Organisation and AI: there is no ideal model — only the right diagnosis

Deploying AI is, by comparison, the easy part of the problem. The question that genuinely commits an organisation is different: where to place skills, who has the right to act, who controls quality, and what actually needs to change in the structure.

Looking at a number of companies engaged in their AI transformation, six organisational models stand out: distributed adoption, a centralised centre of excellence, the hybrid product team, human-on-exceptions, agentic development, and the AI-native organisation. But the most useful lesson here isn't this list — it's that none of these six models is a universal target organisation. The cases chosen were picked for how clearly they signal organisational patterns, not to represent the market as a whole.

The question a leader should ask, then, isn't "which model have the most advanced companies adopted?", but: what organisational problem are we trying to solve, and which operating model solves it without creating a new bottleneck or a new risk?

That's this article's thesis. The six models aren't maturity levels, nor stages on the same trajectory: they're six answers to different constraints. And a single company can legitimately combine several of them at once.

In brief

• •There's no organisational model that's superior in the abstract. The right choice depends on the bottleneck being addressed: spreading usage, scarce skills, product speed, operational volume, development capacity, or being built AI-native from the start.
• •Centralising or decentralising is almost never a binary choice. The strongest cases combine a tight central core — platform, governance, expertise — with responsibilities distributed across business units.
• •The most spectacular organisations aren't the most transferable ones. Anthropic, OpenAI, Dust and Mistral are useful reference points, not models a traditional scale-up can apply as-is.
• •The real risk isn't picking the wrong model: it's picking one because it looks modern, and discovering it just moves the problem elsewhere — from development to review, from support to exceptions, from business units to an overloaded centre of excellence.
• •Before any company-wide reorganisation, the model can almost always be tested on one flow, one pod, or one function, over 30 to 60 days.

1. The real starting point: which bottleneck do we want to move?

The temptation is strong to transform the organisation as soon as AI usage takes off: create an AI team, name champions, merge roles, automate a service, ask developers to become "agentic-first". The cases observed call for more caution.

Five cross-cutting phenomena come up regularly: part of the work shifts toward supervision and exception-handling; certain roles hybridise; in a few technical teams, the bottleneck slides toward decisions and evals; a central core frequently pairs with distributed relays; and — a less-discussed but equally real signal — several companies deeply engaged with AI haven't overhauled their organisation at all.

This last point deserves a leader's attention. Lucca, for example, keeps its 6-to-8-person teams organised by application and explicitly keeps the decision on the HR and manager side. Pennylane built AI into its product and brought former chartered accountants into product roles, with no organisational overhaul attributable to AI documented.

Adopting more AI and reorganising the company are two separate decisions. The second becomes relevant when a structural problem shows up: duplicated initiatives, an overloaded scarce skill, review that's become too slow, volume growth that's impossible to absorb, roles that are too siloed, blurry accountability. It's from that problem — not from a market trend — that a model should be chosen.

The six models in one grid

This grid reflects the six archetypes observed in the body of cases; the categories overlap, and a single case can fall under several models at once. It should be used as a reasoning tool — not as a normative benchmark.

2. Distributed adoption — bringing AI closer to the real work

In a distributed organisation, business units don't hand their needs off to an "AI team" tasked with building everything: teams experiment, adapt, and sometimes build their own use cases themselves. Distributed adoption still needs to be told apart from a hands-off free-for-all, though.

The PayFit case is instructive. The company set up a cross-functional AI Ops team, prompt owners, and a network of around thirty champions, for around 600 active users of its internal AI platform, according to a case study published in 2026. The champions there are backed by department sponsors, tasked with freeing up time and clearing obstacles: adoption stays local, but it's organised.

What this shows: a small cross-functional setup can let usage stay close to the field without concentrating the whole transformation inside one central team.

What this doesn't show: neither the number of champions nor the number of users proves, on its own, an economic impact. Adoption is most often measured by logins or usage — far more rarely by isolable results.

When this model works best

When teams already have enough of a digital culture to experiment, a common tooling base exists, and the risks stay locally controllable. It requires, at minimum:

• •an executive sponsor;
• •explicit ownership of the platform and the standards;
• •time genuinely allocated to the local relays;
• •a mechanism for capturing and reusing use cases;
• •metrics that go beyond mere tool usage.

The trap: building a highly active community of volunteers with no real power to change workflows, objectives, or priorities.

3. Centralised centre of excellence — concentrating what can't be distributed yet

Centralisation answers the opposite problem: when skills are scarce, compliance demands are high, or the infrastructure is still unstable, asking every team to become self-sufficient can multiply technical choices, costs, and risks.

Qonto illustrates a form of strategic centralisation: creating a Head of AI Products role overseeing several AI products, while ML engineering skills were brought closer to software engineering.

This point is worth flagging: centralising AI doesn't necessarily mean building a large machine-learning team. What can be centralised is instead: the architecture, reliability standards, governance, evals, vendors, shared data, and certain cross-cutting products or components. Business units, for their part, keep ownership of the problem to be solved.

The main advantage: stopping twenty teams from solving the same security, platform, or evaluation problems twenty times over.

The main danger: turning a scarce skill into a queue. The centre of excellence then becomes an internal service where every request piles up, business units wait, and the central experts gradually lose the context needed to make the right calls.

A good centre of excellence, then, needs a partial exit strategy: what it wants to keep owning in two years, and what it wants to gradually hand over to teams to run on their own.

4. Hybrid product team — cutting handoffs, not expertise

One of the most talked-about signals concerns the growing porosity between Product, Design, Data and Engineering.

Instagram offers a clear illustration. Adam Mosseri described, in July 2026, a shift in the typical product team toward smaller pods — four to six generalist engineers — rounded out by a "product staff" blending dimensions historically carried separately by product, design, data and research. This shift is presented as a trend under way, not a new established standard.

This case is interesting less for the number than for the logic it reveals. When AI lowers the cost of a prototype, an analysis, or a first screen, the dependencies between roles loosen: a PM goes further into prototyping, a designer touches the real product, an engineer explores a product question more directly. Handoffs shrink. That doesn't mean expertise becomes interchangeable.

The risk of misreading this

Confusing greater versatility with the disappearance of specialisation. A small generalist team works better when:

• •the problem stays bounded;
• •quality can be reviewed;
• •specialists remain available on demand;
• •people have genuinely acquired several skills.

It works far less well if you simply remove the designer, the data analyst, or the PM, assuming AI will absorb the depth of their expertise.

A more nuanced conclusion: roles don't necessarily disappear — their boundaries become more porous, and how they combine evolves.

5. Human on exceptions — powerful, provided the remaining work is also designed

This is probably the model most immediately applicable to operations. The principle: AI absorbs the standard cases, humans handle the uncertain or sensitive situations.

Roundtable offers a clear illustration: on a control flow covering 1,000 SPVs, automation is used to isolate fifteen to twenty problem cases a human genuinely needs to examine — an account, not an independent performance study. The potential is real for support, financial operations, compliance, or certain administrative processes.

But this model has a blind spot: what's left for the human isn't a representative sample of the previous work. It's precisely the unhappy customers, the ambiguous files, the errors, the unusual situations, the hard decisions, the cases carrying accountability.

Klarna offers a useful counter-example to overly quick readings here. After heavily automating its support and cutting its headcount, the company brought back more human capacity, to guarantee access to a person in situations where the quality of the interaction mattered most. AI stays central: this is a correction of the automation's scope, not an abandonment — a shift confirmed by several public accounts.

The question that's often forgotten isn't just "what percentage can we automate?", but "what job are we creating for the people who stay?". If humans continuously inherit the toughest 5% of cases, the company needs to rethink the skills required, the headcount needed for peaks, recovery time, decision-making power, escalation mechanisms, and the loop through which exceptions feed back into improving the system. Without that, automation can shrink human volume while raising its intensity.

The essential metrics: the automation rate alone isn't enough. At minimum, you need to track volume, the exception rate, errors, rework, lead time, quality or satisfaction, and cost.

6. Agentic development — when producing more isn't enough anymore

Development's organisation changes in nature once an agent no longer just completes a few lines, but takes on an entire task: producing pull requests, writing tests, running several jobs in parallel.

Doctolib offers a particularly well-documented example. After an experimentation phase in 2025, the company rolled out an "agentic-first" approach across its 600 developers in early 2026; some engineers run up to eight agents in parallel, according to the leaders interviewed. The change comes with sustained investment in specifications and the context given to agents — details confirmed publicly at Devoxx in April 2026.

The most important number here isn't "600". It's the shift in the bottleneck. When producing a first code draft gets much faster, the constraints move upstream toward the quality of the specification, the acceptance criteria, tests and evals, the architecture, review, the merge queue, and ultimately product decisions. This shift shows up at Anthropic, Stripe, Dust and Qonto too — but it seems to mainly involve organisations with a strong engineering culture, and can't be generalised as it stands.

The counter-example worth keeping in mind: more code isn't necessarily more value. If the team multiplies pull requests without review, tests, or trade-off calls keeping up, the agent mainly accelerates the creation of a queue.

The organisational question then becomes: what decision-making and control capacity do we need to build to absorb this new production capacity? It's a transformation of the work system — not a tool change.

7. AI-native organisation — a reference point, rarely a reorganisation target

Anthropic, OpenAI and Mistral exert an understandable fascination: their organisations sometimes seem to preview what every company would become, once AI is advanced enough. That conclusion is too strong. These companies were born around AI — they never had to transform a legacy organisation to integrate it.

Dust illustrates well both the value and the limit of these references. Its co-founder Stanislas Polu said in March 2026 that the share of code produced with agents had risen from around 20% to nearly 70% within weeks, while stressing the need to keep strong technical depth and orchestration capability to avoid degrading the codebase.

This case shows how far certain ways of working can go. It doesn't prove 70% is a relevant target for just any company, that a legacy product team can eliminate its existing functions, that the same model works with a legacy architecture or heavy regulatory constraints, or that a mature company can reproduce an AI startup's density of skills.

AI-native companies' spectacular ratios should be used as questions to ask the organisation, not as benchmarks. "What should we change if the cost of producing a prototype dropped several-fold?" is a useful question. "Why don't we have the same engineer ratio as Dust or Anthropic?" is far less useful.

8. What the cases actually show — and what they don't

What the data reasonably lets us claim

Several companies have changed their division of labour — employees becoming supervisors, roles becoming more versatile, new interface functions being created (AI Ops, champions, ML Analysts). Several cases combine central infrastructure or governance with heavily distributed usage: the real choice, then, is less "central or local" than "what should be central, and what should stay local?". Organisations are automating a significant share of their operational flows and concentrating human involvement on exceptions. In certain advanced development teams, specs, review and evals become more visible constraints as agents produce more. And several companies adopt AI without deeply changing their existing structure.

What the data doesn't let us claim

They don't prove any model systematically delivers better growth or profitability, that a smaller organisation is necessarily higher-performing, or a general headcount reduction attributable to AI. They don't let us extrapolate an AI-native company's ratios onto a legacy organisation, or turn self-reported results or accounts into demonstrated causation.

This caution echoes an idea developed in a different sector, consulting: rising production capacity shifts value toward orchestration, judgment, control and accountability. The transposition is useful for Product and Ops organisations, but it remains an inference.

9. My interpretation — choose by the bottleneck, not by the level of sophistication

Three convictions emerge from these cases.

1. The six models don't form a maturity ladder

Moving from a centre of excellence to a distributed model isn't necessarily "progress". A regulated company can have a lasting interest in keeping centralised governance. A 40-person startup probably has no interest in building a large centre of excellence. A product team can hybridise without support adopting the same model. The model depends on the work in question.

2. The most robust organisation will often be composite

A scale-up can perfectly well combine a central platform and governance, distributed champions and builders, part of support organised around human-on-exceptions, a few technical teams doing agentic development, and more hybrid product pods. This isn't an inconsistency: it's probably more realistic than declaring the whole company "AI-first" and imposing the same organisation on finance, support, product and engineering.

3. The right model moves a bottleneck. The wrong one just hides it.

A central team can solve a governance problem and create a lead-time problem. An automation can solve a volume problem and create an exceptions problem. A hybrid team can solve a handoff problem and create an expertise-depth problem. Agentic development can solve a production-capacity problem and create a review problem.

The question to ask before any reorganisation, then, isn't "which model should we choose?", but: which new bottleneck are we prepared to manage?

10. Five decisions to make before touching the org chart

Decision 1 — Precisely define the problem

"Going faster with AI" isn't an organisational problem. What are: duplicated initiatives, overloaded AI experts, support growing at the same pace as customers, review that's blocking absorption of what agents produce, or product teams spending too much time waiting on other functions.

Decision 2 — Separate what needs pooling from what needs business context

The platform, security, vendors, or certain standards can be centralised. Business decisions, quality criteria, and identifying use cases often benefit from staying close to the field. Drawing this boundary is an organisational decision in its own right.

Decision 3 — Write down the decision rights

For every workflow using an agent: who requests? who specifies? who produces? who checks? who can block? who decides? who's accountable? The more technical autonomy grows, the more explicit this split needs to be.

Decision 4 — Measure the outcome, not just adoption

"80% of employees use AI" says almost nothing about the organisation's quality. The relevant measure depends on the workflow: lead time, volume, quality, error, rework, cost, satisfaction, human time, decision speed.

Decision 5 — Test the operating model before reorganising the company

One strength of these six models is that they can be tested with no company-wide restructuring. A pod, a support flow, a finance team, or a technical service is often enough to test the hypothesis.

Self-diagnostic — which model deserves to be tested at your company?

For each model, check off the statements that are true today.

A. Distributed adoption

• •Several teams already use AI autonomously.
• •Interesting use cases spread poorly, or get rebuilt several times over.
• •Teams have enough skill to be self-sufficient, given a common base and local relays.

3 boxes checked: test a structured distributed model — a sponsor, a lightweight platform core, relays inside teams.

Avoid if: regulatory constraints or scarce skills still call for significant central control.

B. Centralised centre of excellence

• •The skills needed are scarce and concentrated in a few people.
• •Data, security or compliance risk demands strong common standards.
• •Several teams need the same building blocks, platforms, or methods.

3 boxes checked: a centre of excellence can cut duplication and de-risk deployment.

Watch from day one: request turnaround time, and how dependent business units become on the centre.

C. Hybrid product team

• •Your PMs, designers and engineers already usefully overlap into each other's territory.
• •Handoffs between specialties slow the team down more than they protect quality.
• •Specialists remain available for review or complex problems.

3 boxes checked: test a more generalist pod on a limited scope.

Don't: remove expertise before proving it can be deployed some other way.

D. Human on exceptions

• •Your activity has a large volume of repetitive cases.
• •You can objectively determine what counts as a standard case versus an exception.
• •You know how to measure errors, rework, quality, and the exception rate.

3 boxes checked: a "human on exceptions" model deserves a pilot.

Mandatory question: what will the job look like for the people who'll now only get the hard cases?

E. Agentic development

• •Agents already produce a significant share of the development work.
• •Your specs, tests and acceptance criteria are explicit enough.
• •Review or decision-making capacity is starting to become more limiting than writing code.

3 boxes checked: the issue is probably no longer buying a new tool, but transforming the engineering workflow.

Measure: total time to production and rework — not just the volume of code generated.

F. AI-native organisation

• •AI has been core to the product or service since the company was founded.
• •Your architecture, culture and hiring were designed around that reality.
• •You don't have to migrate a legacy organisation toward this model.

3 boxes checked: AI-native companies can offer directly relevant organisational reference points.

Otherwise: use them as edge-case scenarios and sources of ideas — not as a headcount benchmark or a target model.

If several models score three checked boxes

That's probably normal. Your real operating model may well be a combination: a centre of excellence for platform and governance, distributed adoption across business units, human-on-exceptions in operations, agentic development in certain technical teams. The next step isn't picking a label — it's clarifying the interfaces between these models.

My conviction

AI doesn't create a new ideal organisation. It makes the existing organisation's flaws more visible.

It reveals unnecessary handoffs, poorly assigned decisions, skills that have become scarce, repetitive tasks, quality problems, review bottlenecks.

This is why two companies using the same models and the same tools can each have good reason to build very different organisations.

A leader's job isn't to rush toward whichever model looks most advanced. It's to determine where expertise should stay, where decisions should be made, where to place control, and which responsibilities the organisation doesn't want to delegate.

The best operating model will be the one that answers these questions clearly enough to let teams work differently — without silently moving the risk somewhere else.