Brex publicou um padrão para executar o mesmo código de workflow de IA tanto através do Temporal Cloud em produção quanto de um harness de eval leve in-process sem duplicação de código. Um time de cinco engenheiros TypeScript construiu essa abordagem porque seus agents rodam por uma hora através de dezenas de chamadas LLM, tornando o desvio eval-produção caro e arriscado.
O problema é estrutural. Engines de workflow duráveis como Temporal persistem cada resultado de passo, reproduzem histórico após crashes e impõem determinismo rigoroso: sem `Date.now()`, sem I/O direto dentro de orquestração, limites rigorosos de tamanho de payload. Essa maquinaria funciona bem para agents de onboarding de longa duração que não podem perder quarenta minutos de progresso após um recycle de pod. Mas quebra evals—execuções offline contra datasets rotulados para detectar regressões. Você herda persistência, filas de tarefas, workers e semântica de replay para um loop que não precisa de nada disso. O loop deve ser local, efêmero, barato o suficiente para rodar centenas de vezes por hora.
A alternativa dominante cria uma armadilha diferente. Frameworks como LangGraph e Mastra expressam orquestração diretamente em seus próprios SDKs. A lógica de orquestração e o framework são o mesmo artefato. Para fazer eval da lógica, você roda o framework. Para implementar, você roda o mesmo framework. Não existe versão da orquestração independente do runtime. A abordagem antiga da Brex era reimplementar agents em um runtime de eval separado—duas cópias da mesma lógica, garantidamente divergindo.
Solução da Brex: escrever o workflow como lógica de negócio pura sem conhecimento de onde ele roda, depois injetar um adapter de runtime no momento da execução. Em produção, o adapter se conecta ao Temporal Cloud via workers no cluster Kubernetes da Brex. Em evals, ele se conecta a um runner in-process leve na plataforma de eval interna deles. Chamadas LLM são roteadas através do Vercel AI SDK para um LLM Gateway interno que centraliza rate limiting e autenticação. Uma versão da orquestração existe. Tudo que passa por eval corresponde ao que é implementado, eliminando uma classe de bugs de desvio de código.
Enforcement é arquitetural, não disciplinar. O time construiu a restrição no sistema de build: se um desenvolvedor escreve código de orquestração dependendo de features específicas do runtime, o build falha. A pressão para usar primitivos nativos de Temporal é constante—eles são poderosos e tentadores. A camada agnóstica falha se depender de desenvolvedores individuais se manterem dentro dela.
O custo é real. Desacoplamento significa que orquestração perde acesso direto a features nativas do runtime. Cada nova capacidade além do denominador comum entre produção e eval tem que ser re-exposta através da interface agnóstica. Esse overhead de wiring é trabalho de engenharia real. O padrão só compensa se um time genuinamente precisa tanto de durabilidade em produção quanto de avaliação rápida offline no mesmo caminho de código. Times rodando agents mais curtos ou tolerando implementações separadas de eval e produção não devem pagar esse custo.
Stack da Brex: TypeScript, Kubernetes, Temporal Cloud, Vercel AI SDK, um LLM Gateway interno e uma plataforma de eval interna. Cinco engenheiros possuem a plataforma.
A decisão: se seus agents rodam tempo suficiente para que recycle de pod seja um modo de falha, e sua cadência de eval é frequente o suficiente para que overhead de framework diminua a iteração, esse padrão remove a escolha forçada entre durabilidade e velocidade. Orce pela wiring do adapter que ele substitui.