Primero déjame explicarte por qué elegí este caso de uso
Bueno, si estás en este rubro, sabrás que los reembolsos son uno de los procesos de servicio al cliente más repetitivos y, a la vez, más delicados. Cada caso exige la misma investigación: encontrar el pedido, verificar quién lo pagó, revisar si la actividad ya ocurrió e interpretar la política. Y cada caso toca dinero, así que un error es una pérdida o un problema serio con tu cliente.
Entonces, lo que hice fue construir un AI Agent que hace ese trabajo de principio a fin dentro de Zendesk, con una condición básica: actúa por su cuenta solo cuando la decisión es segura y demostrable. En los demás casos pide información, rechaza con una explicación o entrega el caso a un agente humano.
Tiene cinco piezas, cada una con una sola responsabilidad. No le agregué una interfaz, ya que el equipo sigue trabajando en mi instancia de Zendesk, donde dos triggers avisan a mi agente autónomo al crearse un ticket con un formulario de reembolso que creé, y cuando el cliente responde a un caso en espera.
- Puerta de entrada
- Recibe el evento, verifica que sea auténtico y lo convierte en un objeto de forma estricta. Un campo vacío, mal tipado o inesperado se rechaza y no contamina la decisión.
- Motor de decisión
- Dos capas separadas y versionadas: la política decide si el caso califica, la autoridad, si el sistema puede actuar solo. Nunca se mezclan.
- Flujo persistente
- Cada caso vive en una máquina de estados guardada en base de datos. Si el cliente responde días después, el caso se reanuda donde quedó.
- Simulador comercial
- Mi simulador tiene pedidos, pagos, actividades y reembolsos ficticios que reproducen once escenarios, incluidos cargo duplicado, disputa abierta e identidad que no coincide.
- Despliegue
- Usé GitHub para almacenar el código de mi agente autónomo, Railway como server para alojarlo y SQLite como base de datos.
Objetivos y principios de diseño
Definí seis principios antes de escribir código:
- Automatizar solo los casos seguros.
- Fallar cerrado. Ante duda, dato faltante o resultado incierto, el sistema no ejecuta la acción financiera.
- Mantener a las personas en control. El escalamiento es un resultado previsto, con su propia ruta, cola y mensaje.
- Preservar evidencia. Cada transición de estado queda registrada con su motivo y la versión de política aplicada.
- Evitar reembolsos duplicados. La creación del reembolso es idempotente y un resultado desconocido se reconcilia antes de cualquier reintento.
- Comunicar con claridad en Zendesk. Lo que ve el cliente y lo que ve el equipo son dos cosas diferentes pero alineadas al caso de uso.
Visualmente, este sistema autónomo funciona así
Desliza horizontalmente para ver el diagrama completo.
gpt-4o-mini propone uno y la puerta de aceptación decide si se acepta. Solo ese número entra al motor determinista, que es el único que verifica hechos y mueve dinero.Cómo se toma la decisión
El agente recorre siempre las mismas preguntas, en el mismo orden, y se detiene en la primera que no puede responder con certeza.
- ¿Viene el número de pedido? Si no, el caso queda en espera y se le pide al cliente.
- ¿Existe ese pedido? Si no aparece, no hay nada que reembolsar y se explica por qué.
- ¿Quien escribe es quien pagó? Si el correo del solicitante no corresponde al dueño del pedido, el caso va a revisión humana. No se rechaza ni se aprueba: se entrega.
- ¿Califica según la política? Cuatro reglas pueden hacerlo elegible: retracto dentro de siete días, cancelación de la actividad por la academia, cargo duplicado confirmado y falla técnica confirmada. Si aplican varias, hay un orden de precedencia fijo.
- ¿Puede el sistema ejecutar solo? Pregunta distinta. Un caso puede ser elegible y aun así requerir una persona: por monto, por disputa abierta o por marca de revisión manual.
- Si no, rechazar con explicación o escalar. Nunca quedarse en silencio.
Por supuesto que este flujo debía tener salvaguardas, te las explico de manera visual simple, mira.
Desliza horizontalmente para ver el diagrama completo.
Salvaguardas y confianza
Autenticación y privacidad
Cada llamada trae una cabecera secreta compartida, comparada de forma resistente a ataques de tiempo. Las tablas de flujo guardan códigos de motivo y huellas de los datos, no el cuerpo del evento ni el texto del ticket.
Identidad y revisión humana
Si quien escribe no coincide con el dueño del pedido, el caso se asigna a un grupo de revisión en Zendesk con nota interna y motivo estructurado. Nunca se aprueba ni se rechaza solo, y no queda sin dueño.
Política y autoridad deterministas
Reglas en código versionado con pruebas. Por encima del límite monetario configurado, el caso requiere una persona aunque sea perfectamente elegible.
Duplicados e idempotencia
Cada evento se registra con un identificador estable, y la creación del reembolso usa una clave determinista. Un reenvío no vuelve a actuar, y un resultado desconocido se reconcilia antes de permitir cualquier reintento.
Evidencia y reversión atómica
Cada transición guarda su motivo, la versión de política y una huella criptográfica de la evidencia. Si un paso tardío falla, se revierte la operación completa: no hay estados a medio escribir.
Comunicación segura
Los textos públicos son plantillas fijas. Nunca exponen datos internos ni trazas de error, y nunca prometen un resultado que no ocurrió.
Ahora bien, ¿qué hace que este sistema sea agéntico?
Hoy en día la palabra «agéntico» o «automatización» se usa para casi cualquier cosa, así que aquí me detengo a explicarlo bien porque no quiero venderte humo.
Este sistema es agéntico en un sentido operativo, es decir, cierra por sí mismo el ciclo entre percibir y actuar.
- Percibe un evento desde mi instancia de Zendesk sin que nadie lo invoque manualmente.
- Mantiene estado persistente del caso entre interacciones separadas por días.
- Reúne por su cuenta el contexto que necesita.
- Evalúa política y autoridad, y elige una acción entre varias posibles.
- Actúa a través de Zendesk, agrega comentarios y etiquetas que definí, cambia el estado del ticket.
- Ejecuta o rehúsa un reembolso.
- Pide al cliente la información que falta y espera la respuesta.
- Escala a uno de mis agentes humanos en Zendesk los casos inciertos o no seguros.
- Deja evidencia e historia de auditoría de cada transición.
Cabe aclarar que ningún modelo participa en la decisión de elegibilidad, autoridad, identidad o ejecución. Esas decisiones son deterministas y auditables, y el sistema no razona como una persona para decidir.
¿Cómo funciona la capa de comprensión conversacional?
Para comprender la solicitud de mi cliente, implementé una capa de comprensión con gpt-4o-mini, el cual recibe el último mensaje del cliente y devuelve, mediante Structured Outputs, cuatro campos: intención, motivo declarado, número de pedido y confianza. El sistema valida el esquema, la intención, la confianza y el formato del número de pedido, y solo el número de pedido aceptado llega al motor determinista. La intención, el motivo y la confianza las mantuve para decidir si confiar en esa cadena de texto, y después se descartan.
Las condiciones para aceptar un número de pedido
- Solo cuando no hay nada mejor. Si el ticket ya trae el número de pedido, el modelo no se llama en absoluto, esto me permite ahorrar gastos en OpenAI.
- Intención relacionada con un reembolso y confianza mínima de 0,80.
- Formato válido. Un identificador mal formado se descarta, nunca se corrige: adivinarlo sería adivinar qué pago reembolsar.
¿Cómo hago para medir la confianza?
La confianza expresa cuán seguro está el modelo de haber extraído bien el texto, no si lo que dice el cliente es cierto ni si el reembolso corresponde. Son dos preguntas distintas, y solo la primera es competencia del modelo.
¿Qué pasa cuando falla?
Cosas como tiempo de espera, error de red o de la API, respuesta que no cumple el esquema, confianza baja o credencial inválida producen todas el mismo resultado: ningún número de pedido, y el sistema sigue pidiéndole al cliente el identificador exacto.
Te dejo unos ejemplos de cómo funciona
No incluyo métricas de ahorro, satisfacción o volumen porque no las medí: este es un MVP a modo demo para mostrarte que es posible.
| Escenario | Desenlace | Qué se observó |
|---|---|---|
| Actividad cancelada por la academia, caso elegible | Reembolso simulado | Flujo completo de punta a punta: reembolso registrado una sola vez, ticket resuelto y comentario público de confirmación. |
| Falta el número de pedido | Información solicitada | El agente pidió el número y dejó el caso en espera. Al responder el cliente, se reanudó sobre el mismo expediente en lugar de abrir uno nuevo. |
| La identidad del solicitante no coincide con el dueño del pedido | Revisión humana | Sin acción financiera. Caso abierto y asignado al grupo de revisión, con nota interna y motivo estructurado. Ningún mensaje engañoso al cliente. |
| Evento duplicado | Sin acción repetida | El segundo evento se reconoció como duplicado: ni un segundo reembolso ni reescritura del estado. |
| Petición en lenguaje natural, sin número de pedido en el formulario | Revisión humana | El modelo extrajo la intención, el motivo declarado y el número de pedido con confianza alta. El motor determinista cargó los hechos comerciales, detectó que quien escribía no era el dueño del pedido y derivó el caso. Ningún reembolso autorizado ni ejecutado, y ningún bucle de disparadores. |
| Reinicio del despliegue con datos ya modificados | Servicio recuperado | Tras corregir el arranque, el servicio inició con los datos del volumen, reportó la divergencia y quedó sano. Sin reinicios en bucle. |
¿Qué ve el cliente y qué ve mi equipo en Zendesk?
Dependiendo del resultado se produce una acción distinta.
| Desenlace | Comentario | Estado | Efecto |
|---|---|---|---|
| Reembolso aprobado | Público | Resuelto | Confirma el reembolso al método de pago original y aclara que el tiempo de acreditación depende del banco. |
| Falta información | Público | Pendiente | Pide el número de pedido con un ejemplo concreto y deja el caso esperando respuesta. |
| Revisión humana | Interno | Abierto | Nota privada con el motivo y asignación al grupo de revisión. El cliente no recibe un mensaje automático que prejuzgue el caso. |
| No elegible | Público | Resuelto | Explica que la solicitud no califica según la política, sin cerrar la puerta a una revisión por una persona. |
Limitaciones actuales
- Pagos simulados. El ejecutor no está conectado a ninguna pasarela real; no se mueve dinero.
- Datos ficticios. Silbato, sus academias, clientes, pedidos y pagos son inventados.
- Comprensión validada en escenarios controlados, no con volumen real: funciona y está activa, pero no he medido su precisión con tráfico de clientes.
- Ningún modelo decide sobre dinero. No hay componente generativo en elegibilidad, autoridad, identidad ni ejecución.
- SQLite y una sola réplica. Simplicidad de MVP a cambio de no escalar horizontalmente.
- Sin conciliación ni apelaciones. No existe conciliación contable automática ni un flujo formal de apelación.
- Validación de MVP, no certificación. Nada aquí ha pasado una revisión de seguridad, cumplimiento o riesgo.
Ahora bien, ¿cómo podría beneficiarte este agente autónomo?
Si decides llevar este caso de uso a producción podrías reducir tiempos por caso, evitar respuestas inconsistentes, errores, duplicados, fraude y pérdidas por reembolsos incorrectos. También operaría 24/7 y dejaría auditoría de todo lo que haga para que tu equipo humano sepa qué está sucediendo.
¿Ahorra dinero?
Sí, y aquí no hay que dar muchas vueltas: ahorra dinero porque disminuye el costo por reembolso y aumenta la capacidad del equipo sin que tengas que contratar más personas.
Te doy un ejemplo de cómo pinta el escenario
Digamos que tienes 6 agentes humanos que se dedican a los reembolsos actualmente. Si implementas este agente autónomo, ¿podrías pasar de 6 agentes a 1? La respuesta corta es sí, pero espera: probablemente no debas eliminar los cinco puestos inmediatamente. Primero liberas capacidad para casos complejos, retención y atención de mayor valor. Después del piloto podrás decidir si reduces 5, o 4 o 3, etc., o los distribuyes a otras áreas de más importancia que aún no estén automatizadas.
Te dejo esta fórmula sencilla para calcular el ahorro y que no quede solo en ideas
ahorro = casos automatizados × minutos ahorrados × costo por minuto
Mide durante el piloto: volumen, porcentaje resuelto automáticamente, tiempo promedio, escalaciones y errores. Con eso sabrás cuántos FTE realmente libera.
Para concluir
El LLM que usé entiende el lenguaje humano, como ya es común; sin embargo, los sistemas deterministas verifican los hechos y controlan las acciones financieras. Separar esos dos trabajos es lo que permite usar un modelo de lenguaje en un proceso que toca dinero sin trasladarle el riesgo.
Además, cabe mencionar que cuatro de los seis escenarios validados terminan sin mover dinero. No es una limitación de este agente, de hecho es el propósito. Un sistema que sabe entregar bien un caso difícil es más adoptable que uno que intenta resolverlo todo, desde mi punto de vista.
Ya para terminar, solo quiero decirte que la parte difícil de un agente autónomo no es la automatización. Es el diseño conjunto de cuatro cosas: la acción que el sistema puede ejecutar, las salvaguardas que delimitan hasta dónde llega esa capacidad, la evidencia que permite reconstruir cada decisión, y el escalamiento humano como desenlace de primera clase.
Cuando están las cuatro y haces que funcione, la conversación con tu equipo de riesgo y finanzas cambia: ya no debes preguntarte «¿confiamos en la IA?», sino «¿estamos de acuerdo con estos límites que le hemos dado?».
Esto es una demo que hice sobre un caso de uso financiero o que involucra dinero como los reembolsos, pero no te limites: un agente autónomo o de IA puede cubrir muchos otros escenarios o casos de uso.