Orkes CTO's playbook for building durable AI agents with workflow engines

Most AI agents are brittle, state-lossy loops. Orkes CTO Virein Baraiya proposes a durable runtime architecture using workflow engines like Netflix Conductor to separate agent reasoning from execution.

Most AI agents built today are brittle. They operate in a simple 'LLM in a loop' sandbox, where a crash or network timeout erases all memory and progress. For tasks lasting more than a few minutes, this model fails. Orkes CTO Virein Baraiya, in a technical talk, argues for a different architecture: a durable runtime that separates an agent's reasoning from its execution, making long-running, recoverable AI processes possible.

The failure of memory-based loops

The standard approach of running an agent in a memory-based loop has critical production flaws, according to Baraiya. First, it cannot handle long-running tasks. An agent workflow that needs to wait days for human approval or run for weeks cannot feasibly occupy a sandboxed process, consuming CPU and memory resources indefinitely. The talk notes this is a primary source of inefficiency.

Second, these systems lack crash recovery. If the process fails, the agent's state and context are lost completely. There is no mechanism to resume from the point of failure. Finally, coordinating multiple agents running in isolated sandboxes requires complex networking and retry logic, adding significant engineering overhead.

Separate reasoning from execution

The proposed solution is an architectural separation of concerns. The LLM's role is restricted to reasoning and planning. It generates a plan, such as “call the weather API for Boston,” but does not execute it directly. The actual execution is handled by a durable runtime system, which treats the agent's plan as a step in a persistent workflow.

This model reframes an AI agent as a dynamically constructed workflow, or what Baraiya calls a “late-bound Saga.” Unlike traditional, statically defined workflows, the agent builds the execution graph as it runs. Each step, whether an LLM call or a tool execution, is recorded in a persistent ledger. The core architectural shift is separating the agent's reasoning from its execution.

The Conductor and Agent Span stack

To implement this, Baraiya points to two open-source projects. The foundation is Netflix Conductor, a microservice workflow orchestrator he co-created at Netflix and which his company Orkes now maintains. Conductor acts as the durable runtime, using a database like Postgres to log every step of the agent's process. If a task requires a six-month wait for human input, Conductor can pause the workflow and release all compute resources, resuming precisely where it left off when triggered.

Built on top is Agent Span, a runtime designed to translate definitions from popular agent SDKs into Conductor workflows. Baraiya claims it can take agents built with one of eleven different frameworks, including LangGraph and the OpenAI Agents SDK, and run them on the durable backend without requiring business logic changes.

What we'd change

This architecture introduces significant operational overhead. Deploying and managing a workflow engine like Conductor, along with its database dependencies, is a heavy lift for early-stage teams prototyping new agents. The trade-off is clear: speed of iteration for production-grade reliability. This playbook is for scaling, not for initial discovery.

The solution is also presented by the CTO of Orkes, the company commercializing a managed version of Conductor. While the architectural principles are sound, alternative workflow engines like Temporal or Camunda could serve the same purpose. The key takeaway is the pattern of separating reasoning and execution, not the specific tool choice.

Finally, the claim that Agent Span can run agents from any major SDK with “no code changes” warrants skepticism. Such abstraction layers often handle common cases well but can struggle with complex error handling or state management logic specific to an application. Teams should budget for integration work rather than assuming a frictionless drop-in solution.

Landing

The move from sandboxed loops to durable runtimes reflects a broader maturation in the AI agent space. It mirrors the historical shift from fragile monolithic scripts to robust, observable microservice architectures. As agents move from demos to handling real business processes, auditability, security guardrails, and crash recovery become non-negotiable. For founders building agents for enterprise or mission-critical workflows, this architectural pattern is not an option. It is a baseline requirement for building a reliable product.

The investor read

This playbook signals the maturation of the AI agent market, moving from fragile demos to a need for enterprise-grade infrastructure. The value is shifting to the 'picks and shovels' that enable reliable, auditable, and long-running agents. Companies like Orkes (commercializing Conductor) and competitors like Temporal are creating a new, investable infrastructure layer. The key diligence question is whether generalized workflow engines are the right abstraction or if a new, agent-native runtime will ultimately win. This trend suggests 'AI agent' may become a feature, with the durable runtime that powers it becoming the more valuable, defensible product.

Pull quote: “The core architectural shift is separating the agent's reasoning from its execution.”