Multi-agent orchestration: workflows as graphs, retries and spending caps

The problemYour agents work fine on their own, but when they work together they stall, duplicate effort or spend without limits.

It is 9:40 on a Tuesday morning, and Laura, VP of operations at a distribution company, opens the weekly customer report. It should have been ready at 8:00. It is not. The agent that consolidates sales waited on the inventory agent, which in turn got stuck retrying an ERP query for 90 minutes. Nobody noticed. And that day's bill from the AI model provider came in far above a normal day. The agents were not the problem. The missing piece was multi-agent orchestration.

When a company goes from one agent to several, a new job appears that almost nobody plans for: coordinating them. Who goes first, who can work at the same time, what happens when one fails and how much spending is allowed. This article explains, without jargon, how that gets solved in a system built for production.

Why agents get in each other's way

Most pilots are built as a chain: agent A finishes and hands everything to agent B, which hands everything to agent C. It works in the demo. In production, three problems show up.

• Everything runs in sequence, even when it doesn't need to. If the report needs sales, inventory and collections data, there is no reason for them to wait in line behind each other.
• One failure silently stops everything. If a step hangs, the whole chain freezes and nobody knows where.
• Nobody sets limits. An agent that retries endlessly or gets caught in a loop keeps making model calls, and every call costs money.

The root cause is not "not enough AI." It is that the process is not described in a way a machine can coordinate. That description is part of the harness: the structure around the model that makes it reliable (for the full picture, see the anatomy of an enterprise harness).

Multi-agent orchestration: the workflow as a graph

The core idea is simple: instead of a chain, the workflow is described as a graph, meaning a map of steps connected by arrows. Each step declares which other steps it depends on. With that, the system can work out on its own what can run in parallel and what has to wait.

Think of a restaurant kitchen. The chef does not wait for the sauce to finish before chopping vegetables. She knows plating depends on both, but that the two are independent of each other. A graph gives your agents that same logic.

In practice, each step in the graph has five attributes:

1. What it does: for example, "consolidate this week's sales."
2. What it depends on: "needs the billing close."
3. When it runs: always, or only if a condition is met ("only if there are customers with overdue balances").
4. What to do if it fails: how many retries it gets and how long to wait between them.
5. How much time it has: a per-step limit; if it is exceeded, the step is marked as failed instead of hanging.

Conditional steps

Not every step should always run. If the collections agent finds no overdue balances, there is no point running the step that drafts payment reminders. A conditional step saves time and money, and it also makes the workflow easier to understand: what does not apply does not run.

Retries with a time limit

Models and external systems fail from time to time. Datadog's State of AI Engineering 2026 report found that 5% of model calls in production returned an error, and that capacity limits, rate limits and timeouts accounted for 60% of those errors. In other words, most failures are temporary and a well-configured retry resolves them. The key is that the retry has a ceiling: two or three attempts and a maximum time per step. Without a ceiling, a retry becomes Laura's problem.

The orchestrator and the subagents

In a well-designed multi-agent system there is a special role: the orchestrator. It does not do the underlying work; it hands out tasks, collects results and decides the next move. The subagents are specialists: one knows inventory, another knows collections, another writes.

What matters is that each subagent works with isolated context. That means it receives only the information it needs for its task, not the entire history of the process. The agent writing the email to the customer does not need to see 4,000 inventory transactions; it needs the summary and the brand's tone of voice. Giving it only that has three advantages:

• It makes fewer mistakes, because it is not distracted by irrelevant information.
• It costs less, because it processes less text on every call.
• It is safer, because a subagent cannot leak data it never saw.

This principle has a name of its own, and we cover it in context engineering for companies.

The per-run spending cap

This is the control that gives a CFO the most peace of mind. Every run of the workflow has a maximum budget in dollars. The system adds up the cost of each model call as the workflow progresses. If the total hits the cap, the run stops, saves the work done so far and alerts the person responsible.

It is not a report you read at the end of the month. It is an automatic brake that acts in the moment. An agent caught in a loop stops being a surprise on the invoice and becomes an alert with a name, a timestamp and the exact step.

A practical framework for designing your first orchestrated workflow

If you can fill in this table on a single page, you already have most of the design. The rest is construction.

Illustrative example: the weekly report, before and after

Illustrative example. Before, Laura's report was a chain of four agents. It took about two hours on a good day, and nobody knew what each run cost. When the ERP was slow to respond, the report simply never arrived.

After redesigning it as a graph:

• Sales, inventory and collections run in parallel, so total time depends on the slowest step, not the sum of all of them.
• If the ERP does not respond, the inventory step retries three times and, if it still fails, the report goes out with a clear note: "inventory unavailable, using data from the previous close."
• The reminders step runs only when there are overdue balances.
• Every run has a spending cap. If it is reached, Laura gets an alert naming the step that triggered it.
• Before going to customers, reminders pass through human approval by role from the collections manager.

The important change is not speed. It is that the process is now predictable: you know what will happen when something goes wrong.

Common mistakes when orchestrating agents

• One giant agent that does everything. It looks simpler, but it is impossible to debug and expensive to run.
• Infinite retries. A retry with no limit is not resilience; it is a money leak.
• Sharing all the context with everyone. It increases errors, cost and the risk of leaks.
• Not defining what happens when a step fails. "Stop everything" is rarely the best answer; sometimes it is better to continue with a warning.
• Setting only a monthly spending cap. A monthly cap tells you when the damage is already done; a per-run cap prevents it.

What to do on Monday

Pick a process that involves three or more steps today and draw it on a whiteboard. Mark what depends on what, what could run at the same time and what would happen if each step failed. Put a number on it: the most you would be willing to pay for each run. That drawing is the start of an orchestrated workflow.

At Addabra we build these workflows on our own harness, with dependency graphs, capped retries, per-step time limits, per-run spending caps and human approvals where they matter. If you want to see what your process would look like, we start with a diagnostic.

orchestrationAI agentscost control