Conductor
Multi-agent orchestration engine
Live Demo
Overview
Conductor is a multi-agent orchestration engine I built to understand what agent frameworks actually buy you, by building one myself. A planner agent breaks a goal into subtasks, worker agents execute them with real tools — web search, code execution, structured extraction — and a critic agent verifies the result against the sources before it's returned. Every step is streamed to a live run trace so you can watch the system think. It's a lab project, but the primitives are the ones I reach for in production.
The Challenge
Agents are easy to demo and hard to trust. A single model call with tools looks magical until it silently invents a citation, loops forever, or blows the budget on a task it should have refused. The interesting engineering isn't getting an agent to run — it's getting a group of them to run reliably: bounded steps, verifiable outputs, parallel work without race conditions, and a trace you can actually debug when something goes sideways.
The Solution
Three roles with strict contracts. The planner emits a typed task list via structured output, so its plan is data the runtime can schedule, not prose to re-parse. Workers run concurrently, each with a scoped tool set and a step budget. A critic re-reads the final answer against the retrieved sources and can send the plan back for one revision. The orchestration layer is hand-written — a small state machine over the Claude API's tool-use loop — because the moment I tried to hide it behind a framework, debugging a bad run became guesswork.
Architecture
A planner-worker-critic loop over a hand-written state machine. Tool calls, budgets, and verification are enforced by the runtime, not left to the model's good intentions.
Key Decisions & Tradeoffs
Structured output for the plan, not free text
Why: If the planner returns prose, the runtime has to guess what it meant. Forcing the plan through a tool schema makes it a typed object the scheduler can execute directly — no fragile parsing, no ambiguity about what runs next.
Hand-written orchestration over a framework
Why: I started with an off-the-shelf agent framework. The first bad run — a worker looping on a tool — took an hour to trace through abstractions I didn't write. A ~300-line state machine over the raw tool-use loop gave me the same capabilities and a stack I could actually reason about.
A critic that can say no
Why: The biggest reliability win wasn't a smarter planner — it was a separate agent whose only job is to check the answer against its sources and refuse when confidence is low. Verification as its own role catches the failures a single confident model hides.
Hard step and token budgets per agent
Why: Autonomy without a ceiling is how a $0.05 task becomes a $5 one. Every agent runs under an explicit budget; the runtime halts and reports instead of letting a loop run the bill up.
What I took away from this project
Lessons that still shape how I build — in my own words.
The framework was the abstraction I wanted to own
I set out to learn agent frameworks and came away convinced that for anything I need to debug in production, the orchestration is the part I want to write. Frameworks are a great way to learn the shape of the problem — and the exact thing I'll rip out once the shape is clear. Conductor is small on purpose: every decision it makes is one I can point to in code.
Verification is a role, not a prompt
For a while I tried to make one agent both answer and self-check in the same call. It reliably graded its own homework an A. Splitting the critic into its own agent, with only the answer and the sources in context, is what turned a demo into something I'd actually trust to return a result unattended.
Impact
Technology Stack
AI
Runtime
Tools
Observability
Key Features
Related case studies
Want something like this, built for you?
If the Conductor story sounds close to what you're trying to ship, a 30-min call is the fastest way to find out if we're a fit.