Harness engineering para agentes IA en producción es la capa de infraestructura y código que rodea al modelo LLM para garantizar comportamiento determinístico, auditable y resiliente. Sin harness, un agente IA en producción es ruleta rusa: alucina KPIs, sobrecarga APIs de terceros con 429s, pierde estado entre reintentos y no podés explicar por qué tomó una decisión. Con harness, un LLM se convierte en sistema confiable. KPIs en código, no hallucinations. Sin retainers, sin licencias atadas, código a tu nombre.
¿Qué problema resuelve harness engineering?
Cuatro problemas concretos que los LLMs traen por defecto:
Problema 1: no determinismo. Misma entrada puede dar salidas distintas. Inaceptable para KPIs y decisiones operativas.
Problema 2: rate limits de proveedores. OpenAI, Anthropic, HubSpot, Twilio, todos rate-limitean. Sin harness, tu agente cae en 429 cascadas.
Problema 3: fallos silenciosos. Un LLM puede devolver JSON malformado, hallucinations creíbles, o ignorar tu prompt. Sin harness, estos pasan a producción.
Problema 4: auditabilidad. Cuando un cliente pregunta por qué su solicitud fue rechazada, necesitás trazabilidad. Un LLM crudo no la da.
Harness resuelve los cuatro.
Componentes mínimos de un harness serio
| Componente | Función | Stack típico 2026 |
|---|---|---|
| Rate limit wrapper | Throttle calls a LLM y APIs externas | Python decorator, semáforos |
| Retry exponencial | Reintentos 1s, 2s, 4s con jitter | Tenacity, backoff |
| Idempotency key | UUID por operación para evitar duplicados | Header en cada write |
| Audit log immutable | Trazabilidad de cada decisión | Postgres con SHA-256 hash chain |
| KPIs en código | Métricas calculadas determinístico | TypeScript funciones puras |
| Guardrails de output | Validación JSON schema y reglas | Pydantic, Zod |
| Observabilidad | Structured logs, traces, metrics | OpenTelemetry, Sentry |
| Circuit breaker | Corta cuando proveedor está caído | Custom o resilience4j |
| Fallback chain | Modelo alternativo si principal falla | Manual ruteo por error |
Faltarte uno de los nueve te deja vulnerable en producción.
El caso real: outbox pattern y 0 incidentes en write-back
Un cliente operativo en Centroamérica con plataforma multi-tenant para 100 franquicias necesitaba write-back automático a un sistema legacy externo (TNI) sin perder datos cuando el legacy estaba caído.
Solución: outbox pattern. Trigger en app.leads on INSERT a fase BOOKED genera fila en outbox.cierres_venta con idempotency_key UUID. Worker Python consume outbox y hace write-back con retry exponencial.
Componentes:
- Outbox queue pattern: trigger PostgreSQL genera row
- Idempotency key UUID: cada cierre tiene clave única
- Retry exponencial: 1s, 2s, 4s con jitter
- Audit log cada retry: trazabilidad completa
- CDC logical replication ready: para alta frecuencia
Resultado: cero incidentes en producción incluso cuando el legacy TNI estuvo caído 3 horas. El sistema esperó pacientemente y reenvió sin duplicar. Idempotency más outbox son la combinación que evita pesadillas en multi-tenant.
Guardrails: la pieza más importante
Los guardrails son lo que separa un agente IA juguete de uno listo para producción. Tres niveles:
Nivel 1, validación de output: el LLM devuelve JSON, vos validás contra schema (Pydantic en Python, Zod en TypeScript). Si no valida, retry o fallback.
Nivel 2, KPIs en código: los números nunca los calcula el modelo. El modelo describe, vos calculás. En un cliente con 28 KPIs operativos, todos viven en JavaScript determinístico browser-side. La IA genera la narrativa explicativa solo sobre los números ya calculados.
Nivel 3, reglas de negocio determinísticas: ciertas decisiones críticas no las puede tomar el modelo. Aprobaciones financieras, ruteo de capital, decisiones de compliance. El modelo sugiere, el código decide.
KPIs en código, no hallucinations. Auditable, defendible.
Patrón outbox para integración con sistemas externos
Cuando tu agente IA escribe a un sistema externo (CRM, ERP, payment gateway), nunca lo hagas directo. Patrón outbox:
- Tu agente decide qué escribir: LLM o lógica determinística
- Insertás row en tabla outbox local con idempotency_key UUID
- Worker separado consume outbox y hace la escritura externa
- Con retry exponencial y backoff: 1s, 2s, 4s, 8s, 16s
- Si éxito, marcás row como sent
- Si falla permanente, alerta a humano
Ventaja: si el sistema externo cae, tu agente sigue operando localmente. Cuando vuelve, el outbox se vacía. Cero pérdida de datos.
Rate limiting wrapper: el clásico subestimado
Caso clásico: agente que consulta HubSpot API para buscar contacto. Con 20 conversaciones activas y 5 variantes telefónicas cada una, eso son 100 calls por ciclo. HubSpot empieza a devolver 429.
Solución: rate limit wrapper global con 150ms mínimo entre calls. Retries exponencial respetando Retry-After header. Consolidación de variantes en single call con filterGroups OR. Cache 15 minutos.
Resultados típicos en proyectos reales:
- 80% reducción de API calls por ciclo
- 5 variantes telefono pasan a 1 call
- Cero 429 después del deploy
- Bot funciona ininterrumpidamente
Cuando los datos se unifican, los problemas se anuncian solos. Pero hay que haber implementado harness antes.
Observabilidad: structured logs son no negociables
Tres prácticas obligatorias:
Structured logs: cada llamada al LLM se loguea con prompt, response, latencia, tokens, costo, error si lo hubo. JSON, no texto plano.
Traces distribuidos: OpenTelemetry o equivalente para seguir una request desde webhook hasta write-back. Crítico para debug.
Metrics agregados: latency p50/p95/p99, error rate por proveedor, tokens consumidos por modelo, costo diario. Dashboard visible.
Sin observabilidad, debug en producción es adivinanza.
¿Cuánto cuesta construir un harness serio?
Tres rangos honestos:
Hazlo vos mismo con equipo interno: 4 a 8 semanas si tu equipo conoce. Riesgo: omitir alguno de los nueve componentes.
Consultora tradicional: 6 a 12 meses, 100,000 a 300,000 USD. Te dan harness pero atado a sus licencias.
MAGIA Forge boutique: desde 20,000 USD una sola vez en 12 semanas. Harness incluido, código tuyo, cero licencias mensuales.
El payback de un harness bien hecho está en evitar el primer incidente serio (un cobro doble, un cliente que demanda, un downtime no documentado).
¿Cuándo conviene parar de construir y pedir ayuda?
Tres señales claras:
- Ya tuviste un incidente serio por LLM hallucinations o rate limits
- Tu agente toca dinero o compliance y no podés permitirte fallos
- Necesitás auditabilidad para clientes enterprise que lo exigen
En esos casos, MAGIA Forge con guardrails formales rinde más que seguir parchando.
Próximos pasos
Si estás construyendo un agente IA para producción y todavía no tenés todos los componentes del harness, conviene ordenar antes de escalar. Una conversación de 30 minutos sin pitch deck con el equipo que construye sirve para evaluar tu setup actual. Más en MAGIA Forge para casos a medida con guardrails formales. KPIs en código, no hallucinations.