A company with a CRM, an accounting system, a warehouse system and two SaaS tools adds an agent to each. Each agent works. The one in the CRM chases stale deals. The one in accounting matches payments to invoices. The one in the warehouse flags short stock. Six weeks later a customer is chased for an invoice the accounting agent had already marked paid, because the CRM agent read the order a day before the payment agent wrote to it.
Nobody built anything wrong. The agents were not coordinated, and in a mixed estate coordination is the part nobody is assigned.
That is what orchestration means in practice, and it is less technical than the frameworks suggest. It comes down to three decisions that the business has to make, whatever tooling it chooses.
Records in a business have dependencies. An order exists before a shipment, a shipment before an invoice, an invoice before a payment. An agent acting on one of them reads the state of the others, and if another agent is about to change that state, the first one acts on a picture that is already out of date.
In a single application, the application enforces the order. A workflow cannot raise an invoice before a shipment record exists because the stages are wired in sequence. Across applications nothing enforces it, because each agent sees its own system and no system sees the sequence.
So the first decision is to write the order down by record type, once. For each of the five or six records that matter, which system is the system of record, which agent may change which fields, and what must be true before it does. "The invoice status may be written only after the payment agent has confirmed a matched payment" is the sort of rule that prevents the story above. It is a sentence, not a diagram, and it belongs to someone in operations who knows the process.
We argued in you do not need a new ERP to get agents that the platform question is really a connection question. The order of operations is the connection question applied to time.
Here is how it reads for a company that sells and ships a product. The CRM owns the account and the quote. The order system owns the order and its status. The warehouse owns stock and shipment. Accounting owns the invoice and the payment. Each agent may write only to fields its system owns, and may read the others. An agent that needs another system's field to act does not guess: it waits for that system's agent to have written it, or it asks a person.
The second decision is the one nobody wants to make until the day it is needed. When an agent starts doing something wrong, who can stop it, how quickly, and does stopping it stop the others?
In a mixed estate the default is a collection of switches, one per tool, in different admin consoles, held by different people. Finding out which agent is misbehaving takes an hour. Stopping it takes another, and during that time the agents downstream are acting on what the first one wrote.
The fix is a single control that can pause any agent or all of them, held by a named person with a named backup, which does not depend on the vendor of each tool. In practice this is a flag the agents check before acting, stored in one place, which an operator can set from a phone. An agent that cannot read the flag does not act. That is a design rule, not a feature to ask for: the safe default when the flag is unreadable is to stop.
Pausing needs a companion: a way to see what each agent did in the last hour, in one list, across systems. Without that, the person who pulled the switch cannot tell what to undo.
Two agents will eventually want to change the same record in different ways. The CRM agent wants to set the next step to "call", the support agent wants it set to "awaiting customer". Left alone, the last writer wins, which means the outcome depends on timing.
The business has to decide the rule. Usually there are only three useful ones. The system of record's owner wins: the agent belonging to the system that owns the field decides. The most recent human instruction wins: if a person has set it in the last day, agents leave it alone. Or the conflict goes to a person: the agent writes nothing and raises it. Pick one rule per field that is contested, and write it where both agents can read it.
Most conflicts are on a short list of fields: owner, status, next step, amount. A list of ten contested fields, each with a rule, covers the vast majority of what will happen.
There is a cost to skipping all three that is easy to underestimate: the problems look like data problems. A wrong status, a duplicated task, a customer contacted twice. People fix them by hand, nobody traces them to the agents' timing, and the number of agents quietly caps itself at the count the team can babysit.
Frameworks and platforms for orchestration are useful. They route requests, hold shared state, retry failures and give you a graph to look at. None of them can decide the three things above, because those are business decisions: which record leads, who is allowed to stop work, whose word wins. A framework with the wrong rules gives you wrong behaviour in a tidy graph.
The practical consequence is a different order of buying. Decide the order, the stop and the conflict rules first, on a page, with the people who run the processes. Then choose the tooling that can enforce them. A company that does it the other way round ends up bending its rules to fit the tool's defaults, which is how the story at the top of this post happens. In MCP in plain terms we described how an agent reaches a system. This is the other half: what makes several agents behave as one.
Take your two busiest agents and one record type they both touch. Write three lines. First: the sequence in which each may change the record, and the condition for each step. Second: who can stop each agent, how, and what the agents do if they cannot reach the stop flag. Third: which agent wins on each contested field, or whether a person decides.
Then run last week's log against it. If the log shows something the page says should not have happened, you have found the gap before a customer did. If it does not, you have a page that will carry the third and fourth agents.
We run the agent layer over mixed estates for companies of 5 to 1,000 users, and the three decisions are the first thing we write down with the people who run the processes. Discovery is no-risk: we map the order, the stop and the conflict rules for your two busiest agents, and you pay only if you go ahead. The build carries a guaranteed estimate, so if we estimate low, we absorb the difference.
Orchestration is not the tool that coordinates your agents. It is the set of decisions that tell the tool what to do.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
