Agentes IA en producción: cinco lecciones duras de shipping en 2026

Todos los demos de agentes IA que hemos visto este año funcionan. Todos los agentes IA en producción, en algún momento, alucinaron un reembolso, llamaron a una tool con argumentos basura, o quemaron $40 de tokens en un loop de reintentos. Los demos están guionados sobre el happy path. La producción es el unhappy path el 30% del tiempo.

Hemos hecho shipping de agentes para triaje de soporte, búsqueda interna, resumen de llamadas de ventas, y extracción de datos estructurados durante los últimos 12 meses. La mayoría funciona bien ahora. Ninguno funcionaba bien el día uno. Aquí están las cinco lecciones que más nos costó aprender.

Lección 1 — Los eval pipelines no son opcionales. Son el producto.

El error más grande que cometen los equipos: escriben el agente, lo mandan a staging, miran diez outputs, y dicen que está listo. Tres semanas después un usuario se queja y nadie puede saber si el fix mejoró las cosas o las empeoró.

Necesitas un eval pipeline antes de escribir el segundo prompt. No después del launch. No después del primer regression. Antes.

Lo que corremos para cada agente que hacemos shipping:

• Un test set congelado de 50-300 inputs reales. Sacados de logs de producción cuando ya los tienes. De founders, support tickets, o transcripciones de entrevistas antes de eso.
• Una rúbrica de scoring por tarea. Para extracción factual, exact match o validez de JSON-schema. Para resumen, LLM-as-judge con rúbrica calibrada más sampling humano del 20%. Para agentes que usan tools, éxito en el outcome end-to-end, no solo en las tool calls intermedias.
• Prompts y model IDs versionados. Cada eval run loguea el hash del prompt, la versión del modelo, la temperatura, y las definiciones de tools. Si cambias el prompt sin re-correr, estás adivinando.
• Un regression gate en CI. Cambios de prompt que bajen el eval score más de 3% bloquean el merge.

Los equipos que se resisten dicen que es overkill para un producto temprano. Discrepamos. El eval set es la spec. Si no puedes escribir 50 ejemplos de cómo se ve “bueno”, no entiendes el problema todavía, y no deberías estar haciendo shipping de un agente para él.

Lección 2 — Los techos de costo te van a salvar de un mensaje de Slack a las 3 AM

La semana que hicimos shipping de nuestro primer agente para usuarios externos, un usuario descubrió que podía pedirle que “resuma este PDF de 400 páginas y después traduzca el resumen a 12 idiomas”. El agente obedeció. Nos enteramos cuando sonó la alerta de billing a las 2:47 AM.

Pon techos duros, en tres niveles:

1. Techo por call. Presupuesto de tokens por invocación del agente. Default de 30K input + 8K output con lógica explícita de truncación. Si un input lo excedería, resumimos primero o rechazamos con explicación.
2. Techo por usuario por día. Trackeado en Redis o tu DB. Default de $2-$5/día para usuarios free, $20-$50 para paid. Llegar al techo retorna un rate-limit elegante, no un 500.
3. Techo por tenant por mes. Con alertas de Slack al 50%, 80%, y 100% del budget configurado. Hard cutoff al 120%.

Promediamos $0.04-$0.18 por call de agente en nuestros productos desplegados, con la long tail llegando a $1.20 en tareas multi-hop complejas. Los techos mantienen la long tail de convertirse en una sorpresa de cuatro cifras.

Una lección de costo más sutil: el caching es un feature, no una optimización. El prompt caching de Anthropic corta el costo de system prompts repetidos por cerca del 90%. Si no lo estás usando para cualquier prompt sobre 4K tokens que se llama más de 10 veces por hora, estás quemando dinero.

Lección 3 — El fallback path importa más que el happy path

Una pregunta útil para tu equipo: ¿qué hace el agente cuando la LLM call falla? ¿Cuando la tool call retorna JSON malformado? ¿Cuando el usuario pregunta algo que el agente no fue diseñado para manejar?

Para la mayoría de equipos la respuesta es “no sé, probablemente 500s”. Esa respuesta es el bug.

Diseño de fallback que usamos como default:

• Reintentar una vez con un system prompt más estricto si una tool call retorna output malformado. No hagas loop. Un reintento, después escalar.
• Schema-validate cada output estructurado. Si la validación falla después del reintento, retorna un error tipado, no una alucinación. Usamos Zod o Pydantic según el stack.
• Rutear a un camino determinístico cuando la confianza es baja. Si el classifier del agente para “esto es una pregunta de reembolso” tiene score bajo 0.7, rutea a un humano o un handler basado en reglas. No dejes que el agente improvise.
• Degradación visible al usuario, no falla silenciosa. “No estoy seguro de poder responder esto — ¿quieres que escale a un humano?” es mejor UX que una pausa de 6 segundos seguida de algo equivocado.

En nuestro agente con más tráfico, el happy path maneja 71% de queries, el fallback path maneja 24%, y la escalación humana maneja 5%. El fallback path es donde se construye o se quema la confianza del usuario. Gastamos tiempo de ingeniería más o menos igual en los tres.

Lección 4 — La observabilidad necesita latencia, tool traces y costo en una sola vista

Las herramientas estándar de APM (Datadog, New Relic, Sentry) fueron construidas para servicios request/response. No alcanzan para agentes, porque un agente es un grafo de LLM calls y tool calls, con branching, reintentos, y recursión.

Usamos una capa dedicada de LLM-ops (Langfuse, Helicone, o Arize Phoenix según el cliente) y capturamos:

• Trace end-to-end por invocación. Cada LLM call, cada tool call, cada reintento, con relaciones padre/hijo.
• Latencia en cada paso. Mediana, P95, P99. Los agentes que “se sienten lentos” casi siempre son lentos en un paso específico que no habrías adivinado.
• Costo por trace. Atado al user ID y al tenant ID. Ordenable. El 80/20 del costo vive en 5% de los traces.
• Diff de output en cambios de prompt. Cuando cambias un system prompt, necesitas ver qué hizo distinto el agente sobre el eval set, lado a lado.

Un ejemplo real: teníamos un agente de soporte promediando 8.2 segundos por respuesta. El logging estándar decía “LLM call lenta”. La vista de trace decía “la primera LLM call retorna en 1.1 segundos, después llamamos a una tool de CRM que toma 5.8 segundos, después la segunda LLM call agrega 1.3”. Fix: paralelizar la call de CRM con un paso preliminar de LLM. Nuevo promedio: 3.4 segundos.

No vas a encontrar ese fix en console.log. Invierte en el tooling correcto desde el día uno.

Lección 5 — El human-in-the-loop nunca desaparece del todo

El pitch de “agente totalmente autónomo” es, en 2026, todavía mayormente marketing. Los agentes que se ganan la confianza del usuario tienen humanos en el loop en puntos estratégicos:

• Antes de cualquier acción irreversible. Mandar un email, cobrar una tarjeta, agendar una reunión, modificar data de producción. Mostrar la acción propuesta, requerir confirmación. La fricción es el feature.
• Como auditor periódico. Una muestra semanal de 30-50 outputs aleatorios del agente revisados por un humano, con rúbrica, con los resultados alimentando el eval set.
• Como camino de escalación. Cuando la confianza del agente es baja, cuando el usuario lo pide explícitamente, o cuando la política lo requiere (financiero, médico, legal).

Los agentes que pretenden no necesitar humanos son los que terminan en screenshots de Twitter por las razones equivocadas.

Una nota corta sobre qué cambiaríamos si empezáramos de nuevo

Si construyéramos el agente número uno otra vez, sabiendo lo que sabemos ahora, el orden sería:

1. Eval set primero. Antes de cualquier selección de modelo. Antes de cualquier diseño de tools.
2. Techos de costo configurados antes del primer call a producción.
3. Capa de observabilidad cableada antes del primer demo interno.
4. Happy path implementado.
5. Fallback path implementado con el mismo nivel de rigor que el happy path.
6. Checkpoints de human-in-the-loop diseñados para el 20% de acciones más riesgosas.

Este es el inverso de cómo construyen la mayoría de los equipos. La mayoría escribe el happy path primero, lo lanza, y atornilla el resto después del primer incidente. El costo de ese orden — en confianza del usuario, en facturas sorpresa, en noches tarde — es la lección que quieres aprender de las cicatrices de otro y no de las tuyas.

Cómo trabajamos con clientes en IA de producción

Softronic construye IA de producción para clientes B2B en EE.UU. y LatAm. Entramos como equipo de delivery para un agente específico o como un “AI tiger team” embebido en un producto existente. Traemos la metodología eval-first, los patrones de control de costo, y el stack de observabilidad como defaults. Ustedes traen el conocimiento de dominio y la data.

Si tu equipo está haciendo shipping de features de IA y chocando con la pared demo-a-producción, deberíamos hablar.

• Nuestros servicios de ingeniería IA
• Contratar ingenieros IA de LatAm
• Agendar una llamada de 30 minutos

La IA en producción no es un problema de selección de modelo. Es un problema de ingeniería de sistemas con un componente probabilístico en el medio. Constrúyela así y los demos empiezan a coincidir con la realidad.