Qué es un agente de IA: definición técnica honesta, sin misticismo

'Agente' se convirtió en la palabra más distorsionada del mercado de IA. Toda startup llama a su producto agente. Todo framework promete agentes. Todo proveedor jura que su chatbot evolucionó a agente. El resultado: un dev sénior abre el código y descubre un while alrededor de un chat.completions, con dos if de retry. Este post define agente con rigor técnico, lo separa de lo que no es, muestra lo que necesita tener para merecer el nombre, y termina clasificando los arquetipos que aparecen en producción. Sin misticismo. Ingeniería.

La definición que voy a defender aquí, basada en la línea de Anthropic (Building Effective Agents, 2024) y Russell & Norvig (AIMA 4ta ed): un agente es un sistema donde un LLM controla de forma autónoma su propio flujo de ejecución, decidiendo qué herramientas usar, cuándo usarlas y cuándo parar, con base en la observación del entorno. El control de flujo está en el LLM, no en el programador. Ese es el eje. Todo lo demás deriva de ahí.

1. La diferencia que lo define: control flow en el LLM vs en el código

En 2024 Anthropic propuso una distinción limpia que se volvió referencia: workflows vs agents.

Workflow: el LLM y las herramientas se orquestan por caminos predefinidos por el código. El programador escribe la secuencia: 'llama al LLM A para clasificar, si es tipo X llama a la tool Y, manda el resultado al LLM B para resumir'. El grafo es fijo. El LLM llena slots, no decide la topología.

Agente: el LLM dirige su propio loop. En cada iteración decide la próxima acción (llamar una tool, razonar más, terminar). El programador no sabe de antemano cuántos pasos va a tener, en qué orden, ni qué tools serán invocadas. La topología emerge de la ejecución.

Esta distinción tiene una consecuencia práctica directa. Un workflow es previsible, debugable, barato. Un agente es flexible, caro, y exige una observabilidad seria. Si tu problema cabe en un workflow, usa un workflow. Un agente es overkill en el 70% de los casos donde se usa hoy. La frase es deliberadamente impopular. Es verdad.

2. Anatomía mínima: lo que tiene que existir

Para que un sistema sea agente según la definición, tiene que tener cinco componentes funcionales. Si falta uno, no es un agente, es otra cosa.

• Modelo: un LLM capaz de tool calling (function calling). Hoy eso significa Claude 3.5+, GPT-4+, Gemini 1.5+, Llama 3.1+, o equivalente. Un modelo sin tool calling estructurado no se convierte en agente sin un hack frágil.
• Tools: funciones deterministas que el LLM puede invocar, con un schema declarado. Una tool puede ser una query SQL, un request HTTP, la lectura de un archivo, la ejecución de código sandboxed, u otro agente.
• Loop: la estructura que recibe la respuesta del LLM, ejecuta una tool si se solicita, devuelve el resultado, e itera. Tiene que tener un criterio de parada (respuesta final, budget agotado, error fatal).
• Memoria de trabajo: una representación del historial de la ejecución accesible al LLM. Mínimo: una lista de mensajes con tool calls y resultados. Avanzado: KV cache optimizado, compactación, resúmenes parciales.
• Runtime/harness: la capa que arma el prompt en cada iteración, parsea la respuesta, despacha la tool, gestiona el error, controla el timeout. Es donde vive el 80% de la complejidad real.

Faltan dos y tienes un chatbot avanzado. Falta el loop con control en el LLM y tienes un workflow. Falta tool calling y tienes un RAG bonito. Los cinco juntos, y solo los cinco juntos, hacen un agente.

3. El ciclo: percepción, decisión, acción, observación

El loop interno sigue OODA (Observe, Orient, Decide, Act), adaptado.

1. Observación: el input inicial del usuario, o el resultado de la última acción. Se convierte en un mensaje en la working memory.
2. Orientación: el harness arma el prompt completo (system + history + tools disponibles) y lo envía al LLM.
3. Decisión: el LLM genera una respuesta. Puede ser tool_use (una o varias, en paralelo) o texto final (end_turn).
4. Acción: el harness ejecuta las tool calls solicitadas, captura el resultado (éxito, error, datos retornados).
5. Vuelta a (1): el resultado se convierte en una nueva observación. El loop continúa hasta end_turn, budget, o error fatal.

El nombre elegante de esta estructura es ReAct (Reasoning + Acting), formalizado por Yao et al. en 2022. Hoy toda implementación seria deriva de ahí. La innovación no está en el patrón, está en cómo se ejecuta cada pieza: cómo gestionar el contexto para que no explote en tokens, cómo retornar un error estructurado, cómo paralelizar tool calls independientes, cómo decidir el budget.

4. Tool calling: lo que lo hace posible

El tool calling es el mecanismo que destraba el agente. Sin él, el LLM solo genera texto. Con él, el LLM genera una solicitud estructurada de acción, que el runtime intercepta y ejecuta.

El protocolo varía por proveedor pero la forma es la misma. Declaras las tools en el request:

{
 "tools": [{
 "name": "get_weather",
 "description": "Returns current weather for a city",
 "input_schema": {
 "type": "object",
 "properties": { "city": { "type": "string" } },
 "required": ["city"]
 }
 }]
}

El LLM, en lugar de generar texto, decide llamar a la tool y emite:

{
 "stop_reason": "tool_use",
 "content": [{
 "type": "tool_use",
 "id": "toolu_01A09",
 "name": "get_weather",
 "input": { "city": "São Paulo" }
 }]
}

El harness ejecuta get_weather('São Paulo'), captura el resultado, y lo devuelve en la próxima iteración como un tool_result. El LLM continúa el razonamiento con el dato nuevo. Ese es el mecanismo. Todo lo que se llama agente hoy gira en torno a esto.

5. Lo que NO es un agente

Para dejar la definición operativa, una lista de lo que se vende falsamente como agente:

• Chatbot con un prompt grande: el LLM responde con texto y el programador lo parsea. Sin tool calling estructurado, sin loop. No es un agente.
• RAG: un pipeline busca docs, los inyecta en el prompt, el LLM responde. Flujo fijo. Es un workflow, no un agente. (El RAG puede ser una tool dentro de un agente, y ahí cambia.)
• Chain of prompts: A genera, B critica, C reescribe. Incluso con varios LLMs, si la topología es fija, es un workflow.
• n8n/Zapier con un nodo de IA: un flujo determinista con IA en un paso. Workflow.
• Function calling sin loop: llamas al LLM una vez, decide una tool, la ejecutas, devuelves la respuesta directo al usuario. Sin iteración. No es un agente, es un function-augmented LLM.

El criterio único es el control de flujo. Si el camino de la ejecución lo decide en runtime el LLM, es un agente. Si lo decide en design-time el dev, no lo es.

6. Los arquetipos que aparecen en producción

Cuatro patrones cubren el 95% de los agentes reales.

Agente reactivo single-turn: un loop corto, pocas iteraciones, sin planificación explícita. El LLM decide la próxima acción basado solo en la observación actual. Bueno para tareas donde el camino es descubrible de forma incremental (soporte, navegación web, debug). Anthropic lo llama 'augmented LLM' en el caso degenerado de 1 turn.

Agente con planner: la primera llamada genera un plan (una lista de pasos). El loop ejecuta cada paso. El LLM puede replanificar si un paso falla. Útil cuando la tarea tiene una estructura previsible (research multi-fuente, refactoring de código, llenado de un formulario multi-página).

Orchestrator-workers (multi-agent): un agente principal descompone la tarea, delega sub-tareas a sub-agentes especializados, sintetiza el resultado. Los sub-agentes tienen su propia context window, reduciendo la contaminación del contexto principal. Un patrón usado en Claude Code, Cursor agent mode, y el deep research de OpenAI.

Evaluator-optimizer: dos LLMs en loop. Uno genera una solución, el otro evalúa. Itera hasta que el evaluator apruebe o se acabe el budget. Útil para generación de código, traducción, redacción técnica, donde la calidad es medible y la iteración paga.

7. Propiedades que separan un agente de un juguete

Un agente que va a producción tiene que demostrar cuatro propiedades operativas. Sin ellas, es una prueba de concepto.

• Convergencia: el loop termina en tiempo finito en la mayoría de los inputs. Métrica: el porcentaje de ejecuciones que alcanzan end_turn dentro del budget definido.
• Idempotencia donde importa: las tools con side-effect deben ser idempotentes (una clave de deduplicación) o exigir confirmación explícita. El agente va a reintentar. Está garantizado.
• Observabilidad: cada turn registra el prompt enviado, la respuesta recibida, las tools llamadas, la latencia, el costo en tokens. Sin trace, debuggear en producción es adivinar.
• Failure mode previsible: ¿qué pasa cuando una tool falla? ¿Cuando el LLM alucina un nombre de tool inexistente? ¿Cuando el contexto hace overflow? Cada una de estas tiene que tener una respuesta diseñada, no accidental.

8. Costo: la variable que dimensiona la viabilidad

Un workflow de 1 llamada cuesta 1x. Un agente típico hace de 5 a 20 llamadas para resolver una tarea. El costo por ejecución escala lineal con el número de turns, y el contexto crece en cada turn (cada tool result se acumula). El costo total puede ser 50x a 200x un workflow equivalente.

Eso cambia la regla de decisión. Un agente tiene sentido cuando: (a) la ganancia de calidad es medible y justifica el costo, (b) el problema no es resoluble por un workflow en el tiempo de diseño, (c) la frecuencia de ejecución es lo bastante baja para absorber el costo, o (d) el costo del error humano es lo bastante alto para pagar la iteración extra.

No tiene sentido cuando: la tarea es de alta frecuencia y bajo valor, tiene un camino determinista obvio, o el budget de tokens no soporta múltiples intentos. 'Todo agente' es la versión 2026 del 'todo microservicio'. Va a salir mal por la misma razón.

9. La línea de tiempo: por qué los agentes funcionan ahora

La idea de agente es antigua (la década de los 80, en IA simbólica). Los LLMs como base de un agente son recientes (2022). El tool calling estructurado se volvió de primera clase en 2023 (OpenAI function calling) y maduró en 2024 (Anthropic tool use, structured outputs). Tres cosas convergieron para que los agentes se volvieran realidad:

• Modelos con razonamiento de largo horizonte: Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro mantienen coherencia a lo largo de 20+ turns. Los modelos de 2023 perdían el hilo en 5.
• Context windows grandes: de 128k a 2M tokens permiten mantener el historial entero sin compactación agresiva. En 2022, 4k tokens forzaban un workflow.
• Tool calling entrenado en el pre-entrenamiento: los modelos modernos fueron entrenados para usar herramientas. No es prompt engineering, es una capacidad nativa.

10. El reframe para quien está construyendo

Definición operativa final, para usar en una discusión de arquitectura: un agente es un workflow donde el grafo de ejecución lo decide en runtime el propio LLM, usando tool calling estructurado, dentro de un loop con un criterio de parada explícito. Si no puedes dibujar el agente en esa frase, o el sistema no es un agente, o la definición que estás usando es distinta de la que la industria está convergiendo.

El próximo post de esta serie irá por debajo de los bastidores: cómo funciona exactamente el harness del agente, cómo gestionar el contexto que crece en cada turn, cómo ejecutar tool calls en paralelo sin race condition, cómo lidiar con una tool que falla en medio del loop, y cómo instrumentar todo eso para la observabilidad. La definición es el eje. La implementación es donde todo sale mal.