Most companies are already drowning in org charts, procedures, reference documents and standard operating procedures. Nobody needed AI to start formalising. So what Bertrand Duperrin describes in a piece published on 25 August is not a call to document more. It is the observation of a change in status:
Once a representation no longer merely explains how the company works but contributes to how it works, it stops being documentary heritage and becomes a component of the execution system itself.
The consequence is immediate and rarely drawn: an approximation that used to go unnoticed can now lead an agent to make a bad decision, propagate an obsolete rule, or automate a way of working that should never have been automated.
Formalising is not documenting
The word documentation carries a deserved bad reputation: procedures nobody consults, reference material nobody updates, files produced to satisfy an audit. Many organisations concluded that the problem was documentation itself.
That is a confusion. The goal was never to produce documents but to build a shared representation of how the company works. That representation exists either way, formalised or not - scattered across habits, conversations, spreadsheets, support tickets and decisions made case by case. The cost shows up the day those versions stop being compatible: someone leaves, someone joins, an activity changes scale.
Formalising means making that representation debatable. A procedure's first function is not to impose a way of working but to establish a common reference that anyone can understand, challenge and evolve. Without it, there is no way to tell a sensible local practice from an innovation, a mistake, or simply a different reading of the same instruction.
AI changes the economics of formalising
For years the return on formalising was real but indirect: onboarding a new joiner, limiting knowledge loss when someone leaves, preparing an audit. Hard to defend in a budget review.
What changes is frequency of use. A structured representation is no longer consulted on the day someone decides to look something up: it is queried continuously by systems that use it to understand a context, prepare an action, steer a decision or check a rule. Formalising stops being passive memory and becomes an active part of the operational environment.
Elie Nehmé, who built an enterprise application almost entirely with an agent, arrives at the same idea from the field, in a sentence worth pinning to a wall:
Documentation only stays correct when something consumes it.
And he draws the flip side, just as true: it makes incorrect documentation much more dangerous. If the agent reads a wrong rule, it produces wrong code. But it also makes documentation much more valuable - a rule that is consumed every day is far likelier to stay right than a rule filed in a binder.
Beware the misreading, which Duperrin takes care to rule out: this is not about codifying everything. Judgment, experience and tacit knowledge do not fit in a rule file. The point is to make explicit what has to be transmitted, coordinated or executed reliably - and to represent the limits of that formalisation too: where a rule suffices, where context is needed, where a human decision remains indispensable.
Three executors instead of two
For a long time the division of labour was binary: people did what required judgment, software ran deterministic processing from rules set in advance. The boundary was imperfect but clear enough to structure processes and responsibilities.
An agent fits neither box. It interprets a goal, mobilises knowledge, chooses a sequence of actions, calls tools, and adapts to what it receives. A process then stops being a series of tasks assigned to job titles and becomes an assembly of capabilities mobilised according to their nature. The same activity can move from an employee to an agent, return to a human when an exception appears, then pass on to another system.
What matters is therefore no longer only which function performs an activity, but which capability is needed to execute it, under what conditions, and with how much autonomy.
The COO becomes the architect of the execution system
If the representation of the company becomes a component of its execution, someone has to keep it coherent. That someone is not IT: the subject touches how work is designed, distributed, executed and improved. That is historically the ground of operations, and the article's thesis is that AI does not create a new role but widens the scope of one that already exists.
Four responsibilities follow, and they read like a roadmap:
- Discovery. Before representing how the company works, you have to understand how it actually works: observe practices, spot the workarounds that became permanent, tell the exception from the normal case. That is the principle of process mining - start from real execution rather than stated intentions.
- Architecture. Decide the granularity, make the rules explicit, represent dependencies, make the interfaces between humans, applications and agents legible. Not describing everything that exists: producing a model faithful enough to be useful, simple enough to be maintainable, precise enough to be executed.
- Coherence. Keep the representation aligned with reality, accept the changes that deserve it, retire the models that have gone stale.
- Governance. Who may change a rule? How is a change approved? When does a local practice become a standard? What guardrails frame an agent's decisions?
The COO is not being asked to become the head of AI. The role is more structural than that: they become the architect of the company's execution system.
The real danger: automating too early
This is the part of the article to read twice, because it warns against a very available illusion: believing that representing work better is enough to have it executed better.
Researchers in organisational resilience distinguish work as imagined - work as procedures describe it - from work as done - what operators actually do to get the result despite constraints and surprises. The gap between the two is not a malfunction: it is the condition under which organisations function at all. They hold together because people know how to adapt rules to situations nobody anticipated.
The risk for a company steered by explicit representations is to treat that gap as an anomaly to eliminate rather than a signal to understand. The organisation gains homogeneity and loses its capacity to learn.
The line that captures the threat best is not the one you would expect:
The problem is not automating, it is automating too early. Where a bad procedure used to sit ignored in a binder, it can now become the basis for decisions taken at scale by agents. AI does not invent those errors, it gives them more reach.
Hence the conclusion: the representation cannot be treated as a deliverable but as a living model, continuously confronted with reality. Operations' responsibility is not to build a perfect model - there will never be one - but to organise a permanent loop between representation and execution, so that each corrects the other.
The same diagnosis, seen from product
This analysis meets, almost word for word, what Johnny R. Domin wrote days earlier about agility, in a formula worth keeping: AI does not improve the system you add it to, it amplifies it.
A team with a confused backlog will produce a confused backlog faster. An organisation that cannot tell output from outcome will generate more output. A company that does not know who decides will automate badly governed decisions faster.
His other point is economic and it frames the whole question: when production gets cheaper, decisions get more expensive. Bain estimates that hybrid teams of humans and agents could reach five- to tenfold productivity gains - while insisting that pilots and local acceleration are not enough, and that workflows, team organisation, control mechanisms and measurement systems all have to be rethought.
The comparison he draws is a good one: the Toyota Production System was built against overproduction - making things too early ties up resources and creates cost before demand exists. In industry that stock is visible; in software it takes the form of little-used features, code to maintain and added complexity. If AI lets a team produce five times faster, the answer cannot be to build five times more features.
Hence the metric he proposes, and which strikes us as right: move from time-to-market to time-to-learning. A team that ships a feature in four hours but waits three months to find out nobody wants it is still a slow team.
What Survol does with this
We have long argued that the specification is the new software asset and that the hard part is not writing it but keeping it alive. Duperrin extends the reasoning beyond software, and the extension holds.
Three design choices answer it directly:
- The representation is versioned, not archived. Organisation technical constraints are ranked - mandatory, strong, preference - and injected at the start of every session. They are executed rules, not a document someone should have read.
- The gap is traced, not erased. When an agent pushes back on a constraint, the pushback is recorded. That is precisely the loop the article calls for: the execution system does not merely use the model, it learns from where the model diverges from reality. Work as done travels back up instead of disappearing.
- Nothing is automated before it is understood. A request becomes a human-approved specification before it becomes an agent task. That is our answer to "automating too early": approval is not a formality, it is the moment you check that the work was understood before freezing it.
Which leaves the question neither a tool nor an article settles on a company's behalf: who, where you work, owns that representation? As long as only humans read it, having no answer was expensive slowly. From now on it will be expensive quickly.
Sources
- Bertrand Duperrin, âLe COO devient l'ingĂ©nieur du systĂšme d'exĂ©cution de l'entrepriseâ, duperrin.com, 25 August 2026.
- Johnny R. Domin, âAI-Augmented Agile & Productâ, LinkedIn, 19 August 2026.
- Elie NehmĂ©, âAI Writes the Code. So What Is the Engineer's Job Now?â, Medium, 15 August 2026.
