Answers
We run several AI agents and people on the same work. Is an orchestration tool what we need?
Two different problems get called orchestration, and only one of them is about scheduling. Ordering the work — what runs when, what waits for what, what retries after a failure — is what an orchestrator does, and if that is what is broken, get one. The failure most teams actually hit looks nothing like it: two agents run correctly, at the same time, on different premises about what the team decided. Nothing is late, nothing is stuck, nothing retries, and the two outputs contradict each other. That is not fixed by deciding who commands whom. It is fixed by every agent and every person reading the same decision in force before acting, and recording what they did. A queue coordinates order; a shared record coordinates agreement — and a team with several agents usually needs both.
Last updated September 7, 2026
An orchestrator moves work around; it does not settle what is true
Look at what a scheduler is actually given: a graph of steps, a trigger, a retry policy. Every one of those is a statement about sequence, and none of them is a statement about content. So when two agents disagree about the current discount policy, the orchestrator has nothing to say — both steps completed, both returned successfully, and the disagreement is in the text. Teams reach for orchestration at this point because the symptom feels like coordination, and then discover they bought ordering for a problem that was never about order.
The failure has no error, no delay and nobody to blame
It is worth being precise about the shape, because it is what makes this hard to notice. There is no handoff to lose: the agents are not passing anything to each other, they are running in parallel. Nothing was interrupted, so there is no half-finished work anyone has to pick up. Both agents did exactly what their instructions said. The divergence is upstream of all of it — one was told the policy in February and the other in June, or one read a prompt where the rule was pasted and the other a prompt where it was pasted differently. What you see downstream is two plausible answers and no way to tell which one is the house position.
The people are in the loop too, and they diverge the same way
Any arrangement that coordinates only the agents moves the problem rather than solving it, because a person reviewing an agent's output is applying their own version of the rule. So the record is not an agent bus: it is one place, read by whatever is about to act — an agent on a schedule, an assistant somebody is talking to, a person opening the project on a Friday. What each one reads is the same standing decision, with who ratified it and what would end it. That is the sense in which the coordination is by what the team decided, rather than by who is in charge of whom.
What it looks like in practice
A team runs three agents on its support queue: one drafts replies, one triages into buckets, one writes the weekly summary. All three are healthy — nothing failing, nothing behind. Over one week the drafting agent offers a courtesy refund outside the policy window, because the exception it was told about got wider in the prompt it read, and the summary agent reports the week as clean, because by its rule those tickets were resolved. Nobody notices for nine days, and what surfaces it is a customer quoting the refund back at somebody who says no. With the refund policy held as one standing decision, all three agents read the same version at the top of every run, and the exception that widened would have had to be ratified by a person to reach any of them. The orchestrator that runs the three on a schedule is still doing its job — it was simply never the thing that could have caught this.
Questions people ask about this
- So do we still need an orchestrator?
- Probably, if you have real sequencing to do — steps that depend on each other, work that has to retry, load to spread out. That is a genuine problem and this is not a substitute for solving it. The distinction worth holding onto: an orchestrator is how the work gets run, and a shared record is what the work is run against. Teams that buy only the first keep finding contradictions they cannot trace.
- Isn't this just giving every agent the same system prompt?
- That is the version most teams try first, and it fails on maintenance rather than on principle. A rule pasted into six prompts has to be corrected in six places, the copy somebody misses keeps running with the old text, and nothing tells you which copies disagree. Reading the rule at the start of the run inverts it: one correction, and every agent and person is on the new version the next time they open the project.
- Do the agents have to be built on the same framework?
- No, and that is most of the point. The record sits outside any single assistant or framework, so agents built on different stacks — plus the people working alongside them — read the same thing. Teams usually arrive here because they already have a mixture they are not going to consolidate, and standardising the decisions turns out to be far cheaper than standardising the tooling.
Where this is verifiable
Product documentation on this site (How it works, Install) and the sanctioned product spec in the repository, for how a decision in force is read before an action and how what happened gets recorded. The failure described here — concurrent agents acting correctly on divergent premises, with no error and no delay — comes from our own scheduled routines and from an audit of another team's, where one rule lived in four prompts and had drifted apart. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/orchestrating-ai-agents-and-people-on-one-shared-memory