B2B Support Tickets · AI · Arquitectura Completa
Cómo los dos sistemas
se conectan — y mejoran
Diseñar dos sistemas de agentes es el trabajo visible. Lo que los hace realmente funcionar es lo que pasa en el medio — el objeto de contexto que los conecta, los guardrails que los restringen, y el loop de monitoreo que los hace mejores con el tiempo.
Arquitectura del sistema
Dos sistemas de agentes · un ticket en el medio
Operador
técnico de planta
Sistema del cliente
Lado de ingreso
lo que experimenta el operador
Ticket enriquecido
Técnico
agente de soporte del fabricante
Sistema técnico
Lado de resolución
lo que experimenta el técnico
Operador
Sistema del cliente
Lado de ingreso
Ticket enriquecido
Técnico
Sistema técnico
Lado de resolución
Capa de contexto compartido
El operador ve una interfaz · el técnico ve otra · los agentes trabajan en paralelo. El contexto pasa como un objeto estructurado — no texto libre.
El objeto de contexto compartido
La decisión de diseño más crítica en todo el sistema no es visual — es estructural. Cuando el sistema del cliente termina su conversación con el operador, no pasa un resumen de chat al sistema técnico. Pasa un objeto estructurado. Esa distinción importa por tres razones:
Precisión: los campos estructurados pueden ser parseados, validados y razonados. El texto libre no. Un agente que recibe urgency: high como campo actúa diferente que uno que tiene que inferir urgencia de un párrafo.
Confiabilidad: un objeto estructurado tiene un schema definido. Si falta un campo, el agente receptor sabe exactamente qué no tiene — y puede actuar en consecuencia. Un párrafo faltante en un resumen es invisible.
Trazabilidad: cada campo en el objeto de contexto se loguea con el agente que lo produjo. Cuando un diagnóstico es incorrecto, la traza muestra qué campo faltó o fue incorrecto — y qué agente es responsable.
El schema del objeto
De la base de datos de máquinas
ID de máquina, modelo, fecha de instalación, horas de uso, estado de garantía, fecha de último servicio, contrato de servicio asignado, tier de SLA.
De la conversación con el cliente
Código de error, descripción de síntoma, impacto en producción, clasificación de urgencia, intentos previos, ID del operador, timestamp de cada intercambio.
Del agente de diagnóstico
Hipótesis preliminar si está disponible, nivel de confianza, tickets fuente referenciados, campos marcados como incompletos o inciertos.
Metadata
ID de sesión, IDs de agentes que tocaron el objeto, versión de cada agente, timestamp de creación del objeto de contexto.
Agent IDs — la convención de nombres
{system}.{role}.{version}
System: client o diag — en qué lado del ticket opera el agente.
Role: qué hace el agente — triage, diag, ticket, analysis, suggest, escalation.router.
Version: v1, v2, etc. — qué versión de ese agente corre en producción.
Por qué importa más allá del nombre
En producción, cada acción de agente se loguea con su ID completo. Cuando una traza muestra que diag.suggest.v1 produjo una sugerencia con 78% de confianza que luego fue descartada, el equipo puede:
- ›Extraer todos los tickets donde ese agente sugirió con 60–80% de confianza
- ›Comparar tasas de aceptación entre bandas de confianza
- ›Identificar si la calibración es precisa o sistemáticamente sesgada
- ›Deployar diag.suggest.v2 junto a v1 y comparar performance antes del rollout completo
El ID no es burocracia — es la infraestructura que hace al sistema auditable, mejorable y seguro de evolucionar.
Guardrails — lo que el sistema nunca hace
Los guardrails se definen en tres niveles:
Nivel 1 — Instrucciones en el prompt
Instrucciones explícitas en el system prompt de cada agente definiendo comportamientos prohibidos, con ejemplos de edge cases donde la prohibición aplica.
Nivel 2 — Evals
Antes de que cualquier versión de agente llegue a producción, se testea contra escenarios de guardrail — inputs diseñados para disparar el comportamiento prohibido. Cualquier violación bloquea el release.
Nivel 3 — Monitoreo en producción
Alertas en tiempo real cuando un agente produce output que matchea un patrón de violación de guardrail. Cada alerta se loguea con agent ID, input y output.
Sistema del cliente — lo que nunca hace
- ›Inventar procedimientos técnicos no presentes en la base de conocimiento
- ›Prometer tiempos de respuesta o compromisos de SLA
- ›Minimizar urgencia descrita por el operador como crítica
- ›Pedir información que no se va a usar en el ticket
- ›Continuar la conversación más allá de cuatro intercambios sin crear un ticket
Sistema técnico — lo que nunca hace
- ›Sugerir una solución sin indicar nivel de confianza y fuente
- ›Ocultar que un problema requiere un especialista al que no puede rutear
- ›Acceder a datos comerciales, financieros o contractuales del cliente
- ›Presentar una hipótesis como confirmada cuando es inferida
- ›Reproducir una sugerencia previa que el técnico ya descartó en la sesión
Evals — antes de cada release
Cada versión de agente pasa por una evaluación estructurada antes de llegar a producción. Los evals no son unit tests — son evaluaciones basadas en escenarios que simulan interacciones reales con resultados esperados conocidos.
Estructura del eval
Input: el contexto completo que el agente recibiría en una sesión real.
Output esperado: lo que el agente debería producir, definido como rúbrica en vez de match exacto de string.
Condiciones de falla: outputs específicos que constituyen un eval fallido — violaciones de guardrail, referencias alucinadas, scores de confianza mal calibrados.
Categorías de eval por agente
client.triage.v1
Precisión de clasificación de urgencia · Cumplimiento de guardrails · Completitud de contexto del ticket generado · Precisión de triggers de handoff
client.diag.v1
Reconocimiento de códigos de error · Desambiguación de síntomas · Escalamiento apropiado cuando el patrón es desconocido
client.ticket.v1
Cumplimiento del schema del objeto estructurado · Completitud de campos · Ausencia de campos que deberían estar excluidos
diag.analysis.v1
Precisión de recuperación de historial · Detección de patrones cross-ticket · Identificación correcta de campos de contexto faltantes
diag.suggest.v1
Precisión de hipótesis top-1 y top-2 · Calibración de confianza · Cero referencias alucinadas a tickets · Expresión apropiada de incertidumbre
escalation.router.v1
Identificación correcta de especialista · Completitud del objeto de contexto en handoff · Precisión de triggers — escala cuando debe, no cuando no debe
Umbral de release
- ›Ninguna versión de agente va a producción con alguna violación de guardrail en evals
- ›Misclasificación de urgencia mayor al 10% en escenarios de alta urgencia bloquea el release
- ›Miscalibración de confianza mayor a 15 puntos porcentuales bloquea el release
- ›Cualquier referencia alucinada a un ticket, sección del manual o campo de datos bloquea el release
Monitoreo — en producción
Una vez que los agentes están live, cuatro categorías de métricas se trackean continuamente:
Tasa de escalamiento por agente y tipo de trigger
Si client.triage.v1 escala más del rango esperado, el umbral de urgencia está mal calibrado. Si escala menos, las conversaciones están terminando en frustración. Ambas direcciones son problemas.
Tiempo entre ticket creado y primera acción del técnico
La métrica de negocio principal. Si el ticket enriquecido está funcionando, este número disminuye. Si no, el contexto no le está siendo útil al técnico.
Tasa de adopción de sugerencias
Qué porcentaje de sugerencias de diag.suggest.v1 adopta el técnico sin modificación. Rango saludable: 40–70%. Debajo del 40% las sugerencias no son útiles. Arriba del 70% arriesga confianza ciega.
Completitud de contexto en handoff
Porcentaje promedio de campos completos en el objeto de contexto. Target: arriba del 75%. Debajo del 70% dispara una revisión de qué preguntas el agente del cliente no está haciendo.
Monitoreo de guardrails
- 1.La alerta se loguea con el contexto completo de la sesión
- 2.El agent ID y versión específicos se flaguean
- 3.El input que disparó la violación se agrega al suite de evals
- 4.Se dispara una revisión antes del próximo deploy de ese agente
El ciclo de mejora
El monitoreo alimenta los evals, que alimentan ajustes de prompt y contexto, que vuelven a producción. El ciclo corre continuamente:
Observar: una métrica cae fuera del rango esperado o una alerta de guardrail se dispara.
Diagnosticar: revisar las trazas de las sesiones donde ocurrió la anomalía. ¿Qué contexto tenía el agente? ¿Qué produjo? ¿Qué faltaba?
Intervenir: ajustar el contexto del agente, actualizar el prompt, o agregar escenarios al suite de evals. Evaluar la nueva versión antes de deployar.
Deployar: lanzar la nueva versión junto a la actual. Monitorear tasa de adopción. Hacer rollback si la performance degrada.
Este ciclo no es automatizado — requiere juicio humano para diagnosticar y decidir. Pero los datos que lo alimentan sí son completamente automatizados. Esa combinación es lo que hace al sistema mejorable sin volverse opaco.
Impacto — la perspectiva del dueño del SaaS
Esta es la sección que más importa para la empresa que construyó la plataforma.
Reducción de churn
El sistema aprende de las máquinas específicas de cada fabricante, sus patrones de falla y su historial de resolución. Cuanto más tiempo usa la plataforma un fabricante, más precisas se vuelven las sugerencias de diagnóstico — para su contexto específico. Esa inteligencia acumulada no es transferible.
KPI: tasa de churn mensual — ¿disminuye el churn después de los primeros 90 días de uso?
Net revenue retention
El valor del sistema crece con el volumen de datos. Un fabricante que empieza con una línea de producto tiene incentivo para traer más máquinas, más clientes, más técnicos — porque cada adición hace al sistema más inteligente para todos.
KPI: NRR a 12 meses — un sistema de IA bien diseñado debería impulsar expansión, no solo retención.
Win rate en demos competitivas
Un SaaS de tickets de soporte sin IA compite en precio y paridad de features. Un SaaS con este sistema compite en inteligencia acumulada — algo que un competidor no puede replicar en un ciclo de ventas.
KPI: win rate contra competidores en demos donde el sistema de IA se demuestra con datos de tickets reales.
Data como activo estratégico
Cada ticket enriquecido, cada objeto de contexto estructurado, cada causa raíz logueada al cerrar un ticket — son datos que no existían en forma estructurada antes. Con el tiempo, se convierten en un mapa estructurado de cómo fallan las máquinas industriales. Eso ya no es un producto de soporte. Es una plataforma de inteligencia.
KPI: crecimiento del volumen de datos estructurados — la base de la defensibilidad a largo plazo de la empresa.