The business model that works is not the one with the most autonomous agents, but the one that effectively orchestrates a few components—both deterministic and probabilistic—under a single point of control. The image of an organization populated by agents negotiating with each other is appealing at a conference but fragile in production, because it multiplies points of failure without multiplying the capacity to manage them.
The architecture that bears the weight is more boring and considerably older: a defined flow, components with clear responsibilities, contracts between them, and a place where it is decided what happens when something fails.
This means that the process—not the model—is in charge. There is an explicit flow that defines what steps there are, in what order, under what conditions, and what happens at each branch. Within that flow, some steps are handled by deterministic software, others by a model, and still others by a person.
The difference with the "autonomous agent" approach lies in where the decision logic resides. In an autonomous agent, the sequence is decided by the model in each execution, meaning it can vary. In an orchestration, the sequence is defined, and the model resolves specific steps within it.
This distinction has three practical consequences:
None of the three are possible when the sequence is improvised by the model.
Step type | Who should resolve it? | Because |
Calculation, validation, accounting rule | Deterministic software | It demands accuracy and traceability, not interpretation. |
Inquiry into a fact | Source system | Truth is consulted, not generated. |
Interpretation of ambiguous text | Language model | This is where classic software performs worst. |
Classification with clear criteria | It can be either one. | Decide based on cost and measurement accuracy |
Decision with economic impact | Person, with the proposal prepared | Responsibility and contextual judgment |
The asymmetry is structural: savings are measured with monthly precision and attributed directly to the project; losses are spread across five departments and never attributed to anyone. This is why support automation projects are almost always presented as successes, even though the customer receives worse service.
The way to correct that asymmetry is to measure the full balance from the beginning, not afterward. And the metric that best captures this is not the automation rate, but the resolution rate in the first interaction combined with the satisfaction of escalated cases. A bot that automates a lot and scales poorly produces excellent numbers and an angry customer.
The first row deserves emphasis because that's where the most money is lost due to trends. An amount isn't calculated using a language model. A tax validation isn't interpreted. An accounting rule isn't inferred. Introducing a probabilistic component where there was a deterministic rule adds cost, latency, and risk, and contributes nothing, because the problem was already solved.
The fourth row is the only one where there is a real decision to be made, and it should be made with data: measure the accuracy and cost of the two options on real cases before deciding.
An explicit and versioned flow. It should be written down somewhere that can be read and audited, not scattered across loose configurations. When someone asks why a case was resolved a certain way, the answer should be in the workflow.
Contracts between steps. Each component receives and returns something defined. This allows one model to be replaced by another, or a model by a rule, without affecting the rest. It's the same boundary logic that underpins any modular architecture.
A single point of traceability. All steps are recorded in the same register. Without this, reconstructing a case requires cross-referencing five sources with different clocks.
Defined human control points. It's not "there is someone supervising", but: in this specific step, with this criterion, with this deadline and with this information in front of us.
A stop and reverse mechanism. Being able to stop the entire flow without deploying code, and being able to undo what has been executed up to that point.
All five are architectural requirements. All five are much cheaper if decided before construction than if added afterward, which is why we insist so much on the order.
There's an economic argument that's often more convincing than a technical one. Models change in price, capacity, and usage policy several times a year. Some are discontinued. What's expensive today might be cheap in twelve months, and vice versa.
A company whose business logic is tied to an agent provider's setup cannot take advantage of this shift: each change costs them a project. A company that orchestrates the process can replace the component in step 3 and leave the other eight untouched.
This connects directly to the issue of technological dependence, which we have discussed in Technological dependence and business risks The business layer, data, rules, and assessments should belong to the company's architecture, not that of its vendor.
Gartner estimated in 2025 that more than 40% of agentic AI projects would be canceled before the end of 2027, and one of the three causes it identified was the rising cost. An architecture that allows components to be replaced with cheaper alternatives is, quite literally, the answer to that problem.
Orchestration does not require a transformation project. The path that works is incremental:
In the end, the company has a better, cheaper, and auditable process, and has used AI exactly where it made a difference. Which is, ultimately, all you can ask of this technology.
In a few years, the conversation about whether it's worthwhile to have agents will have disappeared, just like the conversation about whether it was worthwhile to have a website. Models will be just another component—cheap and replaceable.
What will continue to differentiate two companies in the same sector will be the same as the brand today: the quality of their data, the clarity of their processes, and the robustness of the architecture that connects them.
That's not a risky prediction. It's what has happened with all previous technologies.
It is an architecture in which the process, not the model, defines the sequence: there is an explicit flow with steps, conditions, and branches, and within it, some steps are resolved by deterministic software, others by a model, and others by a person. The behavior is reproducible, the failures are traceable, and the cost is predictable.
Where does the decision logic reside? In an autonomous agent, the sequence is decided by the model in each execution and can vary; in an orchestration, the sequence is defined and the model only resolves specific steps within it.
The calculations, critical validations, and accounting or tax rules, which demand accuracy and traceability; and the fact-finding process, which must be done against the source system. Introducing a probabilistic component where there was already a deterministic rule adds cost, latency, and risk without providing value.
Five: an explicit and versioned flow, defined contracts between steps, a single point of traceability, specific human control points with criteria and deadlines, and a stop and rollback mechanism that does not require deploying code.
This allows you to replace one component without affecting the others. Because prices, capacities, and policies for models change several times a year, a company whose business logic relies on a supplier's configuration pays for a project for each change; one that orchestrates the process does not.
Choosing a bounded process with recognized volume and pain, drawing the actual flow with its exceptions, marking which component should solve each step, automating the deterministic steps first and adding the model only where there is real ambiguity.
Do you want to use AI where it truly makes a difference? We map the process, defining what a rule, a model, and a person should handle, and we build the orchestration with factory traceability. Two hours of analysis with no obligation. Let's talk → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
