Cómo funciona un agente: herramientas, loop y harness

Hasta aquí en la serie de fundamentos vimos cómo funciona la IA, cómo hablarle y cómo consulta documentos (RAG). Todo eso tiene algo en común: el modelo responde. Esta guía explica el salto siguiente — cuando el modelo actúa — y las tres piezas que lo hacen posible: las herramientas, el loop y el harness.

1. Un cerebro sin extremidades

Un LLM es como un cerebro extremadamente capaz… pero sin extremidades. Puede razonar, analizar y generar respuestas sofisticadas. Pero por sí solo no puede hacer nada en el mundo real: no sabe qué hora es, no puede revisar tu calendario, no puede enviar un correo. Solo genera texto.

Un agente es un LLM al que le dimos capacidad de acción: puede usar herramientas, consultar datos y tomar decisiones en varios pasos para completar una tarea — no solo responder.

La diferencia se nota al tiro con un ejemplo:

Chatbot: “¿Cómo redacto un correo para reagendar una reunión?” → te escribe el texto y tú haces todo lo demás.
Agente: “Reagenda mi reunión con Carla para la próxima semana” → revisa tu calendario, encuentra un horario libre, propone el cambio, y cuando confirmas, mueve el evento y avisa a Carla.

2. Las herramientas (tool use): cómo un modelo “hace” cosas

Aquí está el truco que sorprende a todos la primera vez: el modelo nunca ejecuta nada. Lo que hace es pedir que se ejecute algo, en un formato estructurado que tu sistema entiende.

El mecanismo, paso a paso:

Le describes al modelo las herramientas disponibles: nombre, para qué sirve, qué datos necesita. Ej: buscar_disponibilidad(fecha) — “revisa los horarios libres del calendario en una fecha”.
El usuario pide algo: “¿tengo espacio el jueves en la tarde?”
El modelo, en vez de inventar una respuesta, emite una llamada de herramienta: buscar_disponibilidad("jueves").
Tu sistema (no el modelo) ejecuta esa función de verdad: consulta el calendario real.
El resultado vuelve al modelo como texto: “jueves: libre de 15:00 a 17:30”.
El modelo redacta la respuesta final con datos reales: “Sí, tienes libre de 3 a 5 y media”.

Esto tiene dos consecuencias importantes:

El modelo solo puede hacer lo que tú le conectaste. Un agente sin herramienta de correo no puede enviar correos, por más que se lo pidan. Las herramientas definen el perímetro de acción — y por eso son también la primera línea de seguridad.
La calidad de la descripción importa tanto como la herramienta. El modelo decide cuándo usar cada herramienta leyendo su descripción; una descripción vaga produce un agente que usa la herramienta equivocada o no la usa cuando debía.

Ejemplos de herramientas típicas: fecha y hora, búsqueda web, calculadora, feriados en Chile, correos, documentos, validación de RUT, webhooks, bases de datos.

3. El loop: razonar → actuar → observar → repetir

Una herramienta suelta no hace un agente. La magia está en el loop (el patrón se conoce como ReAct): el modelo razona, decide una acción, observa el resultado, y con esa nueva información vuelve a razonar — hasta completar la tarea.

Sigamos el ejemplo de reagendar la reunión con Carla:

Vuelta	Razona	Actúa	Observa
1	”Necesito saber cuándo es la reunión actual”	`buscar_evento("Carla")`	Martes 10:00
2	”Ahora necesito horarios libres la próxima semana”	`buscar_disponibilidad(próxima semana)`	Miércoles 9:00, jueves 15:00
3	”Debo confirmar con el usuario antes de mover nada”	Pregunta: “¿miércoles 9:00 o jueves 15:00?”	El usuario elige jueves
4	”Confirmado: muevo el evento y aviso”	`mover_evento(...)`, `enviar_correo(Carla)`	Ambos OK
5	”Tarea completa”	Responde: “Listo, quedó para el jueves 15:00 y Carla ya fue avisada”	—

Fíjate en tres cosas:

La autonomía de un agente ES este loop, no magia del modelo. Cada vuelta es una llamada más al LLM con el historial de lo que pasó.
El agente decidió su propio camino. Nadie programó “primero busca el evento, luego la disponibilidad”: el modelo eligió el orden según lo que fue encontrando. Eso lo distingue de un flujo fijo.
La vuelta 3 es oro: el agente se detuvo a confirmar antes de una acción con consecuencias. Ese punto de control humano (HITL, human-in-the-loop) no lo decidió el modelo por bondad — se lo impusimos desde afuera. Y eso nos lleva al harness.

4. El harness: donde ocurre la ingeniería real

El loop desnudo es frágil: puede quedarse dando vueltas infinitas, gastar tokens sin control, ejecutar acciones peligrosas o fallar en silencio. El harness es la arquitectura que rodea al modelo y le da capacidad de acción real y segura. La mayor parte de la ingeniería de un agente que funciona en producción ocurre en esta capa — no en el modelo.

Las capas de un harness bien construido:

Capa	Qué resuelve	Ejemplo
Tools	Qué puede hacer el agente	Calendario, correos, búsqueda, validación de RUT
Contexto	La información correcta en el momento correcto	Instrucciones, datos del usuario, resultados de RAG
Memoria	Qué recuerda dentro y entre conversaciones	Corto plazo (la conversación) y largo plazo (preferencias, hechos)
Seguridad	Datos de entrada y salida	Filtros anti prompt injection, no exponer datos de otros
Gobernanza	Quién puede hacer qué	Qué agente accede a qué herramienta; qué acciones requieren confirmación
Gestión de errores	Qué pasa cuando algo falla	Reintentos, fallbacks, avisar en vez de improvisar
Observabilidad	Qué hizo el agente y por qué	Trazas de cada paso, tokens consumidos, decisiones tomadas

Con el tiempo, qué LLM eliges importará cada vez menos — los modelos se van pareciendo. Lo que diferencia a un sistema que realmente funciona de uno que se cae en producción es todo lo demás: el harness. Y a esto se suman los límites duros que ningún agente autónomo debería correr sin ellos: máximo de pasos por tarea (step cap), máximo de gasto (budget cap) y un botón de apagado externo (kill switch).

5. Cuando un agente no basta: enrutadores, orquestadores y subagentes

Para tareas con varias especialidades, los agentes se organizan en flujos agénticos — grafos donde varios nodos colaboran:

Enrutador: analiza la intención del usuario y dirige la conversación a la ruta o agente especializado que corresponde (“esto es una consulta de facturación → al agente de facturación”).
Orquestador: el agente principal que coordina — decide qué agente, herramienta o ruta se usa en cada paso.
Subagentes: agentes secundarios con su propio contexto, a los que el principal delega trabajos específicos (investigar un tema, validar un dato) sin contaminar la conversación principal.

Ojo con el entusiasmo: el patrón dominante en producción sigue siendo un orquestador con buenas herramientas, no diez agentes conversando entre sí. Empezar simple y escalar solo cuando los datos lo justifiquen.

6. Qué NO es un agente

Para cerrar el concepto por contraste:

Un chatbot con buen prompt no es un agente — responde, no actúa.
Un flujo fijo tampoco — si el camino está programado de antemano (“siempre: extraer → clasificar → guardar”), es un workflow. Útil, confiable, pero el modelo no decide nada del recorrido.
La diferencia de fondo: en un agente, el modelo decide qué paso viene después; en un workflow, lo decide tu código.

¿Y cuándo conviene cada uno? Esa decisión — chatbot, workflow o agente — merece guía propia: ¿Chatbot, workflow o agente? Cuándo usar cada uno, el siguiente fundamento de la serie.

Para profundizar

Curso: Flujos Agénticos con AgentInTheLoop — Parte 1 — construye tu primer flujo con enrutadores, RAG y multiagente, sin código.
Glosario de agentes IA — todos los términos de esta guía (ReAct, harness, HITL, orquestador…) en simple.
Qué es un Harness (blog) — las notas originales con el ejemplo del agente personal en producción.
El Harness — Clase 1: un agente de IA por dentro — la serie que desarrolla las 7 capas, con clases dedicadas a contexto, gobernanza y el orden de construcción.
Building Effective Agents (Anthropic) — el ensayo de referencia de la industria sobre workflows vs agentes.