El titular 'semanas a horas' oculta una reescritura de flujo de trabajo
La aceleración del análisis de requisitos impulsada por Codex de Endava recibe cobertura entusiasta: semanas comprimidas en horas, analistas liberados del trabajo tedioso, la organización agentic finalmente llegando. Pero ese enfoque pierde la verdadera historia de ingeniería. Lo que Endava entregó no fue un agente más inteligente. Fue un flujo de trabajo—en el sentido estricto: un patrón orquestado y repetible de tareas con entradas tipadas, salidas, reintentos deterministas y compuertas humanas explícitas.
El malentendido común es que los agentes reemplazaron a los analistas. La realidad es más mundana. Endava descompuso "analizar requisitos" en un gráfico de pasos estrechos y comprobables: ingerir documentos, extraer entidades, agrupar requisitos, detectar conflictos, redactar historias de usuario, exponer resúmenes para aprobación del revisor. Cada nodo tiene un esquema de entrada definido y un esquema de salida. Cada nodo puede fallar independientemente y reintentarse. Cuando un paso produce basura, sabes dónde buscar.
El término "organización agentic" se ha convertido en jerga de marketing que oscurece la deuda de orquestación. Hemos entregado suficientes de estos sistemas para saber: la aceleración no viene de que el agente sea más inteligente. Viene de que el flujo de trabajo sea más simple—ventanas de contexto más estrechas, superficies de decisión más pequeñas, caminos deterministas con compuertas HITL colocadas quirúrgicamente donde el costo de deshacer la salida es alto. Ese es trabajo de ingeniería. Ese es el trabajo que nadie acredita en el titular.
La descomposición de tareas es el trabajo que nadie acredita
Si puedes describir el trabajo como un diagrama de flujo con entradas y salidas claras, tienes la forma de un flujo de trabajo descomponible. La descomposición de Endava es directa: ingesta de documentos → extracción de entidades → agrupación de requisitos → detección de conflictos → redacción de historias de usuario → compuerta de revisor. Cada nodo es lo suficientemente pequeño para que una única llamada LLM lo resuelva. Cada nodo genera un esquema tipado—JSON, no prosa narrativa que necesite análisis descendente.
Por qué importa: un único "agente analista" con un mega-prompt falla en el quinto o sexto salto. El presupuesto de tokens explota. El modelo comienza a alucinar contexto desde antes en la conversación. Los fallos se vuelven costosos de diagnosticar porque toda la cadena está entrelazada. Divídelo en nodos, y puedes probar cada uno independientemente. Puedes escribir pruebas unitarias. Puedes construir arneses de evaluación por nodo—medir la recuperación de entidades extraídas, la precisión de requisitos agrupados, la tasa de falsos positivos en detección de conflictos. No puedes hacer pruebas unitarias de vibraciones.
La regla general que seguimos: si no puedes escribir una prueba para el nodo, el nodo es demasiado grande. Divídelo. Un nodo que dice "analiza esta entrada vaga y averigua qué hacer" no es un nodo. Un nodo que dice "dada una lista de objetos de requisitos con un esquema conocido, detecta conflictos lógicos y devuelve pares de conflictos con puntuaciones de confianza" es un nodo.
Las ventanas de contexto son un presupuesto, no una característica
La tentación es obvia. Tienes una ventana de 200K tokens. Solo pega el documento de requisitos completo, toda la base de código, cada análisis anterior—deja que el modelo lo averigüe. Así es como terminas con latencias p50 de 30 segundos, $0,80 por llamada, y recuperación que se degrada misteriosamente en producción.
Apuntamos a 4–12K tokens de entrada por llamada, p50 sub-2-segundo para pasos interactivos. Eso fuerza disciplina. Un nodo de detección de conflictos no necesita el PRD completo. Necesita: los pares de requisitos siendo comparados, sus metadatos, y quizás los documentos fuente de los que vinieron. La recuperación está limitada por nodo. Preguntas: ¿qué necesita realmente este paso para tener éxito? Respondes con una ventana de contexto pequeña y curada.
Cuando necesitas llevar información adelante entre nodos, resúmela. No lleves la transcripción sin procesar. Un nodo de extracción de requisitos genera no el texto del documento completo sino una lista estructurada de requisitos extraídos. El nodo de agrupación funciona desde esa lista, no desde el documento original. Los nodos descendentes reciben los resúmenes, no los artefactos de diez saltos atrás. Aquí es donde los sistemas RAG a menudo fallan en producción—recuperan demasiado contexto demasiado ampliamente, esperando que la recuperación los salve. La recuperación limitada por nodo es más lenta de diseñar y más rápida de ejecutar.
Reintentos, idempotencia y colas de letra muerta—la capa de confiabilidad poco sexy
Aquí es donde hemos cometido errores antes, y es instructivo. Un flujo de trabajo LLM que no maneja fallos como una preocupación de primera clase fallará silenciosa o ruidosamente en producción, y depurarás a las 2am.
El retroceso exponencial con jitter en 429 y 5xx de las APIs de OpenAI o Anthropic es lo básico. Pero necesitas claves de idempotencia por nodo—un hash determinista del ID del paso y la entrada—para que un reintento no cree duplicadamente tickets de Jira o duplique historias de usuario. Necesitas salidas estructuradas: modo JSON o llamadas de herramientas, no análisis de texto libre. Un fallo de análisis se convierte en un error tipado que puedes agrupar y reintentar, no un misterio.
Y necesitas una cola de letra muerta (Redis Streams, SQS, o Postgres con SKIP LOCKED) para entradas tóxicas—documentos tan malformados que ninguna cantidad de reintentos los arreglará. Los humanos clasifican la cola. Algunas entradas se reprocesarán una vez que arregles la ingesta ascendente. Algunas se rechazarán. Sin esto, los flujos de trabajo acumulan basura atrasada.
Los IDs de paso deterministas importan también. Si un flujo de trabajo muere después de tres saltos y lo repites, quieres reanudar desde el paso cuatro, no reiniciar desde el paso uno. Eso requiere estado duradero—algo que persista qué nodos han ejecutado y qué generaron. Los marcos fuera de la caja como LangGraph envían la sintaxis DAG pero evitan el estado duradero. Integras Temporal, Inngest, o construyes tu propia máquina de estados en Postgres.
Las compuertas humanas en el bucle son arquitectura, no UX
La colocación de HITL no es una solicitud de característica. Es una decisión de diseño impulsada por el radio de explosión y los umbrales de confianza. Coloca compuertas donde el costo de deshacer es alto: antes de crear un ticket de Jira que se propague en un sprint, antes de que el código se fusione, antes de que un artefacto orientado al cliente se envíe. No coloques compuertas en saltos de bajo riesgo solo porque existan.
La aprobación con compuerta de confianza es el patrón: si la autoconsistencia o un modelo crítico puntúa la salida por encima de un umbral, apruébalo automáticamente. De lo contrario, encola para revisión humana. La UI de revisión expone diffs y evidencia—qué cambió desde la versión anterior, por qué el modelo cree que esto es correcto—no cadena de pensamiento sin procesar que los humanos no pueden actuar. Las operaciones manuales tienen un costo real, y cada compuerta que no colocas es trabajo que has reclamado.
Rastrea la tasa de anulación por nodo. Si los humanos están rechazando el 40% de las salidas del paso de detección de conflictos, la extracción de requisitos ascendente se está desviando. El prompt necesita atención. La recuperación es antigua. Los aumentos de anulaciones son una señal, no un fracaso del enfoque.
La aceleración de Endava vino de remover humanos de los saltos de bajo riesgo—ingesta de documentos, extracción de entidades, agrupación inicial. Las compuertas se quedaron donde el costo era real: antes de que un revisor viera los resúmenes finales, antes de que nada se enviara a los clientes. Eso no es remover humanos de los flujos de trabajo. Es enrutarlos donde importan.
Por qué los marcos de agentes fuera de la caja no lo entregan para ti
LangGraph, CrewAI, AutoGen—resuelven la sintaxis de orquestación. Obtienes un DSL limpio para definir tu DAG. El cableado de llamadas de herramientas funciona. La gestión básica de memoria está ahí. Ninguno de ellos entrega flujos de trabajo de producción confiables fuera de la caja.
Lo que falta: arneses de evaluación por nodo. Detección de desviación. Atribución de costo por paso. Reintentos duraderos que sobrevivan a un reinicio de proceso. Cuando cableamos estos sistemas para lo real, la superficie de integración se parece a Postgres para estado, Redis para colas, OpenTelemetry para trazas, un ejecutor de evaluación personalizado en tu pipeline de CI. Ese es el 80% del trabajo.
El despliegue de Microsoft Copilot o Codex dentro de una empresa es quizás 20% elección de modelo, 80% andamiaje de flujo de trabajo. Elige un marco que se salga de tu camino—uno que juegue bien con tu almacén de estado y cola existentes—luego presupuesta ingeniería real para la capa de confiabilidad. El enrutamiento de modelo y el tamaño del bucle de razonamiento importan, pero son refinamientos. La base es la estructura del flujo de trabajo.
Antes de escribir una línea de código de orquestador, mapea tu flujo de trabajo en una pizarra. Define los nodos. Dibuja los esquemas dentro y fuera. Marca dónde los humanos cierran el flujo. Cuenta los pasos. Pregúntate: ¿puedo probar esto? Si la respuesta es no, rediseña. Los agentes y flujos de trabajo se ven similares desde afuera—cuestan cantidades muy diferentes de mantener. La diferencia vive en cuán despiadadamente has descompuesto el problema y cuán explícitamente has manejado el fallo. Eso es de donde vino la aceleración de Endava. Ese es el trabajo que no cabe en un titular.