La mayoría de los rollouts de “soporte con IA” fallan de la misma forma: un bot responde todo, con confianza, incluyendo el 8% de los tickets donde equivocarse cuesta un reembolso, un churn o un incidente de compliance. Este agent template invierte eso. Es un agente de IA de Decagon —conectado a Zendesk— acotado para resolver completamente una porción estrechamente definida de tickets tier-1, y diseñado para escalar limpiamente en el momento en que un ticket sale de esa porción. El entregable no es “un agente que lo intenta”; es un agente con un allowlist explícito de intenciones resolvibles, una compuerta de confianza, un límite de tool-calls y un payload de handoff que aterriza a un humano en contexto en vez de arrancar en frío. La tasa de deflexión es la métrica de vanidad; la métrica que este template optimiza es resuelto-sin-reapertura en las intenciones del allowlist, mientras las escalaciones llegan mejor preparadas de lo que habría llegado un ticket ruteado por un humano.

El bundle del artifact se describe en prosa aquí y se entrega en cuatro partes: agent-instructions.md (el system prompt y la persona), intent-allowlist.yaml (las intenciones resolvibles con guardrails por intención), escalation-schema.json (el contrato del payload de handoff) y _README.md (el cableado de Decagon + Zendesk y la suite de aceptación de 12 casos). Lee las cuatro antes de apuntar el agente a tráfico en vivo.

Cuándo usarlo

Úsalo cuando manejas una organización de soporte con una instancia de Zendesk y un volumen tier-1 significativo y repetitivo —estado de pedido, reseteo de contraseña y login, preguntas de plan y ciclo de facturación, “dónde está mi factura”, how-to básico y reconocimientos de incidencias conocidas. El patrón gana su lugar por encima de aproximadamente 2,000 tickets/mes, donde la porción del allowlist es lo bastante grande como para que incluso un 30-50% de contención sobre ella libere una cantidad medible de horas de agente. También necesitas una base de conocimiento real: la calidad de resolución de Decagon es una función directa de los artículos del help center y las macros sobre las que puede fundamentar respuestas. KB basura, agente basura.

Encaja mejor cuando tu mix de tier-1 es genuinamente deflectable —intenciones informativas y transaccionales con respuestas correctas deterministas— y cuando tienes un support lead que será dueño del allowlist y revisará las transcripciones de escalación semanalmente. Este es un sistema operado, no un interruptor de configurar-y-olvidar.

Cuándo NO usarlo

No despliegues esto en intenciones donde una respuesta equivocada es cara y no reversible: cancelaciones, reembolsos por encima de un umbral trivial, reportes de seguridad y account-takeover, solicitudes de borrado de datos (GDPR/CCPA), cualquier cosa que toque pagos más allá de leer el estado de la factura, y cualquier cosa legal o contractual. Estas pertenecen al camino de escalación desde el día uno —no van en el allowlist, punto. El template las trae pre-excluidas en intent-allowlist.yaml y deberías resistir la presión de agregarlas porque la contención se ve bien en un dashboard.

No lo despliegues si tu help center es delgado u obsoleto. Un agente fundamentado en 40 artículos desactualizados citará con confianza la política de reembolsos vieja. Arregla el KB primero; el agente amplifica cualquier calidad que tenga debajo.

No lo uses como un muro de deflexión que dificulte llegar a un humano. La forma más rápida de destruir el CSAT es atrapar a un cliente frustrado en un loop. La lógica de escalación de este template es deliberadamente ansiosa —prefiere hacer handoff de un ticket en el borde que ganar un punto de contención. Si tu mandato es “reducir el volumen de tickets a cualquier costo”, este es el template equivocado; quieres uno peor, y te vas a arrepentir.

No lo despliegues para menos de ~500 tickets/mes. El costo del setup y la revisión semanal supera las horas ahorradas; unas pocas buenas macros y reglas de ruteo le ganan a un agente a esa escala.

Setup

Presupuesta de una a dos semanas, la mayor parte gastada curando el allowlist y corriendo la suite de aceptación —el cableado de Decagon y Zendesk en sí es una tarde.

Conecta Decagon a Zendesk. En Decagon, agrega el canal de Zendesk y autoriza contra un usuario de API dedicado (no el seat de una persona) acotado a leer tickets y KB y a escribir respuestas públicas, notas internas y tags. Apunta la fuente de conocimiento de Decagon a tu Zendesk Help Center y reindexa. Confirma que el agente puede leer un ticket de prueba y postear un borrador de respuesta antes de avanzar.
Carga el allowlist de intenciones. Importa intent-allowlist.yaml. Cada entrada nombra una intención (ej. order_status), los artículos de KB que la fundamentan, las tools que puede llamar (ej. leer el pedido vía el webhook de estado de pedido) y un guardrail por intención (order_status puede declarar estado y ETA pero nunca debe prometer un reembolso o un expedite). Cualquier cosa que no esté en el allowlist se rutea a un humano por definición —la acción por default es escalar, no intentar.
Configura la compuerta de confianza. En agent-instructions.md se requiere que el agente autoevalúe la fundamentación de su retrieval antes de responder. Si no puede citar un artículo específico de KB o un resultado de tool para su respuesta, debe escalar en vez de generalizar. Configura la compuerta para escalar cuando la fundamentación esté ausente; no dejes que responda desde memoria paramétrica.
Cablea el payload de escalación. escalation-schema.json define la nota interna que Decagon escribe en el handoff: intención detectada, qué preguntó el cliente en una línea, qué intentó y descartó ya el agente, links de KB relevantes, sentimiento del cliente y la razón de la escalación. Mapea estos a campos de Zendesk y a una vista de triage para que el humano receptor abra un ticket que ya está triado.
Corre la suite de aceptación de 12 casos. _README.md trae doce tickets canary —seis que deben resolverse (estado de pedido limpio, reseteo de contraseña, link de factura) y seis que deben escalar (una exigencia de reembolso, un reporte de seguridad, una cancelación enojada, un mensaje ambiguo multi-intención, un how-to fuera del allowlist, un caso borde en idioma no inglés). El agente pasa solo si los seis se resuelven limpiamente y los seis escalan con un payload completo. No habilites la auto-respuesta en tráfico en vivo hasta que la suite esté en verde.
Sombra, luego sal en vivo. Corre el agente en modo solo-borrador por tres a cinco días hábiles: compone respuestas y notas de escalación pero un humano aprueba cada envío. Revisa los borradores, ajusta el allowlist y los guardrails, después cambia las intenciones del allowlist a auto-resolución mientras todo lo demás se queda humano.

Qué hace el agente en realidad

Por cada ticket entrante, el agente primero clasifica la intención contra el allowlist. Si la intención no está en el allowlist, se detiene de inmediato y escala —sin intento de respuesta, sin respuesta parcial. Si está en el allowlist, recupera la fundamentación (artículos de KB más cualquier resultado de tool que la intención permita) y autoevalúa si esa fundamentación realmente responde la pregunta. El orden clasificar-primero, fundamentar-segundo importa: clasificar después de redactar tienta al modelo a justificar una respuesta que ya escribió, que es exactamente como pasan las respuestas confiadamente-equivocadas.

Cuando está fundamentado, compone una respuesta restringida por el guardrail de la intención y la postea. Cuando no está fundamentado —el artículo no cubre el caso borde, la tool devolvió un error, el mensaje del cliente abarca dos intenciones— escala con el payload completo de escalation-schema.json en vez de responder parcialmente. Los mensajes multi-intención siempre escalan; el template se rehúsa deliberadamente a partir un ticket y resolverlo a medias, porque la mitad que resuelve entrena al cliente a desconfiar de la mitad que pateó.

El handoff es la parte que gana confianza internamente. Un humano que toma un ticket escalado ve la intención detectada, el resumen de una línea, los pasos que el agente ya descartó, el KB que consultó y la lectura de sentimiento. Eso es estrictamente más contexto que un ticket ruteado en frío por un humano, que es el argumento que gana el buy-in del support lead: las escalaciones no son fallas, son tickets pre-triados.

Realidad de costos

Decagon cobra por volumen de resolución (custom, típicamente una platform fee más una tarifa por resolución; pide cotización —el precio público por unidad no se publica, trata cualquier cifra como estimado hasta que te coticen). El framing honesto para el business case: modela el costo por ticket contenido contra tu costo humano fully-loaded por ticket, que la mayoría de las organizaciones de soporte ubican en aproximadamente $5-15 dependiendo de región y complejidad. La contención solo ahorra dinero cuando el ticket contenido habría consumido un humano de otra forma; un ticket que el cliente habría auto-servido de todos modos no es un ahorro.

El costo del setup es de una a dos semanas del tiempo de un support lead, cargado al frente en la curación del allowlist y la limpieza del KB. El costo continuo es de aproximadamente dos a cuatro horas por semana de revisión de transcripciones durante los primeros dos meses, decreciendo a medida que el allowlist se estabiliza. No te saltes la revisión: un agente sin revisar deriva a medida que tu producto y tus políticas cambian debajo de él.

Cómo se ve el éxito

Vigila cuatro números. Primero, tasa de resuelto-sin-reapertura en las intenciones del allowlist —la métrica real de contención, no la deflexión cruda. Apunta por encima del 85% dentro de la porción del allowlist para la semana seis; las reaperturas significan que el agente está respondiendo cosas que debería escalar. Segundo, CSAT en tickets resueltos por el agente versus resueltos por humano —debería estar dentro de unos pocos puntos, no más bajo; un gap significa que los guardrails están demasiado flojos o el KB es delgado. Tercero, completitud del payload de escalación —muestrea tickets escalados semanalmente y confirma que el humano receptor no tuvo que re-preguntarle al cliente contexto que el agente ya tenía. Cuarto, tasa de falsa-escalación —escalaciones que un humano resolvió en un solo toque usando solo info del allowlist, lo que significa que el agente podría haberlo manejado; si esto sube, la compuerta de confianza es demasiado conservadora y puedes ampliar intenciones específicas.

Versus las alternativas

Versus el bot nativo de Zendesk y Advanced AI (copiloto de agente, intelligent triage). La IA integrada de Zendesk es la opción de menor fricción si ya pagas por ella y tus necesidades son sugerencia-y-triage en vez de resolución autónoma completa. Es excelente ruteando y redactando sugerencias de cara al agente. La razón para alcanzar Decagon en su lugar es la profundidad de resolución autónoma y el modelo de guardrail por intención —la IA nativa de Zendesk mejora rápido pero la disciplina de allowlist-más-compuerta-de-confianza de la que depende este template es más controlable en un agente de resolución hecho a propósito. Si solo necesitas triage y sugerencias de respuesta, quédate nativo; si necesitas resolución autónoma auditada sobre una porción definida, el agente dedicado gana la integración.

Versus Forethought. Forethought es el competidor directo más cercano para resolución autónoma sobre una columna vertebral de ticketing, y la elección es genuinamente cerrada. Forethought tiende a ser el pick cuando tu prioridad son sus analíticas de discovery/triage y quieres un empaquetado nativo-de-Zendesk apretado; Decagon tiende a ganar cuando la calidad de resolución conversacional y el control del diseño del agente son la prioridad. Evalúa ambos contra tu propio allowlist con la misma suite de 12 casos —el diferenciador es cuál resuelve tus intenciones limpiamente, no el demo.

Versus un agente DIY sobre APIs de LLM crudas más la API de Zendesk. Un agente casero te da control total y el menor costo marginal por resolución, pero reconstruyes lo que Decagon entrega: fundamentación por retrieval, estado de conversación, analíticas, enforcement de guardrails y la consola de operaciones que un support lead usa sin escolta de ingeniería. Elige DIY solo si tienes un equipo de plataforma permanente y la resolución es lo bastante central como para ser dueño de ella; de lo contrario el costo de construir-y-mantener empequeñece la licencia. El allowlist y el schema de escalación del template son portables —si terminas yendo DIY después, te quedas con el diseño y cambias el motor.

Stack

Decagon —el agente de resolución autónoma: clasificación de intención, fundamentación por retrieval, enforcement de guardrails, estado de conversación, analíticas
Zendesk —sistema de ticketing de record, Help Center como fuente de conocimiento, destino para respuestas públicas, notas internas de escalación y tags
Forethought —el agente de resolución alternativo nombrado para hacer bake-off contra tu propio allowlist
Webhooks de pedido/facturación —tool calls de solo-lectura que las intenciones del allowlist tienen permitido hacer (consultas de estado y factura, nunca escrituras)

Editar esta página en GitHub