10 pilares para llevar agentes con LLM a producción

Tu agente funciona bárbaro en un notebook, pero cuando lo ponés detrás de una API se cae con tres llamadas concurrentes. El modelo alucina parámetros, se come tu presupuesto en un bucle infinito o tarda diez segundos en responder.

Llevar agentes de IA a producción no es escribir mejores prompts: es diseñar software distribuido con control determinista sobre piezas que son estocásticas. En este post te muestro el mapa con los 10 pilares técnicos para armar agentes confiables, tomando como ejemplo un agente financiero que consulta saldos y transfiere plata entre cuentas.

Cada pilar es un tema amplio y tiene su propio post en detalle. Donde ya está publicado, te dejo el link.

graph TD
    subgraph Cognicion ["1. Ingesta y Decisión"]
        P1["1. Context Engineering"] --> P4["4. Agent Patterns"]
        P4 --> P5["5. Loop Engineering"]
    end
    subgraph Accion ["2. Ejecución y Control"]
        P5 --> P2["2. Tool Calling"]
        P5 --> P3["3. Agent Orchestration"]
        P2 & P3 --> P7["7. Guardrails"]
    end
    subgraph Infraestructura ["3. Operabilidad y Calidad"]
        P7 --> P8["8. Observability"]
        P8 --> P6["6. Evals"]
        P8 --> P9["9. Cost & Latency"]
        P10["10. Spec-Driven Dev"] -. "gobierna" .-> Cognicion & Accion & Infraestructura
    end

1. Context engineering

El context engineering define qué tokens exactos entran a la ventana del modelo en cada paso. No se trata de redactar texto lindo en el system prompt, sino de balancear memoria operativa, recuperación de documentos y recorte de historial.

El compromiso central acá es fidelidad semántica versus degradación de atención (needle-in-a-haystack):

Resumen en cascada (rolling summarization): Baja el consumo de tokens en charlas largas, pero pierde matices. Si tu agente bancario resumió la sesión cuatro veces seguidas, seguro olvidó el límite diario que el usuario fijó en el primer mensaje.
Recuperación jerárquica (parent-document retrieval o auto-merging): Indexás fragmentos chicos para buscar bien, pero inyectás el documento padre completo con las reglas de la cuenta. Mejorás la precisión del contexto, aunque triplicás los tokens que procesás por nodo recuperado.

Si acumulás mensajes en una lista con messages.append(), la atención del LLM se diluye. Después del décimo turno, la tasa de alucinaciones se dispara.

→ Profundizá: RAG en producción: más allá del demo y memoria para agentes LangGraph sobre DynamoDB.

2. Tool calling

Tool calling conecta la probabilidad del modelo con la ejecución determinista de tu código. Si parseás texto libre con expresiones regulares, tu sistema se va a romper tarde o temprano.

La arquitectura actual usa gramáticas libres de contexto (CFGs) y constrained decoding en el motor de inferencia, como documenta OpenAI con sus Structured Outputs. Esto obliga al LLM a responder sólo con tokens que cumplan un esquema JSON estricto.

from pydantic import BaseModel, Field
from typing import Literal

class TransferFundsSchema(BaseModel):
    account_id: str = Field(..., pattern=r"^ACC-[0-9]{6}$")
    amount_cents: int = Field(..., gt=0, le=10_000_00)
    currency: Literal["USD", "EUR"]
    idempotency_key: str = Field(..., min_length=16)

# El motor de inferencia fuerza la decodificación contra el esquema:
# response = client.chat.completions.create(
#     model="tier-frontera",
#     messages=context,
#     tools=[{"type": "function", "function": {"name": "TransferFundsSchema", "parameters": TransferFundsSchema.model_json_schema()}}],
#     tool_choice={"type": "function", "function": {"name": "TransferFundsSchema"}}
# )

Si validás los datos en tu gateway antes de llamar a la base del banco, frenás los errores de tipo en el transporte y evitás mutaciones corruptas de saldo.

→ Profundizá: tool calling en producción: constrained decoding, gateways e idempotencia.

3. Agent orchestration

La orquestación define cómo colaboran tus agentes. Si le das 40 herramientas distintas al mismo agente financiero, saturas su atención y empezás a ver desvíos de herramientas (tool drift).

Conviene desacoplar la lógica en grafos de agentes especializados mediante routers deterministas o semánticos.

Topología en estrella (Coordinador y Workers): Un despachador detecta la intención y deriva la tarea a un subagente con sólo 3 a 5 herramientas especializadas (ej. sólo transferencias o sólo consultas de saldo).
El compromiso técnico: Esta división baja los errores por paso, pero suma latencia de red en cada serialización de contexto entre agentes.

→ Profundizá: LangGraph vs Vercel AI SDK: máquinas de estado o reactividad en el Edge.

4. Agent patterns

Los patrones de diseño agregan computación en tiempo de inferencia (test-time compute). En vez de pedirle una transferencia en un único paso sin red de contención, armás ciclos de validación.

graph LR
    User["Prompt Inicial"] --> Plan["Planner (Tier Razonamiento)"]
    Plan --> Exec["Executor (Tier Rápido / Mini)"]
    Exec --> Check["Checker (Validador / Linter)"]
    Check -- "Error / Inconsistencia" --> Plan
    Check -- "Válido" --> Out["Respuesta Final"]

Maker y Checker: Un nodo arma el plan de transferencia y otro independiente valida los datos contra las reglas de negocio o linters.
El compromiso técnico: Patrones como Reflection o Planner/Executor resuelven mejor las tareas complejas (como migrar una base bancaria), pero triplican el tiempo al primer token (TTFT) y la latencia final. No sirven para chats en tiempo real sin procesos asíncronos.

→ Profundizá: patrones de agentes: planner/executor, maker-checker y reflection.

5. Loop engineering en agentes de IA en producción

El loop engineering controla la máquina de estados que corre las herramientas y decide cuándo parar. Si tu bucle no tiene condiciones de corte duras, vas a quemar plata.

Para producción necesitás:

Circuit breakers de ejecución: Poné un tope de herramientas por turno (ej. máximo 6 llamadas).
Reintentos con backoff exponencial: Manejá errores 429 y 503 con jitter aleatorio para no saturar tus servicios en cascada.
Presupuesto por traza: Si la ejecución acumula más de 0.05 USD de costo, cortá el bucle y activá una degradación elegante con un mensaje de fallback.

→ Profundizá: del loop simple al graph robusto.

6. Evals

Probar a mano en la terminal no escala. Cuando ajustás un prompt o cambiás a un modelo más chico para ahorrar costos, podés romper silenciosamente el formateo JSON o la lógica de negocio.

Un buen pipeline de evaluación junta aserciones de código con LLM-as-a-judge. Para evaluar con otro LLM sin sesgos estadísticos, tenés que controlar tres problemas:

Position bias: El evaluador suele elegir la primera opción. Lo corregís evaluando dos veces e invirtiendo el orden de las respuestas.
Length bias: El modelo confunde respuestas largas con respuestas de calidad. Lo corregís penalizando el texto redundante y normalizando por densidad de información.
Self-enhancement bias: Un modelo suele calificar mejor sus propias salidas. Lo evitás usando una familia de modelos distinta para juzgar y calibrando contra un dataset dorado anotado por personas.

→ Profundizá: CI/CD para agentes: evitar regresiones silenciosas con evals.

7. Guardrails

Los guardrails son defensas deterministas y probabilísticas alrededor del modelo. Poner advertencias de seguridad dentro del system prompt no alcanza: es vulnerable a inyecciones de prompt y jailbreaks estructurados.

Tipo de Guardrail	Mecanismo	Latencia Agregada	Caso de Uso
Síncrono (In-line)	Filtro léxico / Regex / Modelo clasificador ultra-chico	+15-40 ms	Detección de PII, bloqueo de inyecciones de comandos directas
Asíncrono (Out-of-band)	Escaneo secundario paralelo vía worker	0 ms (no bloqueante)	Auditoría de toxicidad, análisis de cumplimiento normativo ex-post
Human-in-the-Loop (HITL)	Pausa de estado con webhook de aprobación	Variable (minutos/horas)	Acciones destructivas: mutaciones de esquemas, transferencias de dinero

Cualquier acción crítica o irreversible, como mover plata o borrar registros, tiene que pedir confirmación humana o pasar por un control de permisos estricto (RBAC).

→ Profundizá: gobernanza de agentes: por qué el tool calling directo es una falla de diseño y el sandbox operativo para control inteligente.

8. Observability

Para debugear agentes necesitás tracing distribuido. Tenés que registrar cada cambio de estado, el contexto inyectado, las llamadas a herramientas y los costos de cada span, siguiendo las convenciones semánticas de OpenTelemetry para GenAI.

sequenceDiagram
    autonumber
    actor U as "Usuario"
    participant G as "Agent Gateway"
    participant LLM as "LLM (Tier Razonamiento)"
    participant Tool as "Servicio SQL"

    U->>G: Inicia Run (trace_id: 9a7b)
    Note over G: Span 1: Context Hydration (45ms, 1.2k tok)
    G->>LLM: Inferencia Planificación
    Note over LLM: Span 2: Model Inference (650ms, $0.003)
    LLM-->>G: tool_call: execute_query
    G->>Tool: SELECT balance FROM accounts WHERE id = 'ACC-12'
    Note over Tool: Span 3: DB Exec (12ms, 0 tokens)
    Tool-->>G: result: { balance: 45000 }
    G->>LLM: Inferencia Respuesta Final
    Note over LLM: Span 4: Model Synthesis (400ms, $0.001)
    LLM-->>G: Payload final
    G-->>U: Render respuesta (Total: 1107ms | Costo: $0.004)

Si sólo guardás la pregunta inicial y la respuesta final, nunca vas a saber si el agente falló por un mal fragmento recuperado de la base, un error de sintaxis en la consulta SQL o una distracción del modelo.

→ Profundizá: distributed tracing con OpenTelemetry para agentes.

9. Cost & latency

Para no fundirte, tenés que dividir la inferencia en niveles de cómputo específicos en vez de mandar cada paso al modelo más caro del mercado.

                  [ Ingestion de Request ]
                             │
                  [ Router / Classifier ]  <── Tier Rápido / Sub-10B
                             │
            ┌────────────────┴────────────────┐
            ▼                                 ▼
   [ Tarea Simple / Parseo ]         [ Razonamiento Complejo / Síntesis ]
            │                                 │
   Tier Rápido / Mini                Tier Razonamiento / Frontera
   (Latencia <100ms, Bajo Costo)     (Alta Capacidad, Mayor TTFT)

Prompt caching: Poné el contenido estático (instrucciones base, esquemas de transferencias y herramientas) al principio del prompt. Aprovechás la memoria KV-cache de tu proveedor, bajás hasta un 90% el costo de entrada y reducís el tiempo de respuesta.
Model routing: Evaluá la dificultad de cada mensaje. Tareas directas como extraer el CBU o clasificar la intención van a modelos chicos (sub-10B o tiers mini), y dejás los modelos grandes sólo para planificar transacciones complejas.

→ Profundizá: optimización de costos: caching, decodificación especulativa y routing.

10. Spec-driven development

El desarrollo guiado por especificaciones define los límites del agente mediante contratos estrictos y máquinas de estados finitos (FSM).

En nuestro agente bancario, no podés dejar que el modelo decida por su cuenta si primero cobra la tarjeta o manda la factura. La FSM fija qué transiciones de estado son válidas; el LLM sólo completa los datos de cada paso. Tu especificación tiene que dejar en claro los caminos permitidos, los errores posibles y los límites que el sistema jamás puede cruzar.

→ Profundizá: spec-driven development: FSMs y contratos para agentes.

Qué hacer el lunes

Sumá tracing con OpenTelemetry: Registrá la latencia, los tokens y los payloads de cada herramienta antes de agregar más features.
Usá constrained decoding: Reemplazá el parseo manual de strings por esquemas estrictos con claves de idempotencia para tus APIs críticas.
Configurá circuit breakers: Fijá un tope de iteraciones, presupuestos máximos de dinero y timeouts en cada bucle.
Dividí tus modelos por tiers: Mandá la clasificación inicial y la extracción de datos a modelos rápidos y baratos.

Controlar el no-determinismo no es un capricho teórico. Es el único camino técnico para que tus agentes de IA en producción sean confiables y económicamente viables.