Rachel Laycock told a story at FOSE that sticks with you longer than most conference anecdotes: a business user built a full internal tool with an AI agent, live, on stage — polished, functional, and by every visible signal, done. The obvious next question from the room was some version of “so citizens can just build software now, right?” Her answer was no, and the reasoning behind that no is a better piece of engineering-leadership thinking than most of what’s been written about “AI democratizing development” this year.

The line that reframes everything

Laycock’s actual point wasn’t that the tool was bad, or that citizen builders can’t produce real software with agents now — they clearly can. Her point was that a working demo answers a much narrower question than it appears to: can this be built. It says nothing about a second question that determines whether the tool should exist inside a company’s systems at all: does this deserve to run in production, with the data access, uptime expectations, and blast radius that implies. Her framing for who answers which question is the part worth stealing: citizens build, agents execute, experts govern. And the sentence underneath it is the one I keep coming back to — “organisations don’t run on code. They run on trust.” A tool that works is a code claim. A tool that’s safe to depend on is a trust claim, and trust claims need a different kind of owner than the person who happened to prompt the agent that generated the first working version.

This isn’t an argument against citizen-built software, and it isn’t gatekeeping dressed up as governance. It’s a claim about which decisions can be delegated to an agent’s output looking correct, and which decisions require someone with authority and context to actually decide — a distinction that agentic tooling makes more urgent, not less, because the “it demoed fine” bar got dramatically easier to clear this year while the “does this deserve to be in production” bar didn’t move at all.

Why this is more than a talk

The reason this framing is useful rather than just tidy is that it maps cleanly onto a failure mode a lot of engineering orgs are already living through quietly: agent output is now good enough that the review bottleneck moved. It used to be “can we build this fast enough.” Now it’s “can we tell, fast enough, which of the things we built fast are actually fine to keep.” A demo clearing that bar tells you nothing about data handling, about what happens when an edge case the demo never hit shows up in week three, about who’s accountable when it breaks at 2am, or about whether it silently duplicates a capability three other teams already own under a different name. None of that shows up in a live demo, by construction — a demo is optimized to show you the happy path.

A guardrail playbook, not a slogan

Turning “citizens build, agents execute, experts govern” into something you can actually run requires naming who does what at each of the three roles, and where the handoffs are:

1. Give citizen builders a bounded playground, not open access to production systems. The tool from Laycock’s story should exist — in a sandboxed environment with synthetic or de-identified data, discoverable by the team that would eventually own it if it graduates. The mistake isn’t citizens building; it’s citizens building directly against systems that have real customer data and no review gate between “it works” and “it’s live.”

2. Make “agent execution” and “production execution” different states with an explicit gate between them, not two names for the same thing. An agent finishing a task and a human approving that task’s output for production are not the same event, and treating them as the same event is exactly the gap the OpenAI–Hugging Face incident (which I wrote about separately this week) shows you don’t want to skip. Laycock’s “execute” role for agents is scoped to doing the work, not to deciding the work is done.

3. Name the expert reviewer before the tool ships, not after something breaks. “Someone will review it” is not a control; a named person or team with the authority to say no is. If nobody can name who that person is for a given tool right now, that tool doesn’t have a governance owner — it has a governance gap wearing the same clothes as a working feature.

4. Route by blast radius, not by how the tool was built. A citizen-built internal dashboard reading from a read-only reporting replica needs lighter review than an agent-built service writing to a customer-facing database, regardless of which one used more AI. Treating “AI-generated” as the risk signal instead of “what can this touch” misdiagnoses the actual risk.

5. Treat the expert’s review as ongoing, not a one-time gate. Software that graduated review in June and hasn’t been looked at since is drifting risk, especially when an agent is still actively modifying it. The governance role doesn’t end at launch; it recurs on a cadence tied to how much the system is still changing.

The part that resonated with how I actually work

I run a chunk of my own operational output — this blog’s publishing pipeline, a tech digest, a product-lead digest — through scheduled agents that execute unattended overnight and hand me a finished artifact to review in the morning. That’s Laycock’s “agents execute” role almost exactly: I write the spec once (a prompt, a template, a set of source constraints), the agent does the work while I’m not watching, and I’m the expert who decides whether what came back is fit to actually publish. The reason this works without me babysitting every run isn’t that the agent is trustworthy in the abstract — it’s that the boundary between “agent finished” and “this is live” has a human decision point sitting in it every single time, and that decision point has real authority to reject, not just rubber-stamp. Laycock’s framework isn’t describing some future state of AI governance maturity. It’s describing the shape a lot of us already back into by instinct once an agent starts producing enough output that reviewing everything manually stops being the bottleneck and deciding what’s worth reviewing carefully becomes the actual job.

The uncomfortable part of adopting this seriously is that it puts a name on the role most orgs currently leave implicit: someone has to be the expert who governs, on purpose, for every category of agent-touched system you run — and if you can’t name who that is for a given tool, you don’t have a governance gap you’ve mitigated, you have one you haven’t looked at yet.