AI Operating Layer: El ecosistema agéntico para Customer Experience de Pomelo

La evolución de la AI en Customer Experience apunta a construir una capa operativa capaz de entender contexto, orquestar especialistas, ejecutar acciones, validar respuestas y dejar trazabilidad de cada decisión.

En Pomelo, la incorporación de la AI tuvo como primer objetivo mejorar la velocidad, precisión y escalabilidad de nuestros procesos de soporte. Ese camino nos permitió transformar árboles de decisión, manuales técnicos y herramientas internas en capacidades accionables por agentes. Pero la siguiente etapa no consistía simplemente en sumar más automatizaciones.

El verdadero desafío era diseñar un sistema donde distintos agentes pudieran colaborar entre sí, cada uno con un rol específico, reglas claras, acceso controlado a información y mecanismos de validación. Un ecosistema multi-agente que funcione como una capa operativa sobre la experiencia de cliente.

A esa capa la pensamos como nuestro AI operating layer para customer experience.

La evolución: de un agente a un ecosistema multi-agente

Cuando se habla de AI aplicada a soporte, muchas veces la conversación empieza y termina en un chatbot. Pero en una operación compleja, responder una consulta es solo una parte del problema.

Antes de llegar a una respuesta final, el sistema necesita entender:

• la intención del usuario, es decir, identificar si se trata de una pregunta general o un problema operativo
• buscar información confiable
• solicitar datos faltantes
• categorizar correctamente
• consultar herramientas internas
• ejecutar acciones cuando corresponde
• validar el resultado
• responder en el tono adecuado
• dejar registro de todo lo que ocurrió.

Intentar resolver todo eso con un único agente genera complejidad, pérdida de control y poca trazabilidad.

Por eso, en lugar de diseñar “un agente que hace todo”, avanzamos hacia una arquitectura compuesta por agentes especializados. Cada uno ocupa un espacio concreto dentro de la experiencia y trabaja sobre una parte del flujo.

El resultado es un ecosistema donde la AI no opera como una caja negra, sino como una red coordinada de capacidades: algunas orientadas a documentación, otras a categorización, otras a resolución, validación, escalamiento y monitoreo.

AI Gateway: La Capa de Control y Governance de Sistemas Agénticos

Para que un ecosistema de agentes pueda operar en producción, no alcanza con buenos prompts. Se necesita una capa de gobierno.

En Pomelo desarrollamos un AI Gateway propio, que funciona como punto de control para las interacciones que pasan por nuestros agentes. Esta capa nos permite aplicar criterios transversales de seguridad, eficiencia y observabilidad antes de que una consulta llegue al modelo o a una herramienta.

El Gateway cumple varias funciones clave:

• sanitización de inputs;
• detección de prompt injection;
• fallback entre modelos;
• optimización de costos;
• caching;
• rate limits;
• auditoría;
• observabilidad.

Esto nos permite operar con mayor control sobre cómo se consume AI dentro del ecosistema. El foco está en administrar el ciclo completo de interacción: qué entra, cómo se procesa, qué modelo interviene, qué costos genera, qué riesgos aparecen y qué trazabilidad queda disponible para análisis posterior.

El agente orquestador: punto único de entrada

Dentro del Dashboard de Pomelo, el cliente interactúa con un Agente Orquestador impulsado por AI. Este agente funciona como punto único de entrada para las consultas de los usuarios y tiene memoria de conversación, lo que le permite entender mejor el contexto de la interacción. Su rol principal no es resolver todos los casos por sí mismo, sino interpretar la intención del usuario y decidir cuál es el mejor camino dentro del ecosistema.

Si la consulta está relacionada con información oficial de Pomelo, el agente orquestador la deriva al Agente de Documentación. Si detecta que el usuario está reportando un problema operativo o necesita soporte, deriva la interacción al Agente Categorizador. Y si la intención no es suficientemente clara, puede continuar la conversación para obtener más contexto antes de avanzar.

Este diseño permite separar responsabilidades y el orquestador actúa realmente como tal: escucha, entiende, enruta y mantiene continuidad conversacional.

El agente de documentación: self-service con evidencia

Uno de los primeros espacios donde AI genera valor en Customer Experience es en la documentación. Muchas consultas no requieren abrir un ticket, sino encontrar rápidamente información precisa y confiable.

Para eso, construimos un Agente de Documentación conectado a bases vectorizadas con contenido oficial de Pomelo. Este agente trabaja sobre dos fuentes principales:

• Guides, donde se describe el funcionamiento de productos y servicios.
• API Reference, donde está documentada la referencia técnica de nuestras APIs.

El agente utiliza un enfoque de búsqueda semántica sobre ambas bases. Los resultados se combinan mediante ranking semántico y score combinado, para priorizar la información más relevante según la consulta del usuario. Esto permite responder preguntas técnicas como: “¿Cuáles son los estados posibles de una transacción?”

En ese caso, el agente de documentación busca en las fuentes oficiales, identifica los fragmentos relevantes, arma una respuesta con la voz y tono de Pomelo y cita la documentación correspondiente.

Un punto clave es que el agente no está diseñado para responder a cualquier costo. Si no encuentra evidencia suficiente, evita dar una respuesta imprecisa. Este comportamiento es fundamental para sostener confianza, especialmente en contextos técnicos donde una respuesta incorrecta puede generar fricción o errores de implementación.

El objetivo es doble: mejorar el self-service de nuestros clientes y reducir tickets innecesarios, sin resignar precisión.

El agente categorizador: de conversación a ticket estructurado

Cuando la consulta deja de ser una pregunta general y pasa a ser un problema de soporte, entra en acción el Agente Categorizador.

Siguiendo el ejemplo anterior, un usuario podría empezar preguntando por los estados posibles de una transacción. El agente de documentación responde con información oficial. Pero luego el usuario agrega: “Tengo un problema con esta transacción en particular.”

En ese momento, la conversación cambia de naturaleza. Ya no alcanza con explicar cómo funciona el producto; hay que iniciar un proceso de soporte.

El agente orquestador identifica ese cambio de intención y deriva el caso al agente categorizador. Este tiene cargada una base de conocimiento con los motivos de contacto de soporte y el mapeo de campos requeridos para cada caso.

Su trabajo consiste en:

1. interpretar el problema
2. identificar el motivo de contacto correcto
3. pedir la información faltante de ser necesario
4. evaluar impacto y criticidad
5. crear el ticket con la metadata correspondiente

Hoy, el 100% de los tickets creados desde este flujo, es generado por este agente. Esto nos permite pasar de una conversación libre a un ticket estructurado, con mejor calidad de información desde el inicio y menos retrabajo operativo.

Resolución Automática de Tickets: Orquestación y Enriquecimiento de Casos

Una vez creado el ticket, empieza otra etapa del operating layer: la resolución.

En esta fase interviene un ecosistema de agentes que trabajan de forma coordinada. El objetivo no es solo responder, sino analizar el caso, enriquecerlo, validar la categoría, consultar información interna, ejecutar acciones operativas cuando corresponde y dejar logs de las decisiones tomadas.

El primer paso lo realiza un Agente Re-categorizador. Este agente toma el ticket creado y revisa si el motivo de contacto inicial fue correctamente asignado. Para eso, analiza el input del cliente y consulta información relacionada con transacciones, usuarios y tarjetas, según corresponda.

Si encuentra evidencia de que el caso pertenece a otro motivo de contacto, puede modificar internamente la categoría. Esta segunda capa mejora la precisión del flujo y evita que una categorización inicial incorrecta impacte en la resolución.

Luego interviene el Agente Resolutor. Con el motivo de contacto correcto y el contexto del cliente, busca el manual de resolución específico para ese caso. Estos manuales están almacenados en una base vectorial y cada motivo de contacto cuenta con instrucciones propias.

Los manuales combinan estructura con razonamiento flexible. Es decir, no funcionan únicamente como checklists rígidos, sino como guías técnicas que el agente puede seguir paso a paso, adaptándose al contexto del ticket y a la información que obtiene durante el análisis.

El agente resolutor puede diagnosticar, enriquecer el ticket, consultar herramientas internas, ejecutar acciones operativas, cambiar estados y generar una respuesta final. Actualmente, este ecosistema analiza aproximadamente el 50% del incoming, en un proceso productivo que sigue evolucionando a medida que se incorporan nuevos motivos de contacto.

El agente validador: control antes de responder al cliente

Antes de que una respuesta llegue al cliente, pasa por un agente validador. Esta capa es importante porque en un sistema agentic no alcanza con generar una buena respuesta: hay que verificar que esa respuesta sea segura, consistente, completa y adecuada para el contexto.

El validador aplica un sistema de reglas multifactorial. Revisa aspectos de seguridad, cumplimiento de guardrails, consistencia con reglas de negocio, idioma, claridad y tono. También puede adaptar la respuesta para que mantenga la voz de Pomelo y responda en el idioma del cliente.

Este paso nos permite separar la generación de la respuesta de su validación. El resolutor se enfoca en resolver; el validador se enfoca en asegurar que la salida sea correcta para el cliente y para la operación. Si el sistema detecta que el caso no debe resolverse automáticamente, o que requiere intervención de otro nivel de atención, entra en acción el agente escalador.

Escalar también es parte del diseño

Un buen ecosistema de AI no debería asumir que todo puede o debe resolverse automáticamente. Hay casos donde la mejor decisión es escalar: por criticidad, por falta de información, por baja confianza, por reglas de negocio, por alcance funcional o porque el caso requiere intervención especializada.

En esos escenarios, el agente escalador toma el caso y lo deriva al equipo correspondiente según mapeos internos. La diferencia es que el caso no llega vacío: llega enriquecido con el análisis previo, la información consultada, las decisiones tomadas y el contexto necesario para que el equipo pueda avanzar con mayor velocidad.

Observabilidad, logs y mejora continua

Cada interacción dentro del ecosistema deja trazabilidad. Registramos:

• qué agente intervino
• qué decisiones tomó
• qué herramientas consultó
• qué cambios realizó
• qué respuesta generó 
• cómo evolucionó el estado del ticket. 

Estos logs son fundamentales para auditar, monitorear, detectar errores, mejorar instrucciones y entender el comportamiento real del sistema en producción.

Además, contamos con alertas y monitoreo periódico sobre las interacciones. Esto permite observar la salud del ecosistema, detectar fricciones y seguir ajustando cada componente.

A medida que los clientes interactúan con los agentes y los agentes interactúan entre sí, el sistema genera una nueva fuente de aprendizaje operativo. No solo resolvemos casos: también entendemos mejor dónde aparecen dudas, qué motivos requieren más cobertura, qué documentación puede mejorarse y qué pasos del flujo generan fricción.

Un ejemplo de punta a punta

Imaginemos una interacción dentro del Dashboard.

Un cliente pregunta:

“¿Cuáles son los estados posibles de una transacción?”

El agente orquestador interpreta que se trata de una consulta documental y la deriva al agente de documentación. Este busca en Guides y API Reference, combina los resultados con ranking semántico y score combinado, y responde con información oficial citando las fuentes correspondientes.

Luego el cliente agrega:

“Tengo un problema con esta transacción.”

El orquestador detecta el cambio de intención y deriva la conversación al agente categorizador. Este identifica el motivo de contacto, solicita los campos faltantes y crea el ticket con impacto, criticidad y metadata interna.

Luego, el re-categorizador analiza el caso y consulta información relevante para verificar que el motivo asignado sea correcto. Si corresponde, ajusta la categoría. El resolutor toma el ticket, busca el manual específico en la base vectorial, consulta las herramientas internas necesarias, diagnostica el problema, ejecuta acciones operativas si aplican, enriquece el ticket y genera una respuesta.

El validador revisa esa salida bajo criterios de seguridad, idioma, tono, reglas y consistencia. Si la respuesta es adecuada, se envía al cliente con la voz de Pomelo, se cambia el estado del ticket y queda registro completo de las decisiones tomadas.

Si el caso requiere atención especializada, el escalador lo deriva al equipo correspondiente con todo el contexto ya procesado. Ese es el valor del operating layer: cada agente hace una parte del trabajo, pero la experiencia se siente como un único flujo coordinado.

La próxima etapa de la Operación con AI

Construir un ecosistema multi-agente no es solo un desafío técnico. También implica repensar cómo se diseña una operación de soporte: qué tareas se pueden estructurar, qué información necesita cada flujo, qué decisiones requieren validación, qué casos deben escalarse y cómo mantener trazabilidad en cada paso.

La Inteligencia Artificial empieza a generar más valor cuando deja de ser una capa aislada y se convierte en parte de la arquitectura operativa. En Pomelo estamos construyendo una capa donde cada agente tiene un propósito claro, cada interacción tiene controles y cada decisión puede ser observada. Una capa que nos permite escalar la experiencia sin perder calidad, combinando automatización, gobierno, seguridad y criterio operativo.

Estamos construyendo una capa operativa donde cada nuevo motivo de contacto puede convertirse en una nueva capacidad agentic.