Yes, and the shapes do not collide. Conductor can run an agent step that is itself a Claude Code session with CodyCody attached over MCP. Conductor would then orchestrate across agents while the engine keeps each one on its procedure.

Is Conductor's human gate the same as a CodyCody approval gate?

In purpose, yes: both stop the workflow for a person. Conductor answers gates from its dashboard or TUI. CodyCody has no separate approval surface: the gate's question is handed to your coding agent, which puts it to you in the session you are already in and returns your answer to the engine.

Why does it matter whether the orchestrator is in front of or behind the agent?

In front means a new runner and a new way of starting work; behind means the agent you already run gains rails with one MCP entry, and the engine is a service that every agent, profile and CI job on your instance shares. It also means the agent runs the shell steps itself, in its own checkout: the engine fixes the command and the reporting contract, captures the output to a file with a hash, and a later step can re-check it. Conductor runs its script steps in its own process instead. Both are deterministic; they verify from different seats.

← All comparisons

Conductor, by Microsoft

Two ways to take the plan away from the model

Microsoft's Conductor and CodyCody start from the same conviction: for workflows whose structure is known, the model should do the work and something deterministic should decide what happens next. Conductor's own announcement puts it as "known structure is the whole point". We agree with every word of that. Where the two differ is where the determinism sits.

Conductor is a runner. You write a workflow in YAML, and the Conductor CLI executes it, calling the Copilot, OpenAI or Claude SDK at each agent step. CodyCody is a server. You keep the coding agent you already use — Claude Code, Codex, anything that speaks MCP — and it calls the engine, which hands it one verified step at a time. One puts the orchestrator in front of the agent; the other puts it behind.

What Conductor, by Microsoft is

An open-source CLI (MIT, Python 3.12+) "for defining and running multi-agent workflows with the GitHub Copilot SDK and Anthropic Agents SDK", with OpenAI as a further stable backend.
Workflows are YAML files with Jinja2 templating, typed outputs, conditional routing, parallel execution and loop-back patterns. Script steps can route on exit code or parsed JSON stdout.
Human-in-the-loop gates pause for decisions with Markdown-rendered prompts, answerable in a web dashboard or the Fleet Manager TUI.
MCP tool support for the Copilot, OpenAI and Claude providers over stdio. A Conductor skill can be used from inside Claude Code or Copilot CLI.

What CodyCody is

A self-hosted workflow engine with an MCP server. The agent connects over streamable HTTP and drives execution with a handful of tools — ccw_start, ccw_continue and their siblings.
Workflows are designed visually — branches, gates, task lists, sub-workflows, instruction files — and stored on your instance, in a per-user library that travels across projects.
Step order is enforced by the engine. Shell steps are fixed by the engine and run by the agent under a structured contract — exit code, output, and a sha256 of the output captured to a file — so a later step can re-check the result rather than take the agent's word. Decisions branch on a closed set of labels against recorded output. Approval gates halt the run until a person decides.
Licensed per profile, activated offline from a signed key, no phone-home. Starter is free; Pro is priced per seat per year; Enterprise adds air-gapped operation, SSO and a site license.

Side by side

The same questions, both answers

	Conductor, by Microsoft	CodyCody
Shape	CLI runner that calls agent SDKs	MCP server that your agent calls
Your agent	Copilot SDK, OpenAI, Anthropic SDK (Claude Agent SDK experimental)	Claude Code, Codex, any MCP client — unchanged
Workflow definition	YAML with Jinja2, in your repository	Visual designer, stored on your engine instance
Human gates	Yes — Markdown prompts, web dashboard, TUI	Yes — a node type; the run halts and the question reaches you through your agent
Verifying a step's output	Script steps run by Conductor itself; routes on exit code or parsed stdout	Shell steps run by the agent under an engine-fixed command and exit-code contract; output hashed to a file a later step can re-check
Parallel agents	Yes — parallel groups	One agent on rails per run; sub-workflows and task loops within it
Ready-made workflows	Examples in the repository	Packages: code quality, Clean Architecture, OWASP & STRIDE, Boy Scout, team review, forensics
Hosting	Runs where you run the CLI	Self-hosted binary; offline license; air-gapped on Enterprise
License and price	MIT, free	Commercial; Starter free, Pro per seat

Facts about Conductor, by Microsoft are taken from its own documentation, checked on 2026-08-23. “Not documented” means we could not verify it, not that it is absent.

Choose Conductor, by Microsoft if

You want the workflow definition in git as YAML, reviewed like code, and you are comfortable with Python tooling.
Your workflows fan out across several agents in parallel and merge the results.
You are building on the Copilot SDK, or you want an open-source, free tool and will do the integration yourself.

Choose CodyCody if

You want to keep using Claude Code or Codex exactly as you do today, and add rails to it rather than replace it with a runner.
You want the procedure enforced on the agent you already run, with each shell step's command fixed by the engine, its exit code reported under a contract, and its output on disk with a hash — so a later step can check it rather than take the agent's word.
You need offline activation, no phone-home, or an air-gapped deployment, and a vendor to hold accountable for it.
You want workflows that ship ready to run — a complete OWASP assessment, a Clean Architecture review — rather than examples to adapt.

See plans & pricing How CodyCody works

Questions

Asked when comparing

Can I use both?: Yes, and the shapes do not collide. Conductor can run an agent step that is itself a Claude Code session with CodyCody attached over MCP. Conductor would then orchestrate across agents while the engine keeps each one on its procedure.
Is Conductor's human gate the same as a CodyCody approval gate?: In purpose, yes: both stop the workflow for a person. Conductor answers gates from its dashboard or TUI. CodyCody has no separate approval surface: the gate's question is handed to your coding agent, which puts it to you in the session you are already in and returns your answer to the engine.
Why does it matter whether the orchestrator is in front of or behind the agent?: In front means a new runner and a new way of starting work; behind means the agent you already run gains rails with one MCP entry, and the engine is a service that every agent, profile and CI job on your instance shares. It also means the agent runs the shell steps itself, in its own checkout: the engine fixes the command and the reporting contract, captures the output to a file with a hash, and a later step can re-check it. Conductor runs its script steps in its own process instead. Both are deterministic; they verify from different seats.

Sources

Where the facts come from

Spotted something out of date? Tell us at the address in the footer and we will correct it.