Braintrust pone nombre al problema de los agentes stateful: no basta con evaluar un prompt

Braintrust publicó el 26 de junio de 2026 una guía sobre cómo evaluar agentes stateful. El tema suena académico hasta que lo llevas a producción: un agente que recuerda contexto, habla con CRMs, crea tickets, corre migraciones o envía correos no falla igual que un chatbot. Un mal resumen en el paso dos puede contaminar los siguientes diez pasos. Una llamada equivocada a una API puede dejar un cambio real antes de que el usuario vea la respuesta final.

La lección para builders es incómoda pero útil: si tu agente tiene memoria y side effects, una eval de prompt-respuesta ya no alcanza.

Qué vuelve distinto a un agente stateful

Braintrust separa tres propiedades que deberían entrar directo a cualquier checklist de producción.

Primero, el agente acumula working memory. No solo lee el último mensaje; arrastra intentos previos, conclusiones parciales y restricciones del usuario. Eso permite trabajo largo, pero también introduce amnesia de medio contexto, supuestos viejos y narrativas consistentes pero falsas.

Segundo, el agente cambia el mundo. No solo recomienda crear un ticket: lo crea. No solo sugiere una migración: puede ejecutarla. En un sistema stateless, una mala respuesta es molesta. En un sistema stateful, una mala decisión puede dejar datos, permisos o clientes en un estado incorrecto.

Tercero, la trayectoria importa. Dos corridas con el mismo objetivo pueden tomar caminos distintos porque una tool devolvió datos diferentes, una política cambió o un paso temprano eligió otra ruta. La evaluación tiene que mirar esa secuencia, no solo el resultado final.

Checklist mínimo antes de confiar en el agente

Para un equipo pequeño, yo lo bajaría a cinco controles:

1. Registrar cada paso como span estructurado, no como log suelto.
2. Guardar snapshots de estado antes y después de acciones con side effects.
3. Separar evals de paso individual y evals de resultado final.
4. Promover trazas fallidas a datasets de regresión.
5. Correr online scoring o clustering para detectar patrones nuevos en producción.

Eso no exige comprar toda una plataforma desde el día uno. Exige aceptar que “pasó el test unitario del prompt” no dice mucho sobre una corrida de veinte pasos.

Los errores que más se esconden

El artículo de Braintrust menciona fallos que no aparecen en demos: memoria corrupta, supuestos obsoletos, trayectorias que se desvían y decisiones tempranas que vuelven imposible recuperar el objetivo original. En español simple: el agente puede terminar haciendo algo coherente, bien escrito y totalmente equivocado.

Ese patrón pega fuerte en agentes internos. Un agente de soporte puede recordar una política vieja. Uno de DevOps puede asumir que staging y producción siguen iguales. Uno de ventas puede mezclar preferencias de dos clientes. Si solo evalúas la última respuesta, tal vez todo parezca correcto.