Conductor Now Runs Agents Alongside Your Workflows, on the Same Durable Engine

Agents and workflows now run on the same durable engine so agents inherit everything that’s made Conductor workflows reliable in production for years.

An agent running on Conductor is now a workflow.

The model’s “thinking” becomes a task in a workflow, each tool it calls becomes another, and Conductor holds onto the conversation so nothing in your codebase needs to keep it in memory. This means agents get all the things your Conductor workflows have always had: retries when a task fails, approvals that can be stagnant for days without anyone worrying about them, and a history you can scroll back through months later without having to set up any logging yourself.

This is the same engine that has been running production workflows since the early days of Conductor which originated at Netflix, back when the biggest question anyone asked us was how far it scales. It turned out to be billions of workflows a month.

These days another big question is being asked: how do you ship AI agents in production when they’re nondeterministic. It’s rare to need to just ship an isolated agent in production without the need for it to be part of a system, so the question isn’t really whether one agent can be trusted in production. It’s whether a whole agentic system can be, with agents and workflows calling each other and running inside one another as ordinary parts of the same thing. Working harmoniously with each other if you will.

That only works if the engine treats them as equals, and this is our answer to that.

One rule, for both agents and workflows

In most agent stacks, the model picks a tool and that tool runs. There’s no step in between. The only thing keeping it in line is the instructions in its prompt, like “never refund over $200,” or “don’t discuss competitors,” or “be polite to customers.”

But a model is nondeterministic. You can give it the same situation twice and you can get two different answers. And this is exactly what you don’t want from a guardrail in your system. A rule has to hold every time, or it isn’t a rule.

On Conductor, an agent’s tools and guardrails are part of the workflow, rather than the model’s prompt. The model proposes a step and Conductor decides whether it happens and how it happens.

That’s the whole idea, and it’s the reason everything below works. The architecture behind it is worth a read.

What you can do today

• Keep the agent you already wrote. Conductor takes agents from LangChain, LangGraph, OpenAI, Vercel and Google ADK. You can bring them into Conductor and give them Conductor’s agentic runtime so they inherit the same durability Conductor workflows have.

• Or write one from scratch. Any Conductor SDK works, the same ones you already use to write workflows, lets you also write agents.

• Point a tool at anything. A function you wrote, an API call, an MCP tool, a person who has to approve something, another agent, or a whole workflow.

• Mix the two. Drop an agent into a workflow you already have, as an ordinary step. Or let an agent call a whole workflow as one of its tools.

Durable execution for AI agents and workflows: Determinism, durability, explainability

Determinism, durability, and explainability are vital for agentic production systems. Conductor workflows have had all three for a decade. Now your agents do too.

Each one covers a different part of a run, before, during, and after, whether you run an agent or a workflow.

Determinism is what you define before the run. With a prompt-driven agent, the model decides what happens next, like which tools to call, in what order, whether to loop or stop, which is probabilistic. With Conductor, the steps, branches, and available tools are declared in the workflow definition before execution starts. The model just reasons within that structure.

Which means if your agent asks for a tool that isn’t in the workflow definition, the call never gets scheduled and the model gets told what it can actually use:

Unknown tool 'str_replace'.
Available tools: check_inventory, create_ticket, notify_oncall

Conductor also checks what goes into a tool and what comes back out before the step is allowed to proceed. And when the agent needs to do something rather than decide something, the tool it calls can be a whole workflow, so the action runs once and in order, with the retries that workflow already has. The model still guesses. Everything around it is built so those guesses can’t turn into nondeterministic output.

Durability is what holds during the run. The work survives whatever happens to the machine running it.

An agent has to remember things as it goes, like what’s been said so far and which tools it already called, as well as what those calls returned. In most setups that memory sits inside your running program, so if the program dies, the memory dies with it.

On Conductor the memory sits in the engine instead and this memory is durable. Crashes, deploys, timeouts, and multi-day waits for human approval don’t cost you the run. Conductor picks it up at the exact step where it stopped, and the steps that have already finished don’t run a second time, so your agents get the same exact-once execution your workflows already had.

Explainability is what you read after the run. It’s a record of what the agent did and why.

Conductor records everything. That’s been true for workflows, and it’s now true for agents and every step they take. So what you read afterwards is the run itself, step by step: the prompt, the model’s response, the tool it picked, what went in and what came out, the approval and who gave it.

And because the workflow steps, the agent’s thinking, and the human approvals are all one run, you read it in one place instead of lining up timestamps across two systems. Other tools can tell you what happened. Reading the reasoning back is how you find out why.

Agents and workflows go together

When building a production agentic system you need both workflows and agents to work together well. And each has its own function in your system. An agent for example decides that a cluster should restart, because that’s judgment. A workflow decides how it restarts, because that path has to be the same every time.

It also works in both directions. A workflow can call an agent as a step. And an agent can call a whole workflow as a tool.

We didn’t build an agent product and bolt it onto a workflow engine. It’s one engine, and it treats both agents and workflows the same way. That’s why none of your workflows change when you add agents. They just gained something new to call, and something new that can call them.

Start here

• Build an agent — a working agent on a local server in minutes
• Build a workflow — a durable workflow set up in minutes
• Agents on Conductor — Architecture for Production AIt - the architecture on why and how the model proposes and Conductor decides

⭐️ github.com/conductor-oss/conductor