GPT Diffusion

Por qué tu agente de IA no sobrevive a la primera semana en producción

2026-08-28 · Devs #agentes#arquitectura#costes#observabilidad#evaluacion

Por qué tu agente de IA no sobrevive a la primera semana en producción

TL;DR: El demo funciona y el despliegue falla, casi siempre por las mismas seis razones: contexto mal gestionado, presupuesto de API sin control, problemas de confianza, QA inexistente, prompt injection sin vigilancia y tests que no reproducen el mundo real. Ninguna es un problema de modelo. Todas son problemas de ingeniería.


El contexto que das de comer al agente es tu mayor fuente de errores

El hilo más instructivo de agosto en r/AI_Agents no vino de nadie famoso. Un equipo dejó de pasarle contexto pre-cargado al agente y le hizo buscar su propio contexto en cada tarea. Resultado: “eliminó una gran parte de nuestros errores de agente” (22 puntos, 31 comentarios).

Esto es contraintuitivo porque la intuición dice “dale toda la información posible”. Pero un agente con contexto pre-cargado trata todo como relevante. Un agente que busca solo lo que necesita discrimina. La diferencia en producción es la diferencia entre errores de alucinación sobre datos que ni venían al caso y respuestas ancladas a lo que la tarea exigía.

La regla práctica: si tu prompt de sistema pasa de unas decenas de líneas de contexto inyectado, conviértelo en herramientas de búsqueda. El agente recuperará peor que un RAG bien afinado si le das todo masticado, pero mejor si le obligas a masticar.

El presupuesto de API se come el proyecto antes que el modelo falle

“AI agents are eating my API budget alive” — 22 puntos y 76 comentarios, uno de los hilos con más discusión del mes. La pregunta era cómo se hace dinero con agentes cuando el coste de tokens consume el margen.

El patrón que emerge en los comentarios es consistente: los agentes sin límites de gasto por tarea entran en bucles caros. Un agente que reintenta, refactoriza “una vez más” o pide otra herramienta puede multiplicar por diez el coste de una tarea que un humano haría por un décimo del precio.

Las medidas que la comunidad reporta como efectivas:

  • Presupuesto duro por tarea, no por día. Un límite diario se consume en la primera tarea bucleada.
  • Modelo barato para el 90% de los pasos, caro para los decisivos. El routing por coste es la respuesta más repetida al hilo.
  • Caché de resultados intermedios. Muchos agentes repiten llamadas casi idénticas.

La exactitud no genera confianza — y sin confianza no hay adopción

“My agent was more accurate than the team it replaced. They still refused to trust it.” — 27 puntos, 32 comentarios.

Este es el fallo que nadie pone en el postmortem porque no es técnico: el agente funciona, el equipo no lo usa. Los comentarios del hilo apuntan a que la confianza no viene de la precisión agregada sino de la explicabilidad del error. Un humano que falla el 15% de las veces de forma predecible genera más confianza que un agente que falla el 5% de formas impredecibles.

Si tu agente va a sobrevivir a la semana uno, alguien tiene que poder responder “¿por qué hizo eso?” para cada acción. Logs de decisiones, no solo de resultados.

QA: nadie sabe cómo validar miles de salidas

“How do you QA thousands of AI phone calls?” — 19 puntos. El caso es llamadas telefónicas pero el problema es universal: cuando el agente genera volumen, la revisión manual se rompe.

Las respuestas del hilo convergen en muestreo estadístico más clasificación automática de salidas: no revisas todo, revisas todo lo que el clasificador marca como anómalo más una muestra aleatoria del resto para calibrar el clasificador. Es QA de fabricación aplicado a texto, y la mayoría de equipos que despliegan agentes no lo tiene montado cuando llega el volumen.

Prompt injection no termina en el despliegue

“How are you detecting new prompt injection patterns after launch?” — 18 puntos, 18 comentarios. La pregunta misma dice lo relevante: la vigilancia de inyección es una actividad post-launch, no un checkbox del despliegue.

El patrón de fallo real: el agente pasa los tests de inyección del entorno controlado y a las dos semanas en producción alguien descubre (o no descubre) un vector nuevo vía contenido de usuario, emails o páginas que el agente visita. Un agente con acceso a herramientas y a contenido externo necesita monitorización de comportamiento anómalo — acciones fuera de distribución — tanto como cualquier sistema expuesto a internet.

726 ejecuciones reales: lo que dice la experiencia acumulada

El hilo con la perspectiva más larga es “What I’ve learned over 726 real world agent runs” (18 puntos, 23 comentarios). Las conclusiones que coinciden con todo lo anterior:

  1. Los fallos de agentes en producción son casi siempre fallos de harness — contexto, límites, observabilidad — no del modelo.
  2. Los tests sintéticos no predicen el comportamiento con entradas reales; solo la exposición gradual al tráfico vivo lo hace.
  3. Un agente sin techo de coste por tarea es una bomba de relojería financiera.

Qué hacer antes de desplegar

Si estás a punto de pasar un agente a producción, esta es la lista mínima que estos hilos, colectivamente, sugieren:

FalloMitigación
Contexto pre-cargado genera erroresBuscar contexto con herramientas en vez de inyectarlo
Coste por bucle sin límitePresupuesto duro por tarea + routing por coste
Equipo no confíaLogs de decisión explicables, despliegue gradual
QA imposible a volumenClasificador de anomalías + muestreo calibrado
Prompt injection post-launchMonitorización de acciones fuera de distribución
Tests que no reflejan realidadTráfico gradual con rollback, no big-bang

Ninguno de estos puntos requiere un modelo mejor. Todos requieren tratar el agente como lo que es: un sistema distribuido no determinista con acceso a dinero y a herramientas, que se despliega con los mismos cuidados que cualquier otro servicio del que dependa tu negocio.

Fuentes

Datos extraídos de reddit-research.db, r/AI_Agents, threads vistos entre el 10 y el 19 de agosto de 2026.

Cargando comentarios...