Artículo extenso publicado en X el 11 de agosto de 2026 por Jesse Zhang, CEO de Decagon (agentes de IA para atención al cliente).

La observación inicial. El Forward Deployed Engineer se ha convertido en la respuesta por defecto a cualquier dificultad de go-to-market en IA: despliegues dolorosos, clientes incapaces de autoservirse, producto no listo. Anthropic y OpenAI han construido brazos de despliegue empresarial explícitamente calcados de Palantir; las ofertas de empleo con ese título habrían aumentado varios cientos por ciento en un año. Sin embargo, señala Zhang, hasta hace poco esto era un motivo de crítica —ingresos de menor calidad, márgenes estructuralmente limitados— y « nothing about the underlying economics has changed ». Lo que ha cambiado: en la era de la IA, las empresas no conocen el camino hacia el resultado pero creen en el resultado, y el FDE entrega el resultado.

If your FDEs are eating pain and excreting more pain, you don't have an FDE team. You have a services business.

**Jesse Zhang** — cofondateur et **CEO de Decagon** , x.com

El precedente Palantir. Shyam Sankar, CTO: « FDEs eat pain and excrete product. » Joe Lonsdale reconoce que la reputación de «consultora disfrazada» se apoyaba en una observación certera. Los despliegues a medida de Gotham se codificaron en primitivas —ontología, modelos de objetos, permisos, motores de flujo de trabajo, trazabilidad de procedencia— que dieron lugar a Foundry, luego Apollo y AIP. Con la estandarización, el margen bruto subió a la franja del 80% y Palantir dejó atrás el modelo de FDE. « The pain was the input to the product, not a cost of sale. »

La tesis. Enviar ingenieros se justifica cuando la categoría es nueva: un agente contable en 2026 no tiene un flujo de trabajo establecido, y el cliente ni siquiera puede describirlo. Pero una vez conocidos los caminos, hay que retirar a los FDE —y nadie querrá hacerlo—, porque conservarlos resulta más fácil sprint tras sprint: nunca hay que zanjar un compromiso de producto, decir que no, ni tomar una decisión de arquitectura dolorosa. Eso deja todos los inconvenientes del modelo sin el beneficio del descubrimiento. Zhang distingue además FDE de implementación: uno descubre una especificación desconocida, el otro ejecuta una conocida; confundir ambas cosas permite que una organización de servicios pase por una inversión de producto.

El caso Decagon. Un enfoque deliberadamente orientado a producto, impulsado por dos exigencias constantes de las empresas: velocidad de iteración y rechazo del vendor lock-in. Coste: convertir las escaladas en requisitos en lugar de parches. Beneficio autodeclarado: « two-thirds of deployment work » ahora realizado de forma autónoma mediante Duet, y « a few days » para lanzar el primer AOP en grandes bancos, aerolíneas o telecos. Cifras sin definir y no verificables.

La frase de cierre: « If your FDEs are eating pain and excreting more pain, you don't have an FDE team. You have a services business. »