Multi-agent orchestration in Orca: turning complex tasks into coordinated work

The question everyone asks when they start using AI agents at work: "how does this actually work in practice?" The short answer: split the problem, distribute it to specialized agents, and coordinate the result. The long answer is this article.

The scenario: a task that, done solo, would eat your whole day — or week. The goal here is not "automate everything". It's turning a real demand into coordinated work: each part of the problem in the hands of whoever (or whatever) executes it best, with enough context to avoid mistakes and clear criteria to know when it's done.

The problem with big tasks

Every complex task carries three risks when you try to execute it in one go:

• Too much context. An agent (or person) who needs to know everything ends up retaining nothing. A context window is not infinite memory — and shouldn't be.
• Too little accountability. When everyone is responsible for everything, no one is responsible for anything. If something breaks, you don't know where to look.
• Diluted quality. Without an explicit quality bar, every part of the work turns out "almost good" — and the whole, worse.

Multi-agent orchestration exists to solve exactly this. Not to impress anyone with sophisticated architectures, but to give you back clarity: who does what, with which context, and who answers for each part.

Step 1: split the work

The first step is not creating agents. It's understanding the problem.

Take the task and ask: which parts are independent? Which depend on others? Which require context the rest of the team doesn't need?

In my case: I needed to publish a bilingual article. Two versions (pt-BR and en), same translationKey, same date, different tags per language. The work splits naturally:

1. Write in pt-BR — context: blog tone, brief in Portuguese
2. Write in en — context: blog tone, brief in English
3. Validate — context: repo conventions, lint/build commands

Each part has its own context and its own owner. No agent needs to know everything — only what falls within its scope.

Rule of thumb: if you can't describe one part of the task without mentioning another part, they aren't independent. Split again — or accept it's a single task.

Step 2: give each agent context

Context is what keeps an agent from failing with confidence. It's the difference between "write something about X" and "write X with this tone, these references, and this length limit".

In Orca, context arrives in three ways:

• Preamble + TASK block. What you're reading right now is an example: behavior rules, the task ID, and the full instruction of what to do. It's the agent's "briefing".
• Worktree. Each agent runs in its own git worktree. It sees the code, reads AGENTS.md, follows conventions — without stepping on anyone's work.
• Coordination CLI. Commands like check, ask, send let the agent ask questions, report progress, and escalate blockers — instead of making things up when information is missing.

The classic mistake is giving too much context ("here's the entire repository") or too little ("write an article"). The sweet spot: the minimum the agent needs so it never has to guess.

Step 3: coordinate without centralizing

Coordination is not micromanagement. The coordinator doesn't tell each agent how to work — it says what must be delivered and when to report.

The coordination loop in Orca:

1. Dispatch. The coordinator sends the task with scope, IDs, and behavior rules.
2. Heartbeat. The agent signals it's alive every ~5 minutes — distinguishing "still thinking" from "hung".
3. Ask/escalate. If something blocks the work, the agent asks or escalates — instead of going silent or improvising.
4. worker_done. When done, the agent sends a 3-sentence summary: what it did, what it found, what's left. The coordinator decides whether to accept or re-engage.

This loop is what allows one human to coordinate several agents without becoming the bottleneck. You don't follow every step — you follow deliverables and blockers.

Rule of thumb: if you're following steps, you're micromanaging. If you're following deliverables, you're orchestrating.

Step 4: maintain quality and accountability

Dividing work without a quality bar turns into distributed mess. Three simple mechanisms fix it:

• Delivery contract. Every dispatch defines the expected format: files created, validations that must pass, a final 3-sentence summary. If the delivery doesn't match the contract, the coordinator sends it back.
• Validation in the worktree. The agent validates its own work before reporting — lint, build, tests. Whoever produces, validates. No outsourcing accountability.
• Individual accountability. Each agent answers for its part. If the pt-BR article has an error, it's not "the system's fault" — it's the part that wrote pt-BR. Locating the owner must be trivial.

None of this is bureaucracy. It's what allows the whole to be better than the sum of its parts: each part good, each boundary clear.

Practical lessons

1. Split by independence, not by stage. Independent parts can run in parallel; dependent parts need order. Confusing the two wastes time.
2. Minimum context, not maximum. More context is not better context. Give enough that the agent never has to guess — and nothing beyond that.
3. Coordinate deliverables, not steps. Heartbeats and worker_done exist so you don't have to watch. Use them.
4. Whoever produces, validates. The agent that did the work runs lint and build before reporting. Without this, the coordinator becomes QA.
5. Traceable accountability. A problem should point to a part, not to "the system". If it doesn't, the split was bad.

Conclusion

Multi-agent orchestration is not about having many agents. It's about having one problem well split, agents with enough context, and a coordinator that tracks deliverables — not steps.

Orca materializes this with worktrees, dispatches, and a simple protocol (heartbeat, ask, escalate, worker_done). None of it is magic: it's process, with names and rules.

The right question is not "how many agents do I use?" but "how do I split this problem so each part has an owner, context, and a quality bar?" — and you answer that question before opening any tool.