CCAR-F · Arquitectura agéntica
Pedidos con varios temas y traspaso a una persona
En soporte, un cliente rara vez escribe por una sola cosa. “Quiero devolver la campera, me cobraron dos veces el envío y cambié de dirección” son tres problemas en un mensaje. Y a veces uno de ellos no lo puede resolver el agente y tiene que pasar a una persona. Las dos situaciones tienen un patrón claro.
Un mensaje, varios problemas
Un pedido con varios temas (multi-concern request) se resuelve en tres pasos:
- Separar el mensaje en ítems distintos: devolución, cobro duplicado, cambio de dirección.
- Investigar cada ítem en paralelo con el contexto compartido (shared context): el mismo cliente, la misma cuenta, el mismo pedido. La cuenta que se consultó para uno sirve para los otros.
- Armar una resolución unificada (unified resolution) antes de actuar, y responder una sola vez cubriendo todo.
El paso 3 es el que más se olvida. Si cada problema lo resuelve un subagente aislado, sin mirar a los demás, pueden actuar dos veces sobre lo mismo: tres subagentes compensando al cliente por el mismo artículo roto. Separar está bien; lo que falta es integrar las decisiones antes de ejecutar.
Resolver lo que se puede, escalar lo que no
Cada ítem se trata según la política. Si el mensaje mezcla un error en la dirección, un costo de envío mal cobrado y un reembolso que supera el límite del agente, el agente resuelve los dos primeros y escala solo el reembolso. Escalar todo por un solo ítem hace esperar al cliente por cosas que el agente podía resolver y baja la resolución en el primer contacto.
El traspaso a una persona
La persona que recibe el caso trabaja en otra herramienta y no ve la conversación. El resumen es lo único que tiene. Por eso el traspaso estructurado (structured handoff) tiene que ser un resumen autocontenido (self-contained summary) con campos fijos:
| Campo | Ejemplo |
|---|---|
| ID del cliente | C-20417 |
| Qué pidió | Reembolso total de una notebook |
| Causa encontrada | Falla de fábrica confirmada por el servicio técnico |
| Monto en juego | US$ 640 (límite del agente: US$ 200) |
| Qué ya se hizo | Dirección corregida, envío reintegrado |
| Acción recomendada | Aprobar el reembolso o ofrecer reemplazo |
Con eso la persona resuelve sin volver a investigar ni pedirle al cliente que repita todo.
Las trampas típicas
- Resolver solo el primer problema y dejar los otros para “otra conversación”: el cliente tiene que volver a escribir.
- Abrir una conversación por problema: se pierde el contexto compartido de la cuenta.
- Escalar todo pedido compuesto: los pedidos con varios temas son normales; derivarlos todos le quita sentido al agente.
- Mandar la transcripción completa como traspaso: hay que leerla entera, volver a encontrar la causa y no trae una acción recomendada.
- Un resumen vago (“cliente molesto por un cobro”): sin ID, monto ni causa, la persona arranca de cero.
- Mover el límite en silencio: aprobar 640 cuando el agente puede 200, o cambiar un reembolso total por uno parcial sin acuerdo del cliente.
En el examen
Si el escenario dice que la persona que recibe el caso “no tiene acceso al chat” o “usa otra herramienta”, la respuesta es el resumen con campos concretos. Si un mismo cliente trae varios problemas, buscá la opción que separa, investiga en paralelo con el contexto compartido y responde una sola vez.
Pregunta rápida
Una pregunta del simulacro sobre este dominio. Cuenta para tu progreso.
A hotel group's booking agent uses a get_payment_details tool to answer questions about charges and deposits. The tool returns full card numbers in its results. It belongs to the payments team, which has said it cannot be changed before next year's platform upgrade.
Security policy says full card numbers must never enter the model's context or the conversation logs. The agent is built with the Claude Agent SDK and runs in an environment managed by a separate infrastructure team. The agent handles roughly 1,500 guest conversations a day across the group's hotels.
What is the best approach?