Gotchas de agentes: cómo se muere una demo en producción | Cleon

La demo de un agente de IA es un truco de magia. Los inputs están guionados, el camino es amable, la sala quiere que funcione, y funciona — una vez. Un agente en producción es un problema de ingeniería: tiene que ser confiable con inputs que nadie escribió, acotado en costo, correcto en las tools que llama, seguro en las acciones que toma, y con un humano que responde cuando se equivoca. La brecha entre el truco y el sistema es todo el trabajo. Esa brecha es la ingeniería.

Diez gotchas que mataron proyectos de agentes que a Cleon la llamaron a rescatar — sintetizados con la guía oficial, las correcciones que la comunidad práctica aprendió a los golpes, y nuestra propia experiencia en producción donde ambas dejan huecos. Cada uno va con la pregunta a contestar antes de salir a producción y el costo de equivocarte. El encuadre no es "cuál es la respuesta correcta" — es "cuál es la pregunta que tenés que estar listo para defender". Nada de esto depende del toolkit: un agente armado sobre Agentforce, sobre LangGraph y la Claude API, o conectado sobre MCP hereda todos y cada uno.

Los gotchas

1. La brecha demo-a-producción — una demo pulida no prueba nada sobre confiabilidad

Una buena demo prueba que el agente puede hacer la cosa una vez, con un input que alguien eligió. Producción pregunta si la hace de forma confiable todas las veces, con inputs que nadie guionó, al tamaño real de audiencia. Son preguntas distintas, y la distancia entre ellas es donde vive el trabajo. La demo es el arranque del proyecto, no el final.

El costo de confundirlas es una estimación errada por un trimestre y un lanzamiento que falla en la primera semana con los inputs que la demo nunca mostró. La pregunta a contestar apenas alguien dice "subí eso": ¿qué hace esto con el input desprolijo, adversario y a medio llenar que la demo esquivó con cuidado?

2. Sin harness de evaluación — no podés mejorar ni confiar en lo que no medís

"Quedó bien en tres intentos" es una sensación, no un test. Un set de evaluación — casos reales con resultados conocidos que podés puntuar en cada cambio — es la diferencia entre mejorar un agente y adivinar. Sin él, cada edición del prompt es cara o cruz que no podés calificar, y cada regresión sale en silencio.

El costo es un sistema que deriva a oscuras: no distinguís un arreglo de una regresión, y te enterás de cuál fue por un usuario. La pregunta: ¿cuál es tu set de eval, y corre en cada cambio antes de salir? Armalo con las primeras diez fallas reales — codifican cómo se rompe tu problema de verdad.

3. Loops descontrolados y costo sin límite — un agente que replanifica para siempre

Un agente que planifica, actúa, observa y replanifica tiene un modo de falla que un prompt solo no tiene: puede entrar en loop. Sin presupuesto de pasos ni tope de tokens, un agente confundido replanifica hasta agotar la ventana de contexto o la factura, y una sola corrida trabada puede costar más que mil buenas.

El costo de saltearte los topes es una corrida descontrolada que quema presupuesto y latencia en un solo pedido. La pregunta: ¿cuál es el máximo de pasos y de tokens que una corrida puede consumir, y qué pasa cuando choca contra ese muro?

4. Tool calls alucinadas — el modelo inventa un argumento o llama la tool equivocada

Un agente decide qué tool llamar y con qué argumentos, y el modelo puede errarle a ambos: inventar un parámetro que no existe, pasar un valor malformado, o llamar la tool equivocada entera. Si nada valida la llamada contra el schema de la tool antes de ejecutar, un argumento alucinado se ejecuta como si fuera real.

El costo es una acción tomada sobre input basura — un registro actualizado con un valor que el modelo inventó, una query corrida contra un campo que no existe. La pregunta: ¿se valida cada tool call contra un schema estricto antes de ejecutar, y qué hace el agente cuando la validación falla — reintenta, pregunta o frena?

5. Tools demasiado amplias — una tool que puede borrar, enviar o cobrar es un radio de explosión

Apenas un agente puede actuar, lo que está en juego cambia de "respuesta equivocada" a "acción equivocada". Una tool con alcance más ancho que la tarea — una que puede borrar cualquier registro cuando solo necesita actualizar un campo, o enviar a cualquiera cuando solo le escribe al contacto actual — es un radio de explosión esperando que un mal plan lo encuentre. El menor privilegio no es opcional una vez que el agente tiene manos.

El costo es lo peor que la tool puede hacer, porque tarde o temprano un agente confundido lo va a intentar. La pregunta para cada tool: ¿cuál es el alcance más angosto que igual hace la tarea, y de verdad lo restringiste a eso — no solo confiaste en que el modelo se quede adentro?

6. Sin kill switch ni gate humano en acciones de consecuencia

Las lecturas se recuperan; los envíos, los cobros y los borrados no. Un agente que puede tomar una acción irreversible sin humano en el loop y sin forma de frenarlo a mitad de corrida está a un mal plan de un incidente que no podés deshacer. El arreglo son dos controles: un gate de aprobación sobre cualquier cosa de consecuencia, y un kill switch que frena el agente ahora.

El costo de que falten es una acción irreversible que mirás pasar sin forma de intervenir. La pregunta: ¿cuáles de las acciones de este agente son irreversibles, cuáles de esas requieren aprobación humana antes de dispararse, y puede un operador frenar un agente en corrida cuando hace falta?

7. Desborde de contexto — meter todo en el prompt degrada el razonamiento

Más contexto no hace más inteligente al agente. Pasado un punto lo hace peor: la señal que el modelo necesita se ahoga en el historial, la salida de tools y los documentos "por las dudas" que apilaste — context rot. Un agente de corrida larga que acumula la salida de cada paso en el prompt se degrada cuanto más corre, justo cuando lo necesitás más afilado.

El costo es un agente que razona peor cuanto más se mete en la tarea, por razones que no aparecen en ningún error. La pregunta: ¿qué necesita de verdad este paso en el contexto, y cómo mantenés la ventana curada — resumiendo, descartando o recuperando bajo demanda — en vez de dejarla crecer sin límite?

8. Huecos de grounding — el agente responde con seguridad sin retrieval o con el equivocado

Un agente lee los mismos datos que leería un humano, vía retrieval. Si el retrieval no devuelve nada, o devuelve los chunks equivocados, el modelo no frena — responde desde sus parámetros y defiende la suposición con fluidez. Un prompt ingenioso sin grounding es una alucinación con seguridad, y suena exactamente igual que una respuesta correcta.

El costo es una respuesta equivocada con seguridad, que es peor que ninguna respuesta porque alguien actúa sobre ella. La pregunta: ¿qué groundea a este agente, qué pasa cuando el retrieval vuelve vacío, y puede el agente decir "no sé" en vez de inventar?

9. No-determinismo lanzado sin fallback — mismo input, salida distinta, sin red

El mismo input puede producir una salida distinta mañana. Eso está bien para un borrador y es peligroso para cualquier cosa que un cliente ve o que un sistema downstream consume sin revisión. Un agente lanzado sin paso de validación y sin fallback determinístico va a terminar renderizando una falla del modelo como un vacío, un string de error o una alucinación frente a alguien.

El costo es una falla visible sin piso debajo — la salida mala pasa derecho. La pregunta: ¿cuál es el fallback determinístico cuando el agente falla o devuelve algo inválido, y pasa cada generación por un gate de validación antes de usarse? Un fallback aburrido y correcto le gana a una respuesta equivocada y excitante todas las veces.

10. El hueco de responsabilidad — "lo hizo la IA" sin un humano que responda por el resultado

Un agente no mueve la responsabilidad al modelo. Alguien es dueño de cada resultado de consecuencia: lo puede explicar, defender y responder por él cuando está mal. Construí el agente para que esa persona exista, sepa que es ella, y tenga los controles — revisión, override, kill switch — para actuar. "El agente decidió" no es un reporte de incidente que nadie quiera escribir.

El costo es un incidente sin dueño, que es cómo un error arreglable se vuelve uno organizacional. La pregunta: para cada cosa de consecuencia que este agente puede hacer, ¿quién es el humano responsable, y tiene la visibilidad y los controles para ser dueño de esa responsabilidad en la práctica?

El hilo común a los diez: un agente que sale a producción está groundeado, evaluado, acotado, gobernado y con dueño — o es una demo que todavía no falló. Cada gotcha de arriba es un lugar donde el truco de magia y la ingeniería se separan, y producción los encuentra a todos. El trabajo que hace que un agente sobreviva el lunes a la mañana es el mismo que la demo se saltó para parecer sin esfuerzo.

Cierre

Estos diez son las fallas que Cleon vio matar proyectos de agentes con más frecuencia, tanto en builds nativos de Salesforce como externos. El tema compartido es el que recorre toda la ingeniería de IA: la demo hace que el camino fácil parezca el camino entero, y producción es todo lo que el camino fácil dejó afuera. Ninguno es difícil de prevenir de entrada; todos son caros de descubrir en vivo.

La disciplina que previene la mayoría está escrita — mirá el Style Guide de agentes, la vara que un agente tiene que pasar antes de salir. Si querés el lado del grounding de la historia, el chequeo de agent-readiness de Data 360 es donde un modelo limpio se encuentra con un agente seguro.

Si un gotcha de agentes le pegó a tu equipo y no está acá, escribí a hello@wearecleon.com — lo agregamos, con crédito.

Qué es un agente — la definición antes de los gotchas
Patrones de orquestación — acotar loops y componer pasos
Tools y acciones — menor privilegio, schemas y gates
Debuggear agentes — trazar una corrida cuando sale mal
Style Guide de agentes — la vara que un agente pasa antes de salir
Chequeo de agent-readiness de Data 360 — groundear el agente sobre un modelo limpio

Reference: