Brains vs Hands: How to Run AI Agents Safely in Production — Viren Baraiya
Viren Baraiya, CTO of Orkes and original creator of Netflix Conductor, explains why production agents behave like applications built from microservices. He argues for splitting the work between a non-deterministic LLM that plans and a deterministic, durable harness that executes, with approval gates, idempotent steps, and recorded side effects. He frames agent harnesses as late-bound sagas and demos an SRE remediation agent whose plan is compiled into a Conductor workflow.
Viren Baraiya, co-founder and CTO of Orkes and the original creator of Netflix Conductor, opens by asking who runs agents in production. Far more hands go up than at a conference a few weeks earlier, which suggests agents are moving past experimentation. He argues that the familiar hello-world agent, an LLM that picks a tool, uses some context or memory, and plans ahead, is far too narrow a picture of what production agents look like.
Agents beyond the chatbot
He describes four shapes production agents take:
- Background agents that run on a schedule, such as an agent that checks every hour whether something new has come up on a calendar.
- Event-driven agents that listen to streams like alerts and logs and react to them.
- Long-running coordinators that monitor another agent and decide whether to nudge it forward or change its course.
- Multi-agent systems in which agents talk to other agents. He warns against giving one agent many responsibilities, since that multiplies the risk of hallucination.
Once agents look like this, he argues they stop being components and become applications. He draws on the microservices lesson: nobody ships one service that does everything. Teams compose single-responsibility services through choreography or orchestration, and the application is the composition. His example is an SRE harness that listens to logging events, talks to a Kubernetes cluster through an agent, reads metrics and dashboards, and involves humans, with tools reached through APIs or MCP. His conclusion is that “the harness is the application” and that an agent alone does not deliver the business goal.
Mixing deterministic and non-deterministic parts
A harness combines two kinds of work. Non-determinism comes from the LLM’s reasoning. Some parts, such as payments or restarting a production cluster, must not contain non-determinism. Every cluster restart should run the same sequence of steps, so the harness should provide determinism exactly where it matters.
Durability as the cost of admission
Harnesses can run for seconds, or for months while waiting on third-party shipments, human approvals, or external events. They run on infrastructure that fails, through network outages, partitions, or crashed hosts, so they must be durable. He calls durability “table stakes” and “the cost of admission,” not a feature that differentiates one harness from another.
The brain and the hands
The harness tracks the state of the world: completed work, recorded side effects, and what succeeded or failed. Given that state and the goal, the LLM decides what comes next. His central takeaway is that the non-deterministic agent should plan, not act, and the harness should execute. The harness is deterministic code that knows what execution actually involves. If the agent says a cluster is unhealthy, the harness decides how to restart it through a fixed, repeatable process rather than letting the model improvise.
Approval gates must be guaranteed by the harness, not left to a model’s judgment. For a production restart, the harness might send a Slack message asking a human for approval. Steps should be idempotent, and where they are not, the harness should record that fact and what happened, so side effects can be handled separately. He sums this up as the brain and the hands: the LLM is the brain, the harness is the hands.
Late-bound sagas
Sagas were traditionally hand-written, deterministic workflows that defined exactly what happened. Agentic harnesses are late-bound sagas. The set of tools and tasks is finite and deterministic, but the agent proposes and assembles the sequence at runtime. You still get saga benefits out of the box, including visibility, control, and the ability to decide how many steps ahead the agent plans, whether one step or several. He describes this as a branching workflow in which every combination is built for you, which would be nearly impossible to anticipate in advance when many tools are involved.
Demo: an SRE remediation agent
He shows a completed run of an SRE agent that executes a remediation loop twice. In the first iteration, the agent calls the LLM, which proposes a sequence: gather evidence, analyze logs, query metrics, and, if required, roll back a deployment and verify recovery. That plan goes to a plan-and-compile tool that turns it into a runnable workflow on Conductor, which then executes it. The first iteration completes. In the second iteration, the agent checks the downstream state, sees that the rollback already happened, skips repeating it, verifies recovery, and completes. At each step the loop looks at the current state of the world before deciding what comes next.
He notes that this loop can run as often as needed, triggered by events or schedules, and for much longer than a single short run.
Closing
The example runs on Conductor, an open source workflow orchestration platform that supports agentic loops and agentic systems. Orkes offers an enterprise edition. He says Conductor can orchestrate agents built with LangChain, OpenAI Agents, or Google ADK.