how to build agentic orchestration?

the order that works

1. One agent first. Build it, run it on twenty real tasks, and write down exactly where it failed. Half the time the answer is better tools, not more agents, and you save a month.
2. Split on a real failure. Add a second agent when the first is genuinely overloaded: too many tools to choose between, or reviewing its own work badly. Those are the two failures a second agent actually fixes.
3. Pick hierarchical. A coordinator that decomposes and delegates, specialists that execute. Peer negotiation is more elegant and much harder to debug at three in the morning.
4. Add a shared state store. Every agent reads it, every agent can write facts to it. This is what stops handoffs losing context and stops two agents solving the same subtask.
5. Global budgets before the second agent. Total steps, total spend, wall-clock limit. Multi-agent systems fail toward infinite loops, and the loop is between agents, so a per-agent limit does not catch it.
6. Log every step. Which agent, which tool, which arguments, which result. With nondeterministic output, an unlogged run is unexplainable.
7. Gate the irreversible. Merges, deploys, payments, outbound messages. Pause and ask.

the design decisions that matter most

How much context crosses a handoff. Too little and agent B repeats agent A's mistakes. Too much and you pay for the whole history every turn. The pattern that holds up is a short shared fact store plus the specific artefact being passed, not the transcript.

Whether the reviewer is a different agent. It has to be. An agent checking its own work checks against the assumptions that produced the error. This single decision does more for output quality than any prompt work.

Where the stop is. Not "when the agent says it is done". A step budget, a spend cap, and a human gate, all three.

what to skip

• Dynamic agent creation. Spawning agents at runtime is a great demo and a debugging nightmare. A fixed roster is enough for almost everything.
• Open-ended negotiation. Fun to build, impossible to explain when it deadlocks.
• More than about five agents in one run. Coordination overhead grows faster than the benefit. If you think you need twelve, you probably need three agents and better tools.

how this works in aldena

Aldena is this list already built, which is the honest reason to consider it before writing your own. The org chart is the hierarchical coordinator, so delegation is configuration rather than routing code. Shared room memory is the state store, 100 entries every agent reads plus 50 private each.

The reviewer is a separate role sitting above the workers, the gate is approval on by default before anything irreversible, and the blast radius is a room with its own server. You watch the run happen live rather than reading a trace afterwards, which is the part homegrown systems almost never get around to building.