AI workflows face a fundamental conflict between the infrastructure needed for reliable production use and the speed required to test output quality, according to a technical pattern published by InfoQ in a report documenting Brex's workflow platform architecture. The article, written by Brex software engineer Mateus Moury, describes how teams can write workflow logic once and run it unchanged across both heavyweight production systems and lightweight evaluation loops. The solution treats orchestration as pure business logic that doesn't know where it executes, letting the same code operate in production durability engines and fast local testing environments without modification.
Production systems running AI workflows need persistence at every step so work survives crashes, deployments, and worker restarts—capabilities that workflow engines solved years ago. Evaluation loops pull in the opposite direction, demanding cheap, in-process runs that execute hundreds of times per hour to check how prompt changes or model updates affect output quality. The report explains that durability-first runtimes offer test environments, but those sandboxes require standing up task queues and test servers for evaluation loops that need none of that infrastructure. Most technology stacks force teams to pick one runtime or the other, coupling orchestration directly to frameworks like LangGraph and Mastra or to engines like Temporal. When orchestration lives inside a single framework, evaluating that logic means running the entire framework, and switching runtimes requires rewriting the workflow.
The Brex platform, maintained by five engineers and running on Kubernetes with Temporal Cloud, implemented runtime-agnostic orchestration by writing workflows as plain TypeScript functions against a typed Steps interface. According to the report, the orchestration depends only on an interface naming the agent's meaningful operations—no Temporal imports, no evaluation framework code, no Node.js built-ins. Side effects live in concrete Steps implementations that receive dependencies through injection: in production, plugins hit real services, while in evaluation runs, plugins return fixture data. The report states that this approach removed eval-production skew by construction, since the orchestration evaluated is byte-for-byte identical to the one shipped. Two adapters carry the implementation load: a Temporal adapter that maps each Steps method to a durable activity and runs orchestration in a deterministic sandbox, and an in-process evaluation adapter that runs the same orchestration with plugins returning fixtures instead of calling external services.
The pattern works because it enforces portability through architecture rather than developer discipline. The report explains that orchestration must avoid hidden non-determinism—no wall-clock reads, random values, or direct input-output operations—and cannot import Node.js or runtime-specific APIs. Anything non-deterministic becomes a Steps method where the runtime takes control, and anything that ties code to a specific process model belongs in the concrete implementation, never in the orchestration or interface. This constraint makes the portable shape the path of least resistance: the defineAgentHandle function gives developers nothing but steps and input, so the natural way to write an agent is already correct. If orchestration accidentally depends on a Node-only module, the build fails, providing enforcement at compile time. The architecture delivered measurable reliability gains for Brex's long-running agents, which take twenty to sixty minutes and span dozens of language model and tool calls. Under the old setup, roughly four percent of runs never completed because pod recycles, deploys, or timeouts anywhere in the execution would wipe all progress. The report states that after adopting the Temporal adapter, completion held at 99.9 percent over recent months, because when a worker dies mid-run, Temporal replays history and resumes at the last completed step.
The design carries costs that the report presents as deliberate trade-offs. Orchestration loses direct access to runtime-native features like Temporal signals, queries, or timers, since those primitives don't exist in the evaluation runtime. Exposing new capabilities requires designing them into the interface and implementing them across all adapters, turning simple additions into platform-wide changes. Visual tooling that framework-native graph visualizers and step debuggers provide also disappears, because those tools assume workflows are written to their specific model. The report concludes that the pattern earns its value when projects have more than a few workflows, genuine production-durability requirements, and a serious evaluation practice. For platforms hosting fleets of agents making regulated decisions, treating the runtime as a plugin behind an interface lets production reliability and evaluation velocity stop fighting each other. The approach also made runtime choices reversible—switching between Temporal or Restate for execution, or between Braintrust, Laminar, or LangSmith for evaluations, became adapter swaps rather than rewrites. Organizations building AI agent platforms may find themselves forced to choose between architectural flexibility now and vendor constraints later, while those treating infrastructure as disposable risk discovering too late that reliability gaps compound faster than feature velocity can paper over them.