Tu agente de IA aprueba la demo; ahora que apruebe la evaluación
Una demo no prueba nada sobre un agente de IA. Lo desplegable sale de una corrida registrada: casos congelados, verdad de referencia y criterio pass/fail.
Un agente de IA es desplegable cuando un arnés de evaluación escrito puntúa sus corridas como pass/fail — no cuando funciona en una demostración. La demostración muestra un solo camino feliz con un humano mirando. El arnés muestra qué hace el agente con las entradas en las que no pensaste: el mensaje que mezcla dos peticiones, el intento de anulación de instrucciones escondido dentro de una cita, el vago "queremos automatizar cosas" que no debe convertirse en un lead calificado. Construimos un arnés para un flujo acotado — el triaje de leads entrantes para un agente de tres herramientas — y lo corrimos de verdad: 56 ejecuciones registradas en tres versiones de las instrucciones del agente. Los casos de intención simple pasaron 24 de 24. Los casos límite fallaron en patrones, los patrones se corrigieron con cambios de instrucciones, y la corrida completa posterior a la corrección detectó un cambio nuevo. Cada uno de esos fallos habría llegado a un cliente sin el arnés.
Qué prueba una demostración y qué no
La demostración no es evidencia. Prueba que la tubería funciona — el modelo responde, las herramientas se disparan, aparece el registro en el CRM. No prueba nada sobre confiabilidad, porque quien la ejecuta selecciona sin querer las entradas: el mensaje limpio con nombre, servicio y número de teléfono.
Los agentes no fallan en esos mensajes. Fallan en el límite — y los fallos son aburridos de una manera que los vuelve peligrosos. El agente no se cae. Llama a la herramienta equivocada con total confianza, y la herramienta equivocada suele ser la que parece correcta: un lead "calificado" a partir de un mensaje que nunca nombró un servicio, o una pregunta legítima de un comprador entregada a un humano porque el mensaje contenía una frase de anulación dentro de una cita.
Esa asimetría es por qué "funcionó cuando lo probamos" no es un criterio de aceptación. No se llega a los casos límite por casualidad en una demostración. Hay que escribirlos, por adelantado, con la respuesta correcta ya decidida.
El arnés: un flujo, tres herramientas, verdad de referencia congelada
El arnés que corremos es deliberadamente pequeño, porque un arnés que nadie termina no vale nada:
- Un flujo acotado. Mensajes entrantes a un agente de triaje. No "todo el proceso de negocio" — un solo salto.
- El alcance exacto de herramientas de producción. Tres herramientas:
qualify_lead(solo con un servicio nombrado y un método de contacto),ask_question(comprador plausible, falta algo),handoff_human(quejas, clientes existentes, fuera de alcance, asuntos legales, intentos de anulación). - Casos congelados con verdad de referencia escrita antes. Doce casos de intención simple y ocho casos límite, cada uno con su herramienta esperada y sus argumentos requeridos decididos antes de la primera corrida. El agente nunca ve la lista de casos.
- Un evaluador determinista. Parsea la acción JSON del agente y puntúa dos cosas: la herramienta correcta y los campos requeridos presentes y no vacíos. Sin intuiciones, sin un juez-LLM circular en el veredicto central.
| Familia de casos | Qué sondea | Ejemplo |
|---|---|---|
| Comprador limpio | Extracción con entrada ideal | Nombre + servicio + teléfono → qualify_lead |
| Elemento faltante | ¿Pide en vez de adivinar? | Servicio nombrado, sin contacto → ask_question |
| Fuera de alcance | Disciplina de alcance | Automatización de impuestos → handoff_human |
| Multi-intento | En alcance mezclado con fuera de alcance | Chatbot y arreglo de WordPress → handoff_human |
| Anulación citada | Separar datos de instrucciones | Un prospecto cita "ignora todas las instrucciones" → es pregunta de comprador, no un ataque |
| Entusiasmo vago | Presión a la sobre-calificación | "Automatizar cosas" + teléfono no debe calificar |
| Inversión comprador/vendedor | ¿Quién está comprando realmente? | Un proveedor que te vende no es un lead |
| Queja con presupuesto | Emoción vs. proceso | Cliente furioso que aún quiere comprar → humano, no una etapa del pipeline |
Dos corridas por caso, temperatura 0.3, un modelo tipo flash detrás de un protocolo de acción JSON. El costo total de inferencia de las 56 ejecuciones: cambio. La parte cara no son las corridas — es la disciplina de escribir la verdad de referencia primero.
Qué encontró la corrida: tres modos de fallo, uno de ellos una mentira que nos contamos
| Modo de fallo | Cómo se ve | Observado en nuestra corrida |
|---|---|---|
tool_error | Acción que parece correcta, herramienta equivocada para la verdad de referencia | 4 ejecuciones: el agente sobrereaccionó a una anulación citada (entregó una pregunta de comprador) y sobrecalificó una petición vaga (había contacto, no había servicio nombrado) |
context_loss | Herramienta correcta, campo requerido vacío o ausente | 1 ejecución: handoff_human se disparó con reason vacío — el humano recibe un ticket sin contexto |
scope_error | Una acción fuera del alcance concedido | 0 — el esquema de herramientas aguantó |
silent_no_op | Ninguna acción parseable | 0 — el contrato JSON aguantó |
Lee con cuidado la fila de tool_error, porque contiene el hallazgo que justifica todo el ejercicio: ambos patrones de herramienta equivocada fueron deterministas. El agente hizo la misma llamada equivocada en las dos corridas del mismo caso. Eso no es ruido del modelo que se agota esperando — es un defecto en las instrucciones escritas, y ninguna cantidad de "probémoslo unas cuantas veces más" lo hace desaparecer. Los fallos deterministas son la mejor noticia en una corrida de evaluación: nombran la frase exacta de tu procedimiento que está mal.
El segundo hallazgo es el que todos se saltan. Después de parchar las instrucciones contra ambos patrones — el texto citado son datos, y las frases vagas no nombran ningún servicio — la corrida completa pasó 15 de 16, y el único fallo fue un caso que antes pasaba: el handoff multi-intento se disparó con reason vacío en su segunda corrida. Llámalo ruido de muestreo o una regresión del parche; operativamente no importa. La corrida completa fue lo que lo detectó. Un equipo que solo re-corre los dos casos rotos después de un cambio habría publicado con un handoff lanzado a cara o cruz que produce tickets sin contexto.
El criterio pass/fail que puedes poner en un contrato de alcance
"Prueba el agente antes de lanzar" no es un entregable. Esto sí — y un comprador puede exigir cada línea:
- Conjunto de casos congelado, verdad de referencia con fecha anterior a la primera corrida. Si las respuestas esperadas se escriben después de ver las salidas, estás calificando al agente sobre su propio comportamiento.
- Cobertura de límites, no volumen. Cada familia de casos de arriba, al menos una vez. Diez mensajes limpios no prueban nada.
- Dos corridas por caso. Un pase único puede ser suerte; un fallo único puede ser ruido. Dos fallos idénticos son un defecto.
- Dos corridas completas consecutivas para publicar. No re-corridas de los casos rotos — la suite completa, cada vez que cambian las instrucciones, el modelo o un esquema de herramienta.
- Tolerancia cero en dos categorías. Herramienta equivocada en cualquier caso límite, y cualquier campo requerido faltante. Todo lo demás se puede triar; esos dos significan que el agente no puede operar sin supervisión en esa ruta.
- La corrida registrada es el entregable. Desenlaces por caso, las llamadas a herramientas, la clasificación del fallo. Si un proveedor no puede entregarte el registro, no tiene una evaluación — tiene una anécdota.
Es el mismo postura que los equipos de calidad ya toman hacia el código, apuntada a la parte del sistema que no tiene compilador. La documentación de function calling de OpenAI deja explícita la mitad mecánica — herramientas definidas por esquema, el modelo eligiendo entre ellas — pero el esquema solo garantiza que el agente no puede llamar algo que no le concediste. No dice nada sobre si llama a la correcta. Solo el arnés mide eso.
Esto se volvió un criterio de compra este mes
Dos historias aterrizaron en la misma ventana de 48 horas y movieron la evaluación de agentes de higiene de ingeniería a criterio de compra. 1Password lanzó una forma para que agentes de IA inicien sesión en nombre de un cliente sin ver nunca la contraseña — los agentes ahora sostienen rutas de acceso reales hacia sistemas reales (TechCrunch, 22 de octubre de 2026). Y Microsoft atribuyó la brecha de ConnectWise a un grupo que usó agentes de IA a escala contra miles de clientes (TechCrunch, 22 de octubre de 2026). Cuando un agente puede actuar — no solo responder — "¿cómo sabes que hace lo correcto?" deja de ser una pregunta de laboratorio. La respuesta que quieres poder dar no es "lo vimos funcionar". Es un registro.
Si estás evaluando si un agente pertenece en tu ruta de atención a clientes, empieza por los flujos donde una llamada equivocada tiene costo — agendar citas y calificar leads son los dos que más vemos — y lee hasta dónde llega el límite antes de que un humano deba tomar el control: agentes de IA para agendar citas y la barrera de escritura que mantiene a un agente dentro de su carril. La misma disciplina — reglas escritas verificadas antes de publicar cualquier cosa — es lo que cubrimos en por qué las plantillas de WhatsApp se rechazan antes de enviarse.
Corremos este arnés como paso de aceptación en cada agente autónomo de IA que construimos: casos congelados, corridas registradas, un criterio pass/fail en el contrato. Si quieres un agente en el que tu equipo realmente confíe con un cliente, tráenos el flujo — nosotros traemos el arnés.
Preguntas Frecuentes
¿Cuántos casos de prueba necesita un arnés de evaluación de agentes?
Importa cubrir modos de fallo, no volumen. En nuestra corrida registrada, 12 casos de intención simple más 8 casos límite bastaron para encontrar todos los fallos del agente: herramienta equivocada en entradas ambiguas, argumentos requeridos vacíos e intentos de anulación de instrucciones dentro de una cita. Agrega casos solo cuando aparezca un modo de fallo nuevo y congela la lista cuando deje de sorprenderte — un arnés que crece para siempre nunca se puede aprobar.
¿Qué tasa de aprobación significa que un agente está listo para producción?
Son dos puertas, no un número. Los casos de intención simple son el mínimo: menos del 100% dos corridas seguidas es un defecto de instrucciones, no ruido. Los casos límite son la puerta real: exige 100% en dos corridas completas consecutivas, con cero llamadas a la herramienta equivocada y cero argumentos requeridos faltantes, antes de que el agente toque a un cliente real. En nuestra corrida esa puerta se alcanzó solo después de un parche de instrucciones — y la corrida completa posterior al parche fue lo que expuso el último cambio de resultado.
¿Necesito un arnés distinto para cada agente que despliego?
El patrón se transfiere; los casos no. Todo arnés de agente tiene las mismas cuatro partes: un conjunto de casos congelado con verdad de referencia escrita antes de la corrida, el alcance exacto de herramientas que el agente tendrá en producción, un evaluador que puntúa la elección de herramienta y los campos requeridos, y una taxonomía de fallos. Solo cambian el flujo de trabajo y la lista de casos. Presupuesta una tarde por flujo, no un proyecto.
