The agentic service centre: speeding up delivery without industrialising debt

The agentic service centre isn't just about putting Claude Code, Copilot, or agents into developers' hands. As production speeds up, the risk shifts toward what surrounds that production: context quality, tests, review capacity, decision rights, deployment, observability, and total cost. For an IT services firm, the challenge isn't only producing more. It's building a delivery chain able to absorb that speed without multiplying defects, rework, hidden costs, and dependencies.

The thesis argued here is this: a service centre becomes genuinely agentic when the entire production chain becomes measurable, controllable and reversible — not when the share of AI-generated code becomes spectacular.

In brief

• •The transformation signals are real. In France, 72% of the IT services and technology consulting firms surveyed by Numeum and KPMG already said they use generative AI in their delivery processes in 2025. Numeum and Xerfi also estimate AI-linked productivity gains at IT services firms could rise from 15% in 2025 to 22.3% in 2027. This data is self-reported or forward-looking: it isn't a uniform causal measure of productivity.
• •Speeding up one step doesn't guarantee speeding up the system. The DORA report describes AI as an amplifier of the organisation's strengths and weaknesses. Higher adoption can raise throughput while also raising delivery instability.
• •The bottleneck moves. Several cases observed show a shift from writing code toward specs, evals, review, decisions, and the merge queue — a finding mainly documented at organisations with a strong engineering culture, which can't be generalised as-is.
• •The real KPI, then, isn't "how much code AI produces". It's the total cost of one accepted, usable change: human time, models, licences, tests, review, rework, incidents, operations, and maintaining the agentic assets.

The trap: automating production before industrialising control

A traditional service centre already has its own fragilities: incomplete documentation, insufficient tests, too many handoffs, dependence on a handful of key people, technical debt, a backlog growing faster than it shrinks.

AI doesn't magically remove any of these fragilities. It can, on the contrary, give them more throughput.

This is exactly the point the 2025 DORA report makes: AI acts, first and foremost, as an amplifier of the existing sociotechnical system. The best results don't come from deploying a tool in isolation, but from the quality of the organisational system around it.

For an IT services firm, the consequence is significant. A team able to generate twice as many changes but unable to test them, review them, deploy them, or observe them hasn't doubled its delivery capacity. It's potentially doubled its queue.

This phenomenon shows up in several agentic-development cases: when agents produce more code, the bottleneck shifts toward decisions, specs, evals, and review.

The industrial unit to optimise is no longer the developer, or even code generation. It's the whole chain that turns a need into reliable behaviour in production.

The market confirms the shift, but not yet the promise of automatic productivity

Delivery's transformation is no longer marginal.

In the 2025 Grand Angle ESN & ICT study, run by Numeum and KPMG among nearly 200 IT services and technology consulting firms based in France, 72% of respondents already said they use generative AI in their delivery processes.

The Numeum-Xerfi Observatory published in July 2026 goes further. Across 296 digital-sector players, including 151 IT services firms, and 116 CIOs, it estimates AI-linked productivity gains at IT services firms at 15% in 2025 and projects 22.3% in 2027. But the same study stresses these gains remain hard to convert into margin: 35% of the firms surveyed expected their operating margin to decline in the first half of 2026, in a context where 49% cited pricing pressure among their top headwinds.

Producing faster and making more money are two different things.

A service centre can locally improve development productivity while seeing its licence and inference costs rise, along with review time, the number of reworks, platform investment, security and compliance costs, and the upkeep of agents, prompts, connectors, and eval sets.

Delivery's industrial transformation, then, can't be steered by tool adoption rate alone, or by the number of pull requests produced.

What Doctolib, Qonto and Anthropic actually show

The most spectacular cases become dangerous when we make them say more than they prove.

Doctolib: industrialising the environment before rolling out usage

Doctolib's shift to an agentic-first way of working for its 600 engineers in January 2026, after a year-long pilot, doesn't rely solely on individual tools: a platform team notably maintains the tooling and the context files inside the repositories, a training function supports teams, and a central team steers adoption. Some engineers orchestrate several agents at once.

What this case shows: scaling up needs a shared environment, context, rules, and support capacity.

What it doesn't show: that 600 engineers using agents equals a measured productivity gain. Near-total adoption isn't a measure of impact.

This distinction is fundamental for a service centre. "90% of our developers use AI" describes tooling. Not industrial performance.

Qonto: moving evaluation ahead of the bug

At Qonto, building evals into CI and around 800 autonomous code changes a month as of March 2026 rest on a simple principle: telling apart an AI product that works from an AI product reliable enough to go into production. Its AI strategy there is structured and explicitly managed.

What this case shows: once an agent contributes to code, evaluation can't stay a final-stage activity. It has to enter the development pipeline.

What it doesn't show: that this setup is superior to a more distributed architecture, or that performance levels can be compared across products.

For an IT services firm, the lesson, then, isn't "copy Qonto". It's simpler than that: if the agent enters the production chain, evals need to enter the production chain alongside it.

Anthropic: the best case for understanding the new bottleneck, and the worst for benchmarking

Anthropic is one of the most advanced cases: its CPO has said 90 to 95% of Claude Code's own code is written by Claude Code itself, and that the share of AI-generated pull requests forced a redesign of the merge queue. Engineers spend more time supervising and reviewing than producing directly.

The signal is useful: when production becomes abundant, scarce capacity shifts toward integration and judgment.

But Anthropic is also an AI-native organisation, to be used as a reference point rather than a target directly transposable to traditional organisations. An IT services firm managing hundreds of legacy applications, several clouds, client SLAs, and fifteen years of technical debt isn't working in the same environment.

The counter-example that demands caution: AI can also slow things down

The empirical literature currently rules out using a universal productivity rate.

In a randomised experiment published in 2025, METR observed that 16 experienced open-source developers working on their own repositories took 19% longer when allowed to use the AI tools studied.

METR has since heavily qualified how long this result should be taken to apply. In February 2026, the organisation considered it likely newer tools deliver larger gains, but judged its newer data not reliable enough to properly measure their scale, notably due to selection bias and the simultaneous use of several agents.

This counter-example obviously doesn't prove AI slows development down in general. It proves something more useful for a service-centre leader: the gain depends on the task type, the codebase, experience, context quality, and the cost of verification.

A serious industrial architecture, then, shouldn't start with a promise of "+30% productivity". It starts with a baseline.

The minimum chain for an agentic service centre

The Agentic Factory can be thought of as an industrial delivery system, not a collection of individual chatbots or copilots: it links together context, orchestration, the engineering toolchain, quality, human control, observability, and capitalisation.

Context → Agents → Tests & evals → Review → Deployment → Observability → Learning

Context becomes a production infrastructure

An agent is only as good as the context it can access.

In a service centre, this context goes far beyond technical documentation: the code and its history, architecture conventions, past incidents, business rules, dependencies, non-functional requirements, earlier decisions, contractual constraints, security policies, and test data.

Documentation gradually stops being only a deliverable meant for humans. It becomes part of the execution infrastructure.

This also changes accountability. An outdated document isn't just annoying for the next developer anymore: it can automatically contaminate dozens of agentic outputs.

The service centre, then, needs to start treating context quality the way it already treats code quality.

Agents need rights, not abstract freedom

The phrase "autonomous agent" is misleading if it hides a more concrete question: autonomous to do what?

Analysing an incident, preparing a fix, running a test, changing a production configuration, or wiping a database aren't equivalent decisions.

The right level of autonomy depends, notably, on four criteria: reversibility, potential impact, confidence in the evals, and observation capacity.

ANSSI, France's cybersecurity agency, recommends that an AI system's critical interactions with the IT system be controllable by a human, and that privileged operations be explicitly defined and validated. It also recommends securing the deployment chain and properly separating environments.

An agentic service centre, then, isn't a service centre with no humans. It's a service centre where every actor's level of authority, human or agent, is formalised.

Tests change role: from final check to autonomy boundary

In classic delivery, tests mainly serve to verify a piece of work.

In agentic delivery, they fill a second function: they determine how far the machine can be allowed to act.

A task that's perfectly specifiable, well-tested, and easily reversible can be given a lot of autonomy. A critical migration with few tests, heavy business dependency, and a costly rollback gets far less.

This is why agentic AI's arrival can, paradoxically, make engineering discipline more important, not less.

ISG observes, in Europe, GenAI usage expanding from code generation and QA toward fuller development and maintenance cycles, within hybrid delivery models where humans and AI systems work together, with transparency and control as key stakes.

Cigref, in its guide on the contractual impact of AI projects, likewise recommends documenting tests, performance, deviations and corrective measures, and adapting acceptance testing to the particularities of AI systems.

The more autonomy an IT services firm promises, the more it needs to be able to demonstrate the conditions under which that autonomy is safe.

Review is probably the next capacity problem

There's a misleading idea behind many business cases: if a developer produces twice as fast, the team produces twice as much.

Not necessarily.

If agents generate more changes: the number of PRs rises, more architectural decisions arrive at once, the rarest experts get pulled in more often, the cost of understanding the generated code can rise, and the merge queue can become the real delivery lead time.

Alan offers an interesting signal: in its programme opening up contribution to non-engineers, review is explicitly treated as the bottleneck, and the merge decision stays on the engineering side. The case documents more than 350 PRs merged by non-engineers, but not yet hard ROI that would let anyone conclude about overall performance.

Before buying more generation capacity, a delivery director should measure their validation capacity.

In some teams, the next profitable investment may not be another agent. It will be more tests, better architecture, a security specialist, or more senior review time.

Deployment needs to become proportional to risk

Full automation isn't a goal in itself. It's rational when the action is well understood, low-risk, and easily reversible.

The service centre can therefore organise several levels: automatic for standard operations that are fully covered; automatic with monitoring when rollback is simple; mandatory human validation when the impact is significant; double validation or human-only handling when operations are critical.

This gradation avoids two mirror-image mistakes: imposing unnecessary human validation on every micro-action, which destroys agentic AI's whole point; or chasing maximum autonomy when the system isn't observable enough to be trusted with it.

Observability shouldn't just watch the application anymore

Knowing the application went down at 2:03pm isn't enough anymore.

You need to be able to reconstruct which agent acted, with which model and which version, from what context, which tools it called, which tests passed, which review was done, which human authorised the action, how much the processing cost, and what rework was needed afterward.

This traceability isn't just a compliance matter. It's what lets the system be industrially improved.

Without it, teams don't know whether an incident came from the model, bad context data, a connector, a prompt, an orchestration rule, a missing test, or a bad human validation. And with no diagnosis, there's no learning. Only accumulated automation.

Agentic debt: six debts that can hide behind faster delivery

A significant share of the recommendations on managing "AI debt" stress the need to combine industrialisation, governance, reusable assets, observability, and human accountability.

Transposed to the service centre, the risk isn't just adding classic technical debt. It's adding several new kinds.

Context debt shows up when agents rely on outdated, fragmented, or contradictory knowledge.

Evaluation debt shows up when production grows faster than the test sets and criteria used to check its quality.

Orchestration debt shows up when every team accumulates its own agents, prompts and automations, with no owner and no common standard.

Review debt shows up when the validation queue grows until human checks turn into superficial rubber-stamping.

Vendor debt shows up when a critical workflow becomes dependent on a single model, an inference price, or an API with no fallback.

Observability debt shows up when an organisation runs many agents in production without being able to precisely reconstruct their actions.

The paradox is simple: an organisation can post an excellent velocity gain while simultaneously accumulating every one of these debts.

Measure the total cost, not just the hours saved

This is probably the most important management shift for an IT services firm.

The classic business case often compares "time before AI – time after AI". That calculation is too thin for a service centre. The right indicator is the total cost of one change accepted into production.

Human scoping cost + agent and model cost + licences and platform + tests and evals + review + deployment + observability + rework + incidents + maintaining the agentic assets.

This approach explains why IT services firms can simultaneously observe productivity gains and find them hard to convert into margin.

It also avoids a commercial trap. An IT services firm that saves three hours of development but adds two hours of review, more compute, an extra licence, and 45 minutes of rework hasn't gotten the gain its tool advertised. It's moved its cost around.

The KPIs to track

An agentic service centre should, at minimum, track four families of metrics.

Flow: full lead time, delivery frequency, wait time before review, age of blockers.

Quality: change failure rate, escaped defects, rollbacks, rework rate, first-time-right.

Agentic: end-to-end automation rate, exception rate, acceptance rate with no significant rework, human oversight time.

Economics: total cost per accepted change, inference cost, cost of exceptions, margin after AI costs, asset reuse rate.

The percentage of generated code can remain interesting. But it becomes a secondary metric.

The agentic service centre shouldn't become a central factory that turns back into a bottleneck

Six AI organisational models were observed across the sector's body of cases, and none is universal. Two lessons are especially useful here: the frequent need for a central core, and the need to keep autonomy within teams.

For a large IT services firm, centralising all agentic skills into one team would quickly create a new ticket centre. Conversely, letting every service centre build its own agents, its own rules, and its own infrastructure would make risk and cost control impossible.

The most plausible model, then, is federated.

The central level owns what needs to be common: approved models, security, the agent registry, observability, eval standards, FinOps, platform components, and governance. Service centres own what depends on the client: context, business rules, specific tests, runbooks, autonomy thresholds, and operational trade-offs. Human experts keep authority over critical decisions and exceptions.

This architecture remains an organisational inference, not a proven sector standard: some companies succeed with more centralisation, others with a more distributed spread.

What we can't yet claim

• •That an agentic service centre mechanically needs fewer people. The cases observed don't prove a general headcount decline; several companies keep hiring.
• •That a high generated-code rate mechanically means better delivery. DORA's and METR's results show, on the contrary, the importance of organisational context and the diversity of effects.
• •That legacy systems will soon be developed or maintained with no humans. ISG documents AI's progress in the European ADM cycle, but describes hybrid setups and notes companies notably use GenAI for targeted modernisation of high-value legacy systems rather than replacing them wholesale.
• •That human oversight is a transitional phase bound to disappear. In critical environments, French security recommendations point the other way: tighter control over privileges and sensitive interactions.

The credible promise, then, isn't the "autonomous service centre". It's the service centre able to intelligently distribute work and authority between humans and agents.

Self-diagnostic: is your service centre ready to go agentic?

Context

• •Do we have an identifiable source of truth for code, business rules, incidents, and architecture decisions?
• •Can we detect when information given to an agent is out of date?
• •Are context-access permissions defined by client, environment, and sensitivity level?

Agents and autonomy

• •Does every agent in production have an identifiable owner?
• •Have we defined what it can do alone, what needs validation, and what it's forbidden from doing?
• •Can we swap a model or disable an agent without rebuilding the whole workflow?

Tests and evals

• •Are the acceptance criteria written before the agent produces anything?
• •Can the critical cases and regressions be tested automatically?
• •Do we measure false positives, false negatives, and human rework?

Review

• •Do we measure the wait time before review?
• •Is review capacity growing at the same pace as generation capacity?
• •Do reviewers have the time and the context needed to genuinely understand the proposed changes?

Deployment and risk

• •Does every agentic operation carry a risk and reversibility level?
• •Do critical actions require the appropriate human authority?
• •Do we have a tested rollback that's fast enough?

Observability

• •Can we reconstruct the full chain that led to a production change?
• •Do we know the model, the context, the tools, the tests, and the validations used?
• •Can we link an incident to a specific agentic action?

Economics

• •Do we know the total cost of a change before and after going agentic?
• •Are model, licence, review, rework and incident costs built into our margin?
• •Do we measure the reuse and the maintenance cost of our agentic assets?

Organisation

• •Does the central level supply standards without becoming the new bottleneck?
• •Do delivery teams keep enough authority over context and client decisions?
• •Can managers simultaneously oversee throughput, quality, exceptions, and their teams' learning?

If most of the answers still come down to tool choice rather than these questions, the service centre is probably equipped for AI, but not yet organised for agentic delivery.

The conviction

The agentic service centre changes delivery's economics because it makes production more abundant.

But abundant production doesn't make quality abundant.

When agents code faster, the scarcest assets become reliable context, evals, review capacity, judgment on exceptions, and accountability for going into production.

This is why the industrial transformation shouldn't start with the question "how many developers can we augment with agents?", but with: "which chain can we make more autonomous without losing our ability to understand, control, and be accountable for what it produces?"

The next difference between two service centres won't come down only to the quality of their agents. It'll come down to the quality of the control system built around them.