Brex publicó un patrón para ejecutar el mismo código de workflow de IA tanto a través de Temporal Cloud en producción como de un harness de eval ligero in-process sin duplicación de código. Un equipo de cinco ingenieros TypeScript construyó este enfoque porque sus agents se ejecutan durante una hora a través de docenas de llamadas LLM, haciendo que la desviación eval-producción sea costosa y riesgosa.

El problema es estructural. Engines de workflow duraderos como Temporal persisten cada resultado de paso, reproducen historial después de crashes e imponen determinismo estricto: sin `Date.now()`, sin I/O directo dentro de orquestación, límites estrictos de tamaño de payload. Esta maquinaria funciona bien para agents de onboarding de larga duración que no pueden perder cuarenta minutos de progreso después de un recycle de pod. Pero rompe evals—ejecuciones offline contra datasets etiquetados para detectar regresiones. Heredas persistencia, colas de tareas, workers y semántica de replay para un loop que no necesita nada de eso. El loop debe ser local, efímero, lo suficientemente barato para ejecutarse cientos de veces por hora.

La alternativa dominante crea una trampa diferente. Frameworks como LangGraph y Mastra expresan orquestación directamente en sus propios SDKs. La lógica de orquestación y el framework son el mismo artefacto. Para evaluar la lógica, ejecutas el framework. Para implementarlo, ejecutas el mismo framework. No existe versión de la orquestración independiente del runtime. El enfoque anterior de Brex era reimplementar agents en un runtime de eval separado—dos copias de la misma lógica, garantizado que divergen.

Solución de Brex: escribir el workflow como lógica de negocio pura sin conocimiento de dónde se ejecuta, luego inyectar un adapter de runtime en el momento de la ejecución. En producción, el adapter se conecta a Temporal Cloud vía workers en el cluster Kubernetes de Brex. En evals, se conecta a un runner in-process ligero en su plataforma de eval interna. Las llamadas LLM se enrutan a través del Vercel AI SDK hacia un LLM Gateway interno que centraliza rate limiting y autenticación. Existe una versión de la orquestración. Lo que sea que pase por eval coincide con lo que se implementa, eliminando una clase de bugs de desviación de código.

Enforcement es arquitectónico, no disciplinario. El equipo construyó la restricción en el sistema de build: si un desarrollador escribe código de orquestración dependiendo de features específicas del runtime, el build falla. La presión de usar primitivos nativos de Temporal es constante—son poderosos y tentadores. La capa agnóstica falla si depende de que desarrolladores individuales se mantengan dentro de ella.

El costo es real. Desacoplamiento significa que orquestración pierde acceso directo a features nativas del runtime. Cada nueva capacidad más allá del denominador común entre producción y eval debe ser re-expuesta a través de la interfaz agnóstica. Este overhead de wiring es trabajo de ingeniería real. El patrón solo compensa si un equipo genuinamente necesita tanto durabilidad en producción como evaluación rápida offline en el mismo camino de código. Equipos ejecutando agents más cortos o tolerando implementaciones separadas de eval y producción no deberían pagar este costo.

Stack de Brex: TypeScript, Kubernetes, Temporal Cloud, Vercel AI SDK, un LLM Gateway interno y una plataforma de eval interna. Cinco ingenieros poseen la plataforma.

La decisión: si tus agents se ejecutan lo suficiente para que recycle de pod sea un modo de fallo, y tu cadencia de eval es lo suficientemente frecuente para que el overhead de framework ralentice la iteración, este patrón elimina la elección forzada entre durabilidad y velocidad. Presupuesta el wiring del adapter que reemplaza.