Anatomía de un AI agent: del trace a la mejora continua

La evaluación es el principal obstáculo sin resolver de la ingeniería de agentes: el output no es determinista, ‘correcto’ resulta a menudo subjetivo y los tests end-to-end son lentos y caros porque cada ejecución cuesta llamadas reales a la API.

MATTEO DI PAOLANTONIO
CTO Orbitant

Esta es la tercera y última entrega de la serie de glosario, dedicada a poner AI agents en producción: cómo se observan, se evalúan y se mejoran cuando ya están operando. En el primer post expliqué cómo funciona un agente por dentro: el bucle, las herramientas y el runtime. En el segundo post recorrí las piezas que se le ponen alrededor: MCP, skills, límites, guardarraíles, sistemas multi-agente y el espectro de agencia.

Esta entrega cierra la serie con la capa operativa: cómo se observa lo que hace el agente, cómo se gestionan los comportamientos del modelo que aparecen en producción (alucinación, no determinismo), cómo se evalúa cuando el output ya no es determinista, cuándo conviene un agente y cuándo basta un workflow, y qué frameworks dominan el ecosistema actual.

Observabilidad, alucinación y no determinismo

Los agentes heredan del LLM tres propiedades que en el software tradicional no existían y que cambian por completo cómo se opera el sistema en producción: la dificultad para observar qué está haciendo el agente cuando encadena decenas de pasos seguidos, la tendencia del modelo a inventarse cosas con consecuencias reales cuando esas alucinaciones llegan al runtime, y el no determinismo que hace que la misma entrada pueda dar resultados distintos en ejecuciones diferentes.

Las tres comparten un mismo origen, el LLM en el núcleo del sistema, y entender cómo se manifiesta cada una es lo que permite operar agentes en entornos reales.

Observabilidad: los agentes son difíciles de debuggear

Debuggear una llamada normal a una API es directo: con ver la entrada y la salida basta. Pero un agente que encadena 30 vueltas en el bucle, con sus llamadas a herramientas y resultados intermedios en cada paso, no se diagnostica sin un sistema dedicado de seguimiento.

Para ese problema, la solución estándar del sector es el tracing: registrar cada paso de la ejecución del agente, con sus inputs, sus outputs, sus latencias y sus costes.

Trace #4821
├─ LLM call 1: "I need to read the file" (2.1s, 1.2K tokens)
│   └─ Tool: read_file("main.py") → 200 lines (0.05s)
├─ LLM call 2: "I see the bug on line 42" (1.8s, 950 tokens)
│   └─ Tool: edit_file("main.py", ...) → success (0.02s)
├─ LLM call 3: "Let me run tests" (1.5s, 800 tokens)
│   └─ Tool: run_bash("pytest") → 2 failures (3.2s)
├─ LLM call 4: "Tests still fail, let me re-read..." (2.0s, 1.1K tokens)
│   └─ ...
Total: 12 steps, 45s, 28K tokens, $0.08

Es el equivalente al tracing distribuido (Jaeger, Datadog) que el sector de microservicios lleva años usando: mismo problema, dominio distinto. Todos los frameworks importantes de agentes ya integran tracing nativo o se conectan con plataformas de observabilidad externas.

Alucinación y anclaje (Grounding)

Los LLMs se inventan cosas: citan una función que no existe, mencionan una librería que nunca se importó o afirman que un fichero contiene algo que no contiene. En un chatbot eso da una respuesta incorrecta. En un agente, esa misma alucinación puede materializarse en una acción real, porque si el agente alucina un comando bash, el runtime lo intentará lanzar.

Las técnicas para mantener al agente anclado a la realidad se conocen como grounding e incluyen tres prácticas habituales:

• Leer antes de editar: nunca dejar que el agente modifique código que no ha visto previamente.
• Verificar antes de afirmar: ejecutar los tests, comprobar el output, no fiarse de la autoevaluación del agente.
• Retrieval-Augmented Generation (RAG): traer datos desde una base de conocimiento en lugar de depender de los datos de entrenamiento del modelo.

Cada llamada a una herramienta es un reality check contra el mundo, y esa es la razón por la que los agentes se construyen con un catálogo amplio de herramientas. Sin ellas, lo que hace el agente se reduce a adivinar; con ellas, puede leer ficheros reales, recibir los mensajes de error que de verdad ocurren al ejecutar el código, y ver los resultados de los tests que efectivamente se han ejecutado.

No determinismo

Los agentes no son reproducibles por defecto: la misma entrada puede generar resultados distintos en ejecuciones diferentes, sin que haya un fallo de por medio. Este comportamiento tiene tres fuentes que conviene identificar antes de intentar testear el sistema:

• Temperature en el LLM (aleatoriedad controlada en la generación de texto).
• Resultados dinámicos de herramientas (los ficheros cambian, las APIs devuelven datos distintos en cada llamada).
• Decisiones de bifurcación (el agente puede elegir leer primero el fichero A en una ejecución y el fichero B en otra).

Las consecuencias prácticas son tres y afectan directamente a cómo se prueba y se monitoriza el sistema:

• No se pueden escribir tests unitarios tradicionales para el comportamiento de un agente.
• Hace falta un evaluation framework que ejecute el agente N veces y mida la tasa de éxito.
• Los agentes en producción necesitan monitorización continua, no solo testing en CI.

Evaluación y mejora continua

Una vez aceptados el no determinismo y los demás comportamientos del LLM dentro del sistema, llega el problema más difícil de la ingeniería de agentes: cómo decidir si lo que produce el agente es lo bastante bueno y qué hacer cuando no lo es.

Esta sección aborda los tres ejes que componen ese problema: por qué evaluar agentes es distinto de testear software, qué estrategias de evaluación están funcionando en producción, y qué palancas concretas hay para mejorar el sistema cuando las evaluaciones muestran problemas.

El problema de la evaluación

Evaluar agentes es el principal obstáculo de la ingeniería de sistemas con LLM. Mientras que en el software tradicional escribes tests deterministas que pasan o fallan, con agentes la realidad se complica en tres dimensiones a la vez:

• El output no es determinista, así que dos ejecuciones idénticas pueden dar veredictos distintos.
• «Correcto» es a menudo subjetivo (¿es este un buen mensaje de commit? ¿Está limpia esta refactorización?).
• Los tests end-to-end son lentos y caros, porque cada ejecución cuesta llamadas reales a la API del modelo.

Estrategias de evaluación

Existen cuatro estrategias habituales para evaluar el comportamiento de un agente en producción, cada una con sus trade-offs propios:

Estrategia	Cómo funciona	Pros	Contras
Benchmark suites	Tareas estandarizadas (por ejemplo, SWE-bench para coding) que miden tasa de éxito	Reproducible, comparable	Scope estrecho, riesgo de gaming
LLM-as-judge	Otro LLM evalúa el output del agente	Escalable, barato	Puede equivocarse, sesgos
Evaluación humana	Humanos puntúan calidad, marcan fallos	Gold standard en calidad	Cara, lenta
Regression testing	Grabar ejecuciones exitosas, comparar con ejecuciones futuras	Detecta regresiones	Frágil, alta carga de mantenimiento

Cómo mejorar basándose en la evaluación

Cuando las evaluaciones muestran que el agente está rindiendo peor de lo esperado, lo primero que cambia mucha gente es el system prompt, pero esa es solo una de las palancas disponibles. En la práctica, son cinco las que están dando resultado en producción.

1. System prompt (la más común, la más barata, ~70% de las mejoras). Los evaluadores humanos detectan un patrón de fallo y se añaden o refinan instrucciones para evitarlo:

Antes de procesar un reembolso, comprueba siempre el estado del envío primero.
Si el artículo aparece como entregado, pide al cliente más detalles
antes de proceder.

Es el feedback loop más rápido: cambias texto, vuelves a ejecutar, ves si mejora. Otros cambios habituales sobre el prompt incluyen añadir ejemplos de comportamiento correcto (few-shot), reestructurar el texto para mayor claridad, introducir reglas explícitas de «no hagas X», o refinar las descripciones de las herramientas que ve el modelo.

2. Diseño de herramientas. A veces el problema no es el agente, son las herramientas mal diseñadas. APIs ambiguas o con parámetros sobrecargados generan comportamientos incorrectos del agente:

# Antes: ambigua, causa errores
def search_customer(name: str) -> Customer

# Después: identificador único, sin ambigüedad
def search_customer(email: str) -> Customer

3. Cambios en la arquitectura o el workflow. Si el agente da demasiados pasos en tareas simples, conviene fijar los caminos simples como workflow determinista y reservar el bucle agéntico solo para los casos que de verdad lo requieren:

# Antes: totalmente agéntico, el agente decide todo
Agent → (averigua qué hacer) → (múltiples loops) → resolución

# Después: enruta los casos comunes a workflows deterministas
Router (LLM clasifica la intención)
   ├─ "password reset"  → workflow determinista (sin agente)
   ├─ "refund request"  → workflow determinista con una comprobación LLM
   └─ "complex/unclear" → agente completo (solo cuando hace falta)

4. El modelo en sí. A veces los problemas del agente no se resuelven con cambios en el prompt ni en las herramientas, y la palanca que queda es actuar sobre el LLM que está en el núcleo del sistema. Hay tres alternativas dentro de esta palanca:

• Actualizar el modelo: pasar de uno más pequeño y rápido a uno más grande y capaz.
• Fine-tuning: entrenar una versión custom sobre datos específicos del dominio.
• Distintos modelos para distintos pasos: usar uno barato y rápido para clasificación, uno potente para razonamiento complejo.

5. Guardrails y post-processing. Para propiedades críticas de seguridad no basta el prompt; conviene añadir guardarraíles firmes implementados en código que actúen como última validación antes de que el output salga del sistema:

def output_guardrail(response):
    if contains_internal_data(response):
        return "Let me transfer you to a specialist."
    return response

El bucle de retroalimentación

El ciclo de mejora continua se materializa en un bucle iterativo: despliegas el agente, observas qué falla, categorizas el tipo de fallo, aplicas la palanca adecuada y vuelves a evaluar. Esquemáticamente:

Deploy agent
   │
   ▼
Evaluate interactions (rate quality, flag failures)
   │
   ▼
Categorize failures:
   ├─ Agent chose wrong action    → fix prompt or tool descriptions
   ├─ Agent used tool incorrectly → fix tool API or tool description
   ├─ Agent was too slow/costly   → change architecture (workflows)
   ├─ Agent misunderstood intent  → better model or fine-tuning
   └─ Agent leaked sensitive data → add guardrail
   │
   ▼
Make the change
   │
   ▼
Re-evaluate (did the fix help? did it break something else?)
   │
   ▼
Repeat

Workflows vs Agents: la distinción práctica

Una de las distinciones arquitectónicas más útiles del ecosistema, publicada por Anthropic, es la separación entre workflows y agents. Saber cuál de los dos modelos aplica a un caso de uso es la decisión más relevante antes de empezar a construir, porque condiciona desde el coste de desarrollo hasta la previsibilidad del sistema en operación.

Workflows: control flow predefinido

En un workflow, el desarrollador decide el control flow en tiempo de construcción:

Step 1: Generate code → Step 2: Run linter → Step 3: Fix errors → Step 4: Run tests

El LLM se usa en cada paso, pero el orden y la lógica están hard-coded. Si el paso 2 falla, siempre se va al paso 3. No hay ambigüedad en el comportamiento.

Agents: control flow dinámico

En un agente, el LLM decide el control flow en tiempo de ejecución. El desarrollador le da un objetivo y unas herramientas, y el modelo averigua qué hacer:

Goal: "Fix the failing test"
Agent decides: read test → read source → think → edit source → run test →
  still fails → read error → try different fix → run test → passes → done

El camino es emergente y no predeterminado, por lo que ejecuciones diferentes pueden recorrer rutas completamente distintas.

Qué convierte un workflow en un agente

Un workflow se convierte en agente cuando cumple estas cinco condiciones:

1. Tiene un único punto de entrada con un objetivo, en lugar de un pipeline de comandos separados.
2. Toma sus propias decisiones sobre qué hacer a continuación en runtime.
3. Se autoevalúa: comprueba su propio output y decide si es lo bastante bueno.
4. Se recupera de errores: prueba enfoques alternativos cuando algo falla.
5. Tiene checkpoints humanos selectivos: solo pausa en decisiones de alto riesgo y maneja el resto autónomamente.

El trade-off

La elección entre workflow y agente implica trade-offs concretos en cinco dimensiones operativas:

	Workflow	Agent
Control	Total: el desarrollador decide todo	Parcial: el desarrollador fija objetivos y revisa
Velocidad	Más lento: humano en cada bucle	Más rápido: ejecuta pasos autónomamente
Predictibilidad	Alta: los mismos pasos siempre	Más baja: puede tomar caminos inesperados
Quality floor	Humano detecta cada error	Necesita buenos criterios de autoevaluación
Complejidad de construcción	Más simple: pipeline lineal	Más difícil: lógica de decisión, manejo de errores, eval

El takeaway práctico

Empieza con workflows. Usa agentes solo cuando la tarea realmente requiera toma de decisiones dinámica. Los workflows son más baratos, más rápidos, más predecibles y más fáciles de debuggear.

La tendencia del sector a principios de 2026 es exactamente esa: workflows estructurados con humano en el bucle, escalando a agentes completos solo cuando es necesario.

Frameworks y SDKs del ecosistema

El panorama de frameworks para construir agentes ha crecido rápido entre 2024 y 2026. Cada uno tiene un enfoque distinto: algunos son agnósticos al modelo, otros están atados a un vendor; algunos son low-level y dan control granular, otros son high-level y esconden la complejidad del bucle.

Esta sección recorre los más relevantes del momento, agrupados por vendor.

Anthropic

Anthropic ofrece dos productos principales para construir agentes alrededor de Claude, uno listo para usar y otro pensado para desarrollar a medida:

• Claude Code: el agente CLI de Anthropic, un agente de coding de nivel producción que usa Claude con herramientas para file I/O, bash, search, etc.
• Claude Agent SDK: SDK en Python para construir agentes custom. Incluye bucle agéntico integrado, integración MCP nativa, uso de herramientas con generación automática de esquemas, guardarraíles, y orquestación multi-agente vía handoffs.

OpenAI

El SDK oficial de OpenAI para agentes está orientado a multi-agente, handoffs y tracing integrado:

• Agents SDK (anteriormente Swarm): SDK Python open source. Conceptos clave: agentes configurados con instrucciones y herramientas, handoffs para multi-agente, guardrails para validación, tracing integrado para observabilidad.

LangChain y LangGraph

Dos frameworks del mismo equipo, con niveles de abstracción distintos:

• LangChain: el framework de agentes original (2022). Abstracciones para chains, herramientas, memoria y retrieval.
• LangGraph: un framework más reciente y de nivel más bajo para construir agentes como máquinas de estado o grafos. Nodos (llamadas LLM, llamadas a herramientas, lógica), aristas (transiciones). Soporta ciclos, ramas, ejecución paralela, estado persistente, y humano en el bucle en cualquier nodo.

Otros frameworks

Más allá de los principales, el ecosistema cuenta con varios proyectos relevantes para casos de uso específicos:

• CrewAI: colaboración multi-agente. El desarrollador define «agentes» con roles específicos («Researcher», «Writer», «Reviewer») y «tareas», y los agentes colaboran para completar workflows.
• Microsoft AutoGen: framework de conversación multi-agente. Los agentes se comunican por paso de mensajes, con patrones complejos de chat grupal (round-robin, manager-directed, etc.).
• Google Agent Development Kit (ADK): integra con modelos Gemini. Orquestación, uso de herramientas, patrones multi-agente, integraciones nativas con Google Cloud.
• Vercel AI SDK: apps web con agentes (TypeScript/Next.js).
• Pydantic AI: agentes type-safe con outputs estructurados.
• smolagents (Hugging Face): framework minimalista, patrón code-agent en el que el LLM escribe Python como su acción.

AI agents en producción: cómo encaja todo

Las tres entregas de la serie han ido cubriendo capas: el bucle del agente fue el foco del primer artículo, las piezas que se le ponen alrededor centraron el segundo, y en este post se aborda la operación. Esta sección final junta las piezas en un único diagrama y resume en qué está convergiendo el ecosistema.

El diagrama de arquitectura

Todas las piezas que han ido apareciendo a lo largo de los tres posts encajan en un mismo diagrama de arquitectura agéntica:

                ┌──────────────┐
                │  USER GOAL   │
                └──────────────┘
                       │
                       ▼
                ┌──────────────┐
                │ AGENT RUNTIME│   (Claude Agent SDK, OpenAI Agents SDK,
                │ (Framework)  │    LangGraph, CrewAI, etc.)
                └──────────────┘
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│ REASONING   │  │   MEMORY    │  │ GUARDRAILS  │
│   (LLM)     │  │             │  │  (safety)   │
└─────────────┘  └─────────────┘  └─────────────┘
                       │
                       ▼
                ┌─────────────┐
                │    TOOLS    │   vía function calling o MCP
                └─────────────┘
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
     File I/O      API calls    Code exec, Web search
                       ▲
                       │
                ┌─────────────┐
                │ MCP SERVERS │   Estandarizados, plug-and-play
                └─────────────┘

La convergencia

A pesar de la diversidad de frameworks, el ecosistema entero está convergiendo en torno a un mismo conjunto de piezas:

• LLMs potentes como el «cerebro».
• Uso de herramientas como las «manos».
• MCP como el «sistema nervioso» que conecta todo.
• Skills como «experiencia reutilizable».
• Agent frameworks como el «esqueleto» que da estructura.
• Guardarraíles como el «sistema inmune» que mantiene las cosas seguras.
• Observabilidad como los «sentidos» que te permiten entender qué está pasando.