Decagon vs Forethought

Decagon y Forethought prometen la resolución autónoma de tickets de soporte con IA — no copilotos que sugieren respuestas, sino agentes que cierran la conversación y escalan solo lo que no pueden resolver. Los equipos que eligen entre ambos son organizaciones de soporte enterprise y upper-mid-market que deciden qué capa de IA poner frente al volumen de tier-1 para que los CSM humanos dejen de quemar horas en restablecer contraseñas. La división central es doble. Primero, la arquitectura: Decagon apuesta por un único motor de agente impulsado por Agent Operating Procedures (AOPs) en lenguaje natural que ejecutan acciones reales en el backend; Forethought ofrece un stack multiagente (Solve, Triage, Assist, Discover, Agent QA) con modelos por cliente entrenados sobre tu historial de tickets. Segundo, y más decisivo para los compradores de 2026: Forethought ahora es un producto de Zendesk — Zendesk lo adquirió en marzo de 2026 — mientras que Decagon sigue siendo un proveedor independiente. Ese hecho de propiedad reconfigura la decisión más que cualquier comparación de funciones.

Donde gana Decagon

• Ejecución de acciones vía AOPs. El diferenciador de Decagon es que equipos de CS y operaciones de soporte no técnicos redactan workflows de múltiples pasos en lenguaje natural, y el agente ejecuta acciones reales — procesar un reembolso, verificar identidad, cambiar un pedido, cancelar una suscripción — no solo responder preguntas de la base de conocimiento. Solve de Forethought resuelve de extremo a extremo usando tus políticas y contenido, pero la capa de AOP de Decagon es el camino más directo a “el agente hizo la acción” en lugar de “el agente respondió sobre la acción”.
• Sin piso de datos. Decagon no requiere un corpus de tickets históricos para entrenar modelos por cliente. Forethought recomienda 20.000+ tickets históricos y ~2.000+ tickets/mes antes de que sus modelos rindan; por debajo de eso la IA rinde menos y los números por resolución se invierten. Si tienes conocimiento y workflows ricos pero un historial de tickets escaso, Decagon empieza a producir resolución sin una barrera de entrenamiento.
• Multicanal con contexto compartido, incluida la voz. Decagon corre chat, email, SMS y voz (construida con ElevenLabs) sobre una única capa centralizada de conocimiento y workflow con memoria entre canales — un cliente que empezó en chat no tiene que volver a explicar en una llamada. Solve de Forethought también cubre chat, email y voz, pero la memoria entre canales y la madurez de voz de Decagon están más avanzadas.
• Independencia del proveedor. Decagon es un producto autónomo con un roadmap que controla. Para un equipo que no usa Zendesk y no quiere que su capa de soporte con IA quede absorbida en la estrategia de plataforma de un proveedor de help desk, esa independencia es una ventaja.

Donde gana Forethought

• First-party sobre Zendesk. Si ya usas Zendesk o te estás moviendo hacia él, Forethought ahora es first-party (“Forethought AI Agents by Zendesk”) y la deuda de integración es la más baja. Los agentes Triage, Assist y Agent QA encajan en el help desk que ya operas. Decagon se integra con Zendesk pero es una capa de terceros encima.
• Triage y la capa de señal de CS. Triage de Forethought auto-clasifica y enruta el inbound a escala, produciendo datos de tickets limpios y etiquetados que CS y RevOps conectan a modelos de riesgo de churn y NRR aguas abajo. Decagon está construido para deflectar y resolver; Triage de Forethought está diseñado específicamente para alimentar la capa de señal sobre la que corre el forecasting de retención.
• Agent-assist en una sola plataforma. Assist de Forethought es un copiloto dentro del help desk para los tickets que sí llegan a un humano, y Agent QA puntúa el 100% de los tickets de agentes humanos automáticamente. Decagon se enfoca en la resolución autónoma; si quieres resolución autónoma más copiloto para agentes humanos más QA de un solo proveedor, el stack de Forethought es más amplio.
• Bucle de autoaprendizaje. El Resolution Learning Loop de Forethought detecta brechas en los workflows, redacta nuevos procedimientos y los prueba antes del despliegue. Watchtower (QA siempre activo) y Experiments (testing A/B en vivo) de Decagon cubren el monitoreo y el ajuste, pero el bucle de Forethought apunta más explícitamente a cerrar brechas de forma automática — la capacidad por la que Zendesk pagó.

Realidad de pricing

Ambos son custom, solo por cotización, sin un tier self-serve público — y ambos cargan con pisos enterprise capaces de seis cifras. La estructura reportada de Decagon es una tarifa anual de plataforma de unos $50.000 más uso, cobrado por conversación o por resolución (reportadamente alrededor de $0,50/resolución), con mínimos de conversación en los contratos enterprise; el gasto anual mediano reportado queda materialmente por encima de la tarifa de plataforma una vez que se cuenta el volumen. Los datos de marketplace de terceros (Vendr) de Forethought ubican los contratos anuales aproximadamente en el rango de $36K–$151K, con mediana cerca de $75K/año, según el volumen de tickets, el número de agentes, los canales y qué agentes habilitas. A un alcance comparable de volumen medio, ambos caen en la misma banda; la diferencia no es el titular. La trampa de costos es distinta para cada uno: la de Decagon es el piso de la tarifa de plataforma (peso muerto por debajo de unos pocos miles de conversaciones/mes); la de Forethought es el piso de datos (pagas tarifas enterprise mientras el modelo no tiene nada con que entrenar por debajo de ~20K tickets históricos).

Esfuerzo de implementación

Ninguno es un interruptor que enciendes. La implementación de Decagon es un proyecto: redactas los AOPs, conectas integraciones (Salesforce, Intercom, Zendesk, Kustomer) y ajustas durante semanas antes de que la deflexión llegue a donde prometió el deck — presupuesta tiempo de CS-ops, no solo la licencia. Forethought añade un prerrequisito duro encima del trabajo de integración: el piso de datos. Por debajo de ~20.000 tickets históricos los modelos por cliente son débiles, así que el piloto tiene que superar un umbral medido de tasa de resolución antes de que el despliegue completo tenga sentido. La rampa de Decagon está limitada por la rapidez con que puedes redactar workflows; la de Forethought está limitada tanto por la configuración de workflows como por si tu historial de tickets es lo bastante profundo para entrenar. Si usas Zendesk, el cableado de Forethought es más liviano; si no, consigue un compromiso por escrito sobre los plazos de soporte multiplataforma antes de firmar multianual, porque el roadmap autónomo está siendo absorbido por el Resolution Platform de Zendesk.

Conclusión

• Elige Decagon si necesitas que el agente ejecute acciones reales en el backend (reembolsos, cambios de cuenta) vía AOPs en lenguaje natural, no usas Zendesk, tienes un historial de tickets escaso pero conocimiento/workflows sólidos, o quieres una capa autónoma con capacidad de voz de un proveedor que controla su propio roadmap.
• Elige Forethought si ya estás en Zendesk (la deuda de integración es la más baja como producto first-party), tienes los 20.000+ tickets históricos para entrenar, o quieres resolución autónoma más agent-assist más Triage alimentando tus modelos de NRR desde una sola plataforma.
• No elijas ninguno si haces menos de 20.000 tickets/año o solo unos pocos miles de conversaciones al mes. Ambos cargan con pisos enterprise que no se amortizan a ese volumen — Intercom y su agente Fin (pago por resolución, sin piso de volumen) entregan más valor por dólar en esa banda. Y recuerda que ninguna de las dos herramientas retiene: empareja a la ganadora con una plataforma de CS de registro — Gainsight, Totango o ChurnZero — que sea dueña de los health scores, las renovaciones y la expansión.

Si estás eligiendo sin las condiciones anteriores, elige Decagon. La independencia del proveedor más la ausencia de piso de datos lo convierten en el default de menor riesgo en 2026, mientras el roadmap de Forethought está a medio absorber por Zendesk. Cambia a Forethought cuando estandarices sobre Zendesk y la integración first-party se vuelva determinante.