What we learned building a government service with an AI agent

Over the past few weeks we’ve been using AI agents to build out the early design and technical foundations of a government digital service: workshop findings turned into user stories, a data catalogue, a candidate architecture, an entity relationship model, and a working service. Some of what we expected held. Some of it didn’t. Here’s what we learned.

Discovery matters more, not less

Discovery has become a dirty word in parts of government, and not without reason. A three-month discovery that ends in a slide pack, a set of personas, and no options for the policy owner to weigh up is a waste of taxpayer money. The scepticism is earned.

But the answer isn’t less discovery. It’s a better discovery. Most discoveries are shallow not because the team lacked curiosity but because they ran out of time. Four weeks, twelve conversations, whatever documents someone remembered to send over, then you generalise from there. Everything after that is inference dressed as insight.

Agents change the economics of that. We can interrogate data at scale instead of sampling it, though this still needs a shared “project brain” holding the documents, because you can’t use what you don’t know about. We can analyse every piece of policy guidance instead of the three most recent, and find where they contradict each other. We can turn a set of raw workshop notes into user stories in an afternoon, so the workshop gets followed by another workshop instead of two weeks of synthesis. When the unit cost of processing something falls, you can do more of it, as long as it’s narrowing down real options, not generating more material to read.

That points to a different discovery model: not a fixed six-week window ending in a report nobody reopens, but data captured continuously into a memory that stays referenceable through build and beyond. When a developer asks in month four why a field is mandatory, the answer is retrievable rather than lost with whoever’s rolled off since.

That memory has to hold contradictions rather than smooth them over. Where two stakeholders disagree. Where policy intent and lived experience pull apart. Where legislation says one thing and operational practice has quietly done another for a decade. Those conflicts are usually the most valuable thing a discovery finds, and the first thing a summary deck loses, because summaries reward coherence. A memory that can hold “these two things are both true and incompatible” is worth more than a document that picks one. Resolving that incompatibility is still a human call. AI can surface the tradeoff; it shouldn’t decide which one to accept.

The mechanics of delivery change

A backlog carries two kinds of information: constraints and value. Constraints are what must be managed for delivery to succeed. You can’t build the eligibility check before eligibility is defined, and a PII constraint on data sharing doesn’t move regardless of priority. Value is what makes the service worth having. Priority, though, isn’t a property of the work. It’s a property of scarcity. Every prioritisation technique we use, MoSCoW, WSJF, cost of delay, is a rationing mechanism dressed up as a value judgement.

Agentic delivery doesn’t remove sequence. It does start to dissolve priority, because the scarcity has moved. When a working slice of service takes hours rather than sprints, the constraint is no longer the team’s capacity to produce. It’s our capacity to decide whether what’s been produced is right, and to get it in front of users who can absorb it. Faster build doesn’t mean faster release is wise: slotting a new service into an ecosystem of other services, digital and non-digital, is still hard, and deciding when to ship matters more than ever.

So the backlog stops being a ranked queue and becomes closer to an assurance register. The question shifts from “what do we do first with the capacity we have?” to “how do we assure what’s been produced, and was it worth producing at all?” Cheap build makes it easy to ship features nobody needed. Cost used to be the filter against that. If we lose cost as a filter, we need measurement to replace it, or we’ll produce waste faster than before.

This changes what roles do, not whether we need them. A delivery manager spends less time sequencing tickets and more time on the flow of decisions. A product manager’s judgement becomes the bottleneck.

Design and build swap places

We design in high fidelity before we build because building has always been the expensive, slow, hard-to-reverse step. Get it wrong in Figma, you’ve lost a day. Get it wrong in code, you’ve lost a sprint and a difficult conversation. Every design practice we have exists to de-risk that expensive downstream step.

That calculation is shifting. We can put working versions of a service in front of users, and when one is right, it moves toward full deployment instead of being rebuilt from a picture of itself. The handover from design to development, historically one of the most ‘lossy’ moments in delivery, starts to disappear because there’s less to hand over.

There’s a research benefit too. A high-fidelity prototype tests whether people understand a page. Working code tests whether people can complete the thing, with real error states, real edge cases, real performance in a deployed environment. That’s exactly the gap between private and public beta at scale: proving something is technically robust, not just legible. Most of what goes wrong in a public service goes wrong in the edge cases, and edge cases are what prototypes often fake or take a long time to test.

There is still a residual blocker that will persist for a while though. Code still feels permanent, so people are reluctant to throw it away when it’s wrong, and reluctant to show it to a stakeholder in case it’s mistaken for a commitment. That’s a rational response to forty years of code being expensive, and it’ll fade as designing and coding a service converge parallel activities. We’re already working this way in places, with agents producing the service and designers acting as the human in the loop on review of the code: a genuine role change, not just a new tool.

None of this means design thinking matters less. Deciding what the service should be, what a user is trying to achieve, what the journey should feel like: that’s still the work. What changes is the artefact the thinking gets expressed in.

Humans are needed

Not as a caveat at the end of a piece about automation. As the thing that repeatedly made the work correct rather than merely plausible.

Some deliberate unglamorous examples in the work we did: getting the right guidance in place, correct use of ARIA tags, semantic HTML, so agents default to the right thing instead of needing repeated correction. And making sure what gets produced is understandable and maintainable, not just functional. A visually good design is worthless if nobody understands the decisions behind it, and code needs to be readable enough that a human can reason about its behaviour and prompt the next change effectively.

The skill that matters is knowing where to be suspicious. Knowing that a page rendering correctly proves nothing. Knowing where the real risk in a service sits. Knowing when an answer is too tidy for the question. Building that instinct, and holding an agent to it the way you’d hold a less experienced colleague to it, is human work. Agents are good at going complex quickly. Humans need to rein that in, but to do that, they still need to understand the problem.

Take-up and implementation are still the barrier

So much attention goes on the service itself, the page, the interaction design, when the hard part is change management. That’s an unfashionable term in some quarters, but the problem hasn’t gone anywhere.

I remember this from my own time on frontline operations: change fatigue was real, the guidance about a change usually arrived through a different channel from the change itself, and working with systems that weren’t designed to make the job easier was a daily tax nobody had factored in. The people deciding on those systems weren’t the people using them for seven hours a day.

That’s still the barrier, and faster builds don’t touch it. Nothing about agentic delivery shortens the time it takes to retrain or update three thousand operational staff, run a regional pilot, decommission a legacy system with undocumented dependencies, or rebuild trust with a team burned by the last rollout.

If anything, a faster build makes it more acute. The rate at which we can put change in front of operational staff now outruns the rate at which they can absorb it. The bottleneck moves downstream, onto the people who are frontline, delivering value to users.

Which is exactly where a user-centred approach earns its place. Not just on the interface, but on the operational reality the service lands in: what people’s days look like, what they’ll stop doing to make room for this, how it gets adopted rather than merely launched. Agents don’t make that redundant. They make it urgent.

I’d like to hear about how others are navigating these shifts in the public sector. If these insights resonate with your own work and challenges, reach out to me on Linkedin to keep the conversation going.