I went to TechDays in Amsterdam expecting a broad day of AI talks. The event itself was fairly forgettable, but one presentation stayed with me. Pratyush Sinha of Decathlon described an experimental system for producing learning content with AI. The most interesting part was not the authoring agent. It was everything built around it.
The system used an orchestrator, explicit criteria, automated checks, repair loops and two human decision points. Nine stages led towards a single commit point. Sinha’s practical conclusion was that making an agentic system reliable may require more governance than action.
That suggests a useful shift in attention. We tend to describe agentic systems through what the agent can do. It may be more revealing to ask what surrounds it: what it can access, how its work is checked, where failure is routed and who can allow the result to become real.
Capability does not tell us what the system can do
The underlying model matters, but it does not determine the behaviour of the whole system. The same model can sit inside very different arrangements. One may draft a paragraph for a person to inspect. Another may coordinate tools, retry failed work, choose among competing outputs and publish the result.
Those differences come from architecture. Goals, permissions, tests, stopping conditions and handoffs define the system’s practical agency. A highly capable model with narrow permissions may present less risk than a less capable model connected to consequential systems with no meaningful point of interruption.
This is why treating the “agent” as the unit of analysis can be misleading. The consequential object is the configured arrangement in which the agent operates.
Governance is not simply another agent
In the Decathlon example, governance did not mean surrounding one model with a small parliament of other models. It included model-based evaluators, but also deterministic tests, an orchestrator, repair rules, human approvals and a controlled release point.
That distinction matters. A second model can inspect an output, but it may share the first model’s blind spots. Three agents producing three answers create variation, not necessarily independent judgement. Reliability can also come from less glamorous machinery: schemas, tests, logs, permissions and rules about when nothing should happen.
Calling all of this “multi-agent architecture” risks making the agents sound like the main event. Often they are only one component in a larger control system.
The commit point may matter more than autonomy
One of the most useful features of Sinha’s design was the single commit point. The system could generate, compare and repair work, but those activities were separated from the authority to release it.
This creates a distinction that is often lost in arguments about AI autonomy. A system can have considerable freedom to explore possible actions while retaining very little authority to make an irreversible change. Conversely, a simple system may have narrow reasoning capacity but substantial authority if its output is automatically applied.
So the important question is not only how independently an agent can act. It is what the action changes, whether it can be reversed and what has to happen before it crosses from proposal into commitment.
Human involvement also needs an architecture
The Decathlon system retained two human decisions: approving the plan and releasing the result. That sounds reassuring, but “human in the loop” says very little by itself. A useful checkpoint depends on what the person can see, how much work they must review, whether they have time to judge it and whether refusing approval is genuinely possible.
A human decision can be a real control, or it can become the ceremonial clicking of a button after a complex process has already made disagreement difficult. The presence of a person is not the same as governing capacity.
The same applies to automated governors. Explicit criteria make evaluation more consistent, but they also make omissions repeatable. If the system tests the wrong thing very efficiently, it can scale a mistake while producing excellent audit logs.
Reliability moves the problem upstream
Control architecture does not remove failure. It changes where failure is likely to concentrate. Instead of one visibly poor output, the more serious problem may be a defective criterion, a weak evaluator or a permission that affects every run.
This is not an argument against agentic systems. It is an argument for looking at the whole arrangement. The model may be impressive, but the quieter design choices around it determine what its work can become.
After the TechDays talk, I found myself thinking that the agent may be the least interesting part of an agentic system. That is probably overstated, but usefully so. It directs curiosity towards the machinery that turns model behaviour into organisational action.