Anatomía de un AI agent: del bucle al runtime

Toda conversación sobre agentes de IA acaba antes o después en la misma pregunta: qué es un AI agent y en qué se diferencia, exactamente, de un chatbot con un buen prompt o de un script con una llamada a un LLM. La respuesta corta es: en cómo funciona por dentro. En el bucle que ejecuta, en las herramientas a las que tiene acceso y en una pieza —el runtime— que orquesta todo lo demás.

Esta es la primera de tres entregas en las que recorro el ecosistema de los agentes de IA. En este primer post me quedo en lo fundamental: cómo se define un agente, cómo razona, cómo actúa y qué programa hace que todo funcione. En la siguiente entro en cómo se construye en la práctica (MCP, skills, guardrails, multi-agente); en la última, en cómo se opera, se evalúa y se conecta con los frameworks del ecosistema.

Sin herramientas, un LLM es solo un generador de tokens. Con herramientas, se convierte en un actor capaz de afectar al mundo real. Es la diferencia arquitectónica más profunda entre un chatbot y un agente.

MATTEO DI PAOLANTONIO
CTO Orbitant

¿Qué es un AI agent?

Un AI agent es un sistema en el que un large language model (LLM) opera dentro de un bucle, decidiendo autónomamente qué acciones tomar para cumplir un objetivo, en lugar de limitarse a responder a un único prompt.

La analogía es útil: una llamada normal a un LLM es como hacerle una pregunta a alguien y recibir una respuesta. Un agente es como contratar a alguien para sacar adelante un proyecto: planifica, usa herramientas, revisa su trabajo, se adapta y sigue trabajando hasta terminar.

Propiedades de un agente:

• Autonomía: decide sus propios pasos sin intervención humana en cada uno.
• Orientado a objetivos: trabaja hacia una meta, no se limita a responder una pregunta puntual.
• Interacción con el entorno: lee ficheros, llama a APIs, ejecuta código, navega por la web. Actúa sobre el mundo.
• Persistencia: opera a lo largo de varios pasos o turnos, manteniendo estado entre ellos.

Terminología que vas a ver en mercado:

• Agentic AI: la categoría amplia.
• Autonomous agent: pone el énfasis en el carácter autodirigido.
• AI agent: el término general.

Los tres se refieren más o menos a la misma idea.

La arquitectura: el bucle agéntico

Todo agente corre un bucle observe-think-act (también llamado reasoning loop o agentic loop):

User Goal
   |
   ▼
┌─────────────────┐
│  1. OBSERVE     │  ← Lee el estado del entorno, los resultados de
│                 │     herramientas, los mensajes del usuario, la memoria
└─────────────────┘
   |
   ▼
┌─────────────────┐
│  2. REASON/PLAN │  ← El LLM piensa qué hacer a continuación
│                 │     (cadena de pensamiento, reflexión)
└─────────────────┘
   |
   ▼
┌─────────────────┐
│  3. ACT         │  ← Llama a una herramienta, escribe una salida,
│                 │     pregunta al usuario, o declara la tarea completa
└─────────────────┘
   |
   ▼
Vuelve al paso 1 (hasta terminar o alcanzar un límite)

Las tres fases del bucle se apoyan en tres componentes que conviene tener bien identificados desde el principio.

Razonamiento y cadena de pensamiento. El LLM «piensa en voz alta» para descomponer tareas complejas. A veces de forma visible en el output; a veces en tokens ocultos de scratchpad que algunos proveedores llaman extended thinking. Modelos como Claude o los de clase GPT-4 están entrenados específicamente para ser buenos en este razonamiento paso a paso.

Memoria. Conviven tres tipos distintos, y mezclarlos es la causa más frecuente de agentes que olvidan lo que deberían recordar o cargan lo que no hace falta:

• Memoria a corto plazo (la context window): el historial de conversación y los resultados de herramientas que el modelo puede «ver» en una llamada. Limitada por la capacidad del modelo (200K tokens para la mayoría de Claude, 1M para Opus).
• Memoria a largo plazo: almacenamiento externo (bases de datos, ficheros, vector stores) que el agente puede leer y escribir entre sesiones. Permite recordar cosas más allá de una sola conversación.
• Memoria de trabajo: un scratchpad o estado intermedio que el agente mantiene durante una sola tarea (una lista de ficheros que ya ha revisado, un documento de diseño parcial, hipótesis a verificar).

Planificación. Los agentes más sofisticados planifican antes de actuar. Tres técnicas dominantes:

• Descomposición de tareas: partir «hazme una app web» en sub-tareas concretas como «crear estructura del proyecto», «implementar la API del backend«, «escribir el frontend«, «añadir tests«.
• Patrón ReAct (Reason + Act): el agente escribe explícitamente su razonamiento antes de cada acción. Es el patrón más común en agentes de producción hoy; el paper original sigue siendo la referencia.
• Reflexión: tras recibir un resultado, el agente evalúa si va por buen camino y ajusta el plan.

Herramientas y function calling

Una herramienta (tool) es una función que el LLM puede decidir llamar. El modelo no ejecuta la función: emite una petición estructurada —normalmente un objeto JSON— que dice «quiero llamar a la función X con los argumentos Y», y el runtime la ejecuta y le devuelve el resultado. Sin herramientas, un LLM es solo un generador de tokens. Con herramientas, se convierte en un actor capaz de afectar al mundo real.

Cómo funciona paso a paso:

1. El system prompt le declara al LLM las herramientas disponibles:
   • read_file(path: string) → string
   • run_bash(command: string) → string
   • search_web(query: string) → string

• El LLM recibe la petición del usuario: «Encuentra el bug en mi código».
• El LLM responde con una llamada a herramienta (salida estructurada):

   { "tool": "read_file", "arguments": { "path": "main.py" } }

1. El runtime ejecuta la función y obtiene el resultado.
2. El resultado se le devuelve al LLM como un mensaje nuevo.
3. El LLM razona sobre el resultado y decide: llamar a otra herramienta o responder al usuario.

Lo crítico está en el paso 3: cuando el LLM emite { "tool": "read_file", "arguments": { "path": "main.py" } }, eso es solo texto. Es una petición, no una ejecución. El LLM está diciendo «me gustaría que alguien lea este fichero por mí». Es la misma lógica que el cuerpo de una respuesta HTTP: texto inerte hasta que algo lo parsea y actúa sobre él. La guía oficial de OpenAI sobre function calling cubre el protocolo con detalle.

Tipos de herramientas habituales:

• Ejecución de código: Python, comandos bash, etc.
• Lectura/escritura de ficheros: leer, escribir, editar.
• Búsqueda: web, código, vector DB.
• APIs: llamar a servicios externos (GitHub, Slack, bases de datos).
• Navegador: navegar webs, clicar, rellenar formularios.
• Comunicación: enviar mensajes, crear pull requests, publicar en Slack.

El runtime: la pieza que conecta al LLM con el mundo real

El runtime es el programa que orquesta todo. El LLM por sí mismo no puede hacer nada salvo emitir tokens: no lee ficheros, no hace peticiones HTTP, no ejecuta código. Es una función pura de texto-entra, texto-sale. El runtime es lo que se sitúa en medio y hace que las cosas pasen.

Lo que hace el runtime:

┌────────────────────────────────────────────┐
│                  RUNTIME                   │
│                                            │
│  1. Construye el prompt (system + history  │
│     + tools)                               │
│  2. Lo envía a la API del LLM              │
│  3. Parsea la respuesta del LLM            │
│  4. Si hay llamada a herramienta →         │
│     ejecuta → obtiene resultado            │
│  5. Añade el resultado al historial de     │
│     conversación                           │
│  6. Vuelve al paso 2                       │
│  7. Si hay respuesta final → la devuelve   │
│     al usuario                             │
│                                            │
│  También se encarga de: auth, rate limits, │
│  reintentos, gestión del contexto,         │
│  guardrails, logging                       │
└────────────────────────────────────────────┘

Un ejemplo concreto. Imagina que el usuario pregunta «¿Qué hay en main.py?». Esto es lo que ocurre a nivel de código:

# ESTO ES EL RUNTIME (simplificado)

conversation = [
    {"role": "system", "content": "Tienes la herramienta: read_file(path)"},
    {"role": "user", "content": "¿Qué hay en main.py?"}
]

while True:
    # Paso 1: llamar a la API del LLM (petición de red a Anthropic/OpenAI)
    response = client.messages.create(
        model="claude-sonnet-4-6",
        messages=conversation,
        tools=[read_file_schema]
    )

    # Paso 2: parsear lo que el LLM devolvió
    if response.has_tool_call:
        # El LLM dijo: "Quiero llamar a read_file con path='main.py'"
        # Esto es solo texto JSON. Aún no se ha ejecutado nada.

        tool_name = response.tool_call.name       # "read_file"
        tool_args = response.tool_call.arguments  # {"path": "main.py"}

        # Paso 3: EL RUNTIME ejecuta la función de verdad
        # Aquí es donde ocurre el trabajo real; el LLM no lo hizo.
        result = execute_tool(tool_name, tool_args)
        # → abre el fichero, lee bytes, devuelve string

        # Paso 4: devolverle el resultado a la conversación
        conversation.append({"role": "assistant", "content": response})
        conversation.append({"role": "tool", "content": result})
        # El bucle continúa; el LLM verá el contenido del fichero
        # en la siguiente llamada.

    elif response.has_text:
        # El LLM decidió responder al usuario en vez de llamar a otra herramienta
        print(response.text)
        break  # Hecho

Qué significa runtime en concreto. No es un concepto abstracto; es una pieza de software identificable.

Agente	El runtime es…
Claude Code	La aplicación CLI de Claude Code (proceso Node.js en tu máquina)
ChatGPT con herramientas	La capa de orquestación de OpenAI en el lado servidor
Un agente de LangGraph	Tu script Python usando la librería LangGraph
Un agente custom	El bucle while que tú escribiste alrededor de la API

El LLM nunca toca el filesystem, la red ni ningún recurso real. Solo ve representaciones en texto de los resultados que el runtime decide enseñarle.

Con estas cuatro piezas —qué es un agente, el bucle, las herramientas y el runtime— tienes el modelo mental para abrir la caja de cualquier sistema agéntico: Claude Code, un agente custom que has escrito tú alrededor de la API, o un sistema con LangGraph. En la segunda entrega de la serie subo una capa: cómo se conecta un agente con el mundo a través de MCP, cómo se encapsula trabajo reutilizable en skills, y qué guardrails hacen que un agente con autonomía no se vuelva peligroso.