Orchestrators, supervisors, and MCP
Split planning from doing, give every agent the narrowest tools that work, and have something watching what they actually try.
The problem
One large agent with access to every system is easy to demo and impossible to approve. Nobody can say what it will do, test its parts, or limit the damage when it gets something wrong.
Protocols like MCP make connecting agents to systems easy. That makes deciding what each agent is allowed to touch the important part.
How it works
- Request
- Orchestratorplans, delegates
- Specialist agentsas tools
- MCP toolsscoped per agent
- Supervisorchecks every action
- Human gate
The orchestrator plans, specialists act
An orchestrator breaks the request into steps and calls specialist agents as tools. It holds no data tools itself. Each specialist does one thing and can be evaluated and replaced on its own.
A supervisor checks what agents try, not just what they say
Every proposed tool call is compared with the task the agent was given. Out-of-scope actions are blocked and surfaced to a person rather than silently dropped.
Connecting an MCP server is where permissions are decided
Each new MCP server is reviewed tool by tool: read, write, external, destructive. Read is on by default; everything else needs a named owner, a reason and a review date. Every call is logged.
Nothing bypasses the human gate
No tool lets an agent contact a client directly. If a capability would skip the gate, it is redesigned as something that feeds a draft.
See it run
Pick a scenario and step through it. When the run reaches a decision, you make the call.
An orchestrator breaks a request into steps and calls specialist agents as tools, each with a narrow job.
Where it breaks
Too many agents
Splitting work across agents adds latency, cost and places for context to get lost. Split only where it buys you separate evaluation or separate permissions.
A supervisor that only reads the transcript
If the supervisor checks what the agent said rather than the tool calls it made, a confused or manipulated agent can talk its way past it.
Permissions that only grow
Tool access granted for a pilot tends to stay forever. Review dates and usage logs let you take back what nobody uses.
In practice
I work on MCP integration and multi-agent design (orchestrators, supervisors, agents-as-tools) in a regulated enterprise setting.
The design choices on this page (agents-as-tools, scoped MCP permissions, supervisors that check actions) are the ones that turn a promising demo into something risk partners can sign off.