¿Qué es un agente? La anatomía de un sistema que decide | Cleon

La palabra "agente" se estiró hasta significar casi cualquier cosa que llame a un modelo más de una vez. Esa vaguedad es cara: la mayoría de los proyectos que se scopean como "un agente" en realidad quieren algo más simple, más barato y más fácil de testear. Esta página traza la línea con precisión. Un agente es un sistema donde el modelo decide su propio próximo paso en un loop — elige qué tool llamar, lee el resultado y decide qué hacer después, hasta que juzga que la tarea está terminada. Esa única propiedad — el modelo controla el flujo — es lo que separa a un agente de todo aquello con lo que se lo confunde.

Todo en esta subcategoría se construye sobre esa definición. Así que antes de los patrones, las tools y el debugging, esta página expone de qué está hecho un agente, qué no es, y el único test para saber si necesitás uno. Si esto lo tenés claro, la mayoría de las decisiones difíciles de más adelante se vuelven fáciles.

La anatomía de un agente

Un agente son cinco partes trabajando juntas. Sacá cualquiera y tenés otra cosa.

El modelo — el núcleo de razonamiento. Lee la situación actual y decide qué hacer después: llamar una tool, hacer una pregunta o parar. El modelo es la parte en la que todos se fijan, y la que menos importa para saber si el sistema funciona (principio 4 — el modelo es la parte fácil).
Instrucciones — el system prompt que define el trabajo del agente, sus límites y cómo debe comportarse. Acá es donde le decís qué tiene permitido hacer, qué nunca debe hacer, y cómo decidir cuándo terminó. Las instrucciones vagas son la causa más común de un agente que divaga.
Tools — las funciones que el agente puede llamar para actuar o para traer datos. Una tool es una función tipada con un nombre, una descripción que el modelo lee, y argumentos que el modelo completa: lookup_order(order_id), send_email(to, subject, body). Una sola invocación de una tool es una acción. Las tools son la única forma que tiene el agente de afectar el mundo o de aprender algo para lo que el modelo no fue entrenado; ver tools y acciones para cómo diseñarlas.
Memoria — lo que el agente carga entre pasos. Como mínimo, el transcript corriente de la tarea actual (qué intentó, qué volvió). A veces más: hechos recuperados, conversaciones previas, estado de borrador. La memoria es un presupuesto, no un balde — más no es mejor pasado el punto donde la señal se ahoga (principio 10).
El control loop — el motor que ata el resto. Corre un ciclo: percibir el estado actual, razonar sobre él con el modelo, actuar llamando una tool, observar el resultado, y volver al inicio a percibir. El loop se repite hasta que el modelo decide que la tarea está terminada o hasta que dispara una condición de parada (un tope de pasos, un timeout, un error).

El control loop es la parte que lo hace un agente. En un workflow, vos escribiste el orden de los pasos. En un agente, el loop le entrega el control al modelo en cada vuelta y deja que él elija el próximo paso a partir del resultado del anterior. Esa es toda la diferencia, y es la fuente tanto de la capacidad como del riesgo.

Grounding, en un párrafo

Un término que vas a ver por toda esta subcategoría: grounding. Un agente razona sobre lo que sea que se le da. El grounding es la práctica de alimentarlo con hechos reales — recuperados de tus datos, una base, una API — en vez de confiar en lo que el modelo absorbió en el entrenamiento. Un agente sin grounding responde de memoria y adivina con confianza cuando la memoria falla. Un agente con grounding responde a partir de lo que vos le pasaste en esta corrida. El grounding está aguas arriba de casi todo problema de calidad: cuando un agente está equivocado pero fluido, sospechá de lo que le diste antes de culpar al modelo (principio 2).

Agente, workflow, chain, solo prompt: cuatro formas

Son cuatro formas, no cuatro competidores. Cada una es la respuesta correcta a una pregunta distinta. El eje que las separa es uno solo: quién decide el próximo paso.

Solo prompt — una llamada al modelo, una respuesta. Sin tools, sin loop. La forma correcta cuando la tarea es "transformá esta entrada en esta salida" y el modelo ya sabe cómo: resumir, clasificar, reescribir, extraer. Si un solo prompt lo resuelve, frená acá. Es la forma más barata, más rápida y más testeable que hay.
Chain — una secuencia fija de prompts, donde la salida de cada paso alimenta al siguiente. El paso uno extrae entidades, el paso dos las busca, el paso tres redacta una respuesta. Vos escribiste el orden. El modelo completa cada espacio en blanco pero nunca elige qué viene después. Una chain es la forma correcta cuando la tarea tiene etapas claras que siempre corren en el mismo orden.
Workflow — una chain con ramas y lógica: condicionales, loops sobre una lista, reintentos, pasos en paralelo. Aun así, cada camino que la atraviesa es uno que vos dibujaste. Un workflow puede ser complejo y seguir siendo del todo determinista en su flujo de control — el modelo decide contenidos, tu código decide flujo. Esta es la forma que la mayoría de los proyectos "de agente" en realidad necesitan.
Agente — el modelo decide el flujo. No hay secuencia fija; el loop le pregunta al modelo qué hacer después en cada vuelta, y la respuesta depende de lo que devolvió el paso anterior. Le das tools y un objetivo; él compone el camino solo, paso a paso.

Leído de arriba hacia abajo, cada forma le entrega una decisión más al modelo. Un solo prompt no decide nada sobre el flujo. Una chain y un workflow deciden contenidos pero no flujo. Un agente decide el flujo también. Más decisiones entregadas al modelo significa más capacidad en problemas abiertos — y menos previsibilidad, más costo y testeo más difícil. Subís esta escalera solo hasta donde el problema te obliga, y ni un peldaño más.

Cuándo necesitás de verdad un agente

Acá está el test honesto, y tiene una sola pregunta: ¿podés enumerar el camino de antemano?

Si podés dibujar el flowchart — si podés escribir los pasos y las ramas antes de que la tarea corra, aunque sea un diagrama grande y desprolijo — entonces no necesitás un agente. Necesitás un workflow. Construí el flowchart en código. Va a ser más barato de correr, más rápido de responder, posible de testear caso por caso, y va a fallar de maneras que podés predecir y arreglar. Cada rama que podés nombrar es una rama que deberías hardcodear en vez de confiar en que el modelo la elija bien cada vez.

Necesitás un agente solo cuando el camino genuinamente no se puede enumerar de antemano — cuando el próximo paso depende de lo que devuelven los pasos anteriores de maneras que no podés prever, así que ningún flowchart fijo podría cubrir el espacio. Una tarea de investigación que sigue pistas a donde vayan. Un loop de troubleshooting cuya próxima sonda depende del último resultado. Trabajo donde la ramificación es efectivamente ilimitada. Ahí, que el modelo decida el próximo paso no es un lujo; es la única forma que encaja, porque genuinamente no podés escribir el flowchart.

Esto no es un consejo de cautela por la cautela misma. Un agente que debería haber sido un workflow es peor en cada eje que te importa: cuesta más por corrida, responde más lento, deriva de maneras no deterministas y se resiste al eval set que necesitás para shippearlo. La disciplina es usar la forma más chica que encaje con el trabajo — y ser honesto en que el trabajo rara vez necesita la más grande.

El resto del vocabulario

Esta página siembra los términos sobre los que se apoya la subcategoría. Una tool es una función tipada que el agente puede llamar; una sola llamada es una acción. El control loop es el ciclo percibir → razonar → actuar → observar. El grounding es alimentar al agente con hechos reales recuperados en vez de dejar que responda desde el entrenamiento. Un eval es un conjunto fijo de casos de prueba con resultados correctos conocidos contra los que puntuás al agente — la diferencia entre mejorarlo y adivinar (principio 3); como el camino de un agente es no determinista, el eval puntúa resultados y trayectoria, no un string exacto. Vas a conocer cada uno de estos en profundidad a medida que la subcategoría avanza; acá son solo las palabras.

Desde acá, dos direcciones. Para ver cómo se cablean los agentes — un solo agente, un agente llamando sub-agentes, las formas que toma un control loop — leé patrones de orquestación. Para ver los modos de falla antes de chocártelos en producción, leé gotchas de agentes. Los builds específicos de cada plataforma viven en agentes de Agentforce para el trabajo dentro del modelo de seguridad de Salesforce y agentes externos para LangGraph y la Claude API por fuera — tools complementarias que un ingeniero compone, nunca un versus.

Relacionado

Patrones de orquestación — las formas que toma un control loop: un solo agente, sub-agentes, y cuándo usar cada uno
Tools y acciones — cómo diseñar las funciones que un agente llama, y cómo mantener chico el blast radius de cada acción
Gotchas de agentes — los modos de falla — loops, costo desbocado, llamadas a la tool equivocada — y cómo atraparlos
Style Guide de agentes — la vara que un agente pasa antes de salir
Principios de AI Engineering — por qué el modelo es la parte fácil (4), groundeá antes de generar (2), y si no lo podés evaluar no lo podés shippear (3)

Referencia: