Agentic Delivery Is an Operating Model Question

The risk is not moving too slowly

Leaders face two easy mistakes with agentic AI. One is to dismiss it after an early bad output and slowly lose the ability to judge what good looks like. The other is to spend heavily on the bleeding edge before the organisation is ready to carry the risk.

Neither is a strategy.

The useful middle path is preparation. That starts by recognising that agentic delivery isn't primarily a tooling question. It's an operating-model question.

The old handoffs are the constraint

An agent can already inspect a pull request, compare a change with acceptance criteria, identify missing evidence, run tests, and propose or apply a fix. Once that work can happen in one loop, the familiar sequence of developer to tester to reviewer and back again begins to look less like control and more like delay.

That doesn't mean removing judgment or automating every decision. It means asking whether the current boundaries, queues, and responsibilities still serve the work.

If the organisation keeps the same handoffs and only adds agents to them, it may get faster activity without better outcomes. The expected return on AI investment comes from improving the whole feedback loop: how quickly a team can clarify intent, test an assumption, find a defect, and correct course.

Start with controlled loops

Most organisations don't need to invent a new software delivery lifecycle overnight. They do need to build the habits that will make a bigger change possible later.

Start inside existing workflows, with bounded work and clear human accountability:

• Let engineers use agent loops to investigate defects, run tests, and move assurance earlier.
• Let analysts turn source material into clearer specifications and acceptance criteria, then validate them with the people who own the outcome.
• Let delivery leaders turn complex documents into plans grounded in real delivery data, rather than treating generated plans as a substitute for planning.

Each use should be aligned to existing standards and checked against the way the organisation actually works. The immediate benefit may be modest. The longer-term benefit is more important: teams learn how to design, supervise, and improve a human-agent loop.

Coding speed is not loop speed

I have seen agentic work move quickly through specification, validation, build, and test, only to discover after a week that it was not what the business needed. The code was not the problem. The feedback loop was.

When implementation becomes faster, a team can't afford to wait several days to check whether it has understood the need correctly. The important feedback may need to happen every few hours.

That is the structural shift. It changes where feedback happens, how quickly it happens, and who or what participates. It also changes the skills that matter: product understanding, business value, specification quality, assurance, and orchestration become more—not less—important.

Questions for leaders

Before committing to a large transformation, ask:

• Which feedback loops are slow because of genuine risk, and which are slow because of habit?
• Where could a small, reversible human-agent loop produce evidence quickly?
• What must remain a human decision, and what evidence is required before that decision is made?
• How will the team recognise that it is building the right thing, not merely building faster?

The answer is not full automation for teams that are unprepared. It is not business as usual either.

It is preparation: small loops, controlled risk, better habits, and clearer judgment. The organisations that make those changes now will be in a stronger position to decide what to scale when the operating model catches up with the tools.