Orchestration
Each task goes to the agent that fits it
Agents declare what they can do. The kernel routes each step to an agent that can take it, ranked by track record, and every hand-off stays inside the budget and rules of the task that started it.
Orchestration in Core
from cambrian_agent_sdk import CognitiveAgent
class ReportAgent(CognitiveAgent):
role = "Writes the weekly operations report."
constraints = ("Cite the figures you use.",)
def run(self, task):
# The planner routes the sub-task to the agent that fits it best.
summary = self.substrate.execute(
"Summarise last week's support tickets by product area")
return {"report": summary}
agent = ReportAgent(agent_id="report_agent", version="1.0.0",
description="Writes the weekly operations report.")
if __name__ == "__main__":
agent.serve()Routing
Work goes where it fits, not where it was hard-coded
You add agents; you do not wire them together. Each one says what it can do, and the kernel matches steps to agents as the work arrives.
1.000
Learned routing, synthetic tasks (ADR-0076; off by default)
2/3
τ²-bench airline tasks solved (ADR-0090; directional)
How a request runs
1The planner breaks the request into steps
2Only agents that declare the capabilities a step needs are eligible
3The kernel ranks them by track record and starts only the one it picks
✓The result goes back to whoever asked, with access decisions recorded
Patterns
Four ways agents share the work
Each is a few lines in the Python SDK. The kernel does the routing, budgeting, and checks.
What it does
An agent lists what it can do in its manifest. The planner tags each step with the capabilities it needs, and only agents that declare all of them can take it.
In code
{
"version": "1.0.0",
"capabilities": ["invoice_processing", "vat_lookup"]
}Guardrails
Hand-offs cannot widen what an agent may do
Orchestration runs inside the same kernel that enforces access. Passing work to another agent never passes along more permission than the work needs.
- Delegated work is charged to the step that asked for it
- An agent cannot delegate to itself
- A denied tool call comes back to the agent as data, with its reason
What an agent sees when a step is refused
{ "denied": true, "deny_reason": "effect_not_permitted" }
The agent carries on with the reason; the decision is recorded.
FAQ
The planner breaks a request into steps and tags each one with the capabilities it needs. Agents whose manifest declares those capabilities are eligible, and the kernel ranks them by their track record. It makes no model calls to choose, and only the chosen agent starts.