Clever Hans

In the early 1900s a horse in Berlin called Clever Hans drew crowds by tapping out the answers to sums with his hoof. Teachers, scientists and a government commission came to watch, and plenty of them went away convinced he could count. He couldn't. A psychologist eventually showed that Hans was responding to tiny, unconscious signals from whoever was asking the question.

What stays with me is that people saw what they wanted to see. They were so taken with a counting horse that almost nobody asked what he was really doing.

Hans comes to mind whenever I watch organisations adopt AI. A large language model does a very good impression of intelligence. It writes fluent prose, answers questions and produces code that looks right, so it's easy to believe it thinks the way we do. It doesn't. It predicts what comes next, extraordinarily well, and that is its greatest strength if you know how to work with it instead of being mesmerised by the impression.

Ask it to behave like a human colleague, and you'll be let down in ways that are hard to see until they bite. Use it for what it's genuinely good at (following and spotting patterns, summarising, and doing the grunt work without complaint), and it changes what one person can deliver. But only inside boundaries you set.

I was always a producer

I've never been just an engineer, just a tester or just a designer. For most of my career I've been the person holding the vision for a system, with enough skill across each discipline to make that vision realistic: to see how it can be delivered for the best value, and which problems actually need solving. It never had a name. Working with agents gave it one. I'm a software producer.

A music producer doesn't play every instrument. They hold the vision for the record, pick the player for each part, and know when a take is right. That's my job now, and I own what gets made, the schedule, the quality and the record of every decision. I direct the agents and make the rulings. I cover every role a delivery team would need, and I own the evidence that the software does what I say it does.

I learnt the foundations two years ago, as one of the first people on a large government account to bring AI agents into live production. I've written about that in I stopped building canals: agents working to patterns I had defined, inside guardrails that gave them a pit of success.

The engineers with their hands on the work understood straight away. Several managers saw something else: an AI doing all the work, about to replace the team. They were watching the horse count. What was really happening was a partnership, with people shaping the work and agents doing it, and that was the part worth scaling.

What I built in sixteen weeks

From July to October 2026 I put that approach to the hardest test I could set it: building a complete service around an agentic core, with me as the producer, shaping the work and directing the AI agents.

The service turns councils' paper-based forms into accessible online forms that meet GOV.UK standards. It has four parts:

  • An agentic conversion pipeline that takes a council's existing paper form and produces a working digital one, opened in the form designer for review.
  • A form designer, a visual canvas where a form is built, edited, tested and reviewed.
  • A citizen form runner, the public form itself, built on the GOV.UK design patterns so it is accessible and works for every resident, whatever device or connection they have.
  • An officer portal, where council staff manage their account, online services and submissions.
A conversion result headed Your form is drafted, converted in 13 minutes from parking-permit-renewal.pdf. A checklist on the left ticks off each stage, from examining the form to completing the service, with counts such as 36 questions and 12 screens. On the right, a preview of the drafted start page for a made-up North Shire Council, Apply for a residents parking permit, with a Start now button.
Figure 1. From paper to digital form. A council's PDF form converted into a working draft, ready for a person to review in the form designer.Screenshot of the service in development, with made-up test data.
The form designer showing the rodent treatment cash-back form as a flow on a dotted canvas. Sections run from Start through How to complete this form, Applicant's details, Treatment, Qualifying benefit and Pest control company to a summary, a confirmation page and End. A side panel lists the journey's facts: 7 pages, 11 questions, 6 sections and 1 route.
Figure 2. The form designer. A form on the designer's canvas, each section a step in the resident's journey.Screenshot of the service in development, with made-up test data.
A GOV.UK-style form page for a made-up council, Anytown Council, titled Apply for rodent treatment cash-back. The page asks which qualifying benefit the applicant receives, with seven checkboxes from Working Tax Credit to Universal Credit, a file upload for proof of benefit and a green Continue button.
Figure 3. The citizen form runner. One page of that form, as a resident sees it, built on the GOV.UK design patterns.Screenshot of the service in development, with made-up test data.
A dashboard headed 5,521 residents used your services in September, with a line chart of residents starting a form each month over a year. Below it, cards for the most used services, such as Garden waste subscription, Bulky waste collection and Blue Badge, each with a monthly count, a trend line, the share of residents who finish and the typical time to apply.
Figure 4. The officer portal. What council staff see of their online services: how many residents use each one, how many finish, and how long it takes them.Screenshot of the service in development, with made-up test data.

Dozens of real council forms have been through the conversion end to end, from simple two-page forms to complex ones running to dozens of pages of questions.

Building that conversion took over three months of concentrated effort to get right. It started as a single prompt to prove the idea, and grew into a pipeline of separate agents, each with one job, that now produces the same result every time and hands a finished form definition to the designer.

Underneath the product sits the evidence:

  • 1,991 commits across eight repositories.
  • Around 2,300 automated tests on the officer portal, with all 137 end-to-end scenarios passing.
  • 61 recorded architecture decisions, six of them later superseded, each with its reasoning.
  • More than 500 working sessions, every one of them journalled.

To be plain about where it stands: the service is built and proven end to end, but no council has used it yet. I'm not writing to sell it. I'm writing because it shows what this way of working can produce, and that is what I'd bring to your team.

How the production was run

Agents forget everything between sessions. A person on a team carries the project in their head; an agent carries nothing from one session to the next. So the production has to live in files, and my job is to keep those files good enough that every session starts exactly where the last one stopped.

Memory: the project lives in files

  • Wiki pages hold the specifications and explain how each part works, so any session can read the current design before it changes anything.
  • FigJam boards are where I think visually: the architecture, the conversion pipeline, the journeys citizens and officers take through the service, and the plan for the work. The agents read the boards too, and in reviews they add to them.
  • Journals and handovers record what each session did. The handover is overwritten at every close, never appended to, and it states what isn't done as clearly as what is.
  • Decision records capture every significant architectural choice and why it was made. When a decision is superseded the old record stays, so anyone can trace why the system is the way it is.
becomes the next session's only memory READ AT OPEN Handover what isn't done, stated Recent journal the last few sessions Friction ledger lessons, one line each Decision records rulings stay humanONE SESSION Open restate the brief firstWork agents build, a person rulesClose nothing left only in memory WRITTEN AT CLOSE Journal entry what happened, in order Fresh handover overwritten, never appended Ledger entries friction filed, not fixed Every repo pushed the record leaves the machine THE LONG-LIVED RECORD Wiki specs and how it works Decision records every choice, with its why FigJam boards design, journeys, plans Git history every change, reviewable becomes the next session's only memory READ AT OPEN Handover what isn't done, stated Recent journal the last few sessions Friction ledger lessons, one line each Decision records rulings stay human ONE SESSION Open restate the brief firstWork agents build, a person rulesClose nothing left only in memory WRITTEN AT CLOSE Journal entry what happened, in order Fresh handover overwritten, never appended Ledger entries friction filed, not fixed Every repo pushed the record leaves the machineTHE LONG-LIVED RECORD Wiki specs and how it works Decision records every choice, with its why FigJam boards design, journeys, plans Git history every change, reviewable
Figure 5. How each session picks up where the last one stopped. A session's only memory is the files. The opening ritual reads them and the closing ritual rewrites them, while the wiki, decision records and FigJam boards hold the long-lived record.

Control: shaping what the agents can do

Memory makes agents consistent. It doesn't make them right. For that, the work has to be shaped before an agent touches it: the pit of success again, applied to a whole build.

  • Open and close rituals. Every session opens by reading the handover, the recent journal and the lessons learnt so far. It then restates its brief, so that a misunderstanding can be caught before any work starts. Every session closes by writing its journal entry, rewriting the handover and pushing every repository, so nothing exists only in one session's context.
  • Builders and reviewers. The session that builds something never reviews it. Review happens in a separate session, and sometimes in many. On one occasion a checker was passing all its tests. Four agents were briefed to attack it, each from a different angle, with two more checking every finding: fifty-two agents in all. In about fifteen minutes they found four holes. One of them had survived nine earlier reviews.
  • The friction ledger. When something goes wrong it's logged as a single line, and the work carries on. Fixing friction on the spot derails a session; filing it means it gets dealt with properly, later. By late August, 21 of those lines had become six working principles.
  • Rulings stay with me. Agents recommend; they don't decide. That rule earned its place when a review found nine places where agents had credited me with quotes and rulings I had never given. Now anything that looks like a decision comes to me with a recommendation, and agents can't change the project's GitHub records directly. They write a file of intended changes, and a tested tool applies it.

What it cost

Discipline has a price, and leaving it out would give you a false picture. Sound rules compound. Each check made sense on its own, but together they began to slow everything down. At one point six sessions in a row went on reviewing and rebuilding one small part, and the service itself didn't move. The test run at each close grew to half an hour, even for a one-minute fix. My own words, filed in the friction ledger, put it bluntly: "a never-ending cycle of processes with very little progress on the service".

The way out came from the same habit of evidence. I had the build logs re-read, all 307 of them. In one full run of the API tests, the full test sweeps took about 56 of the 99 minutes, and across 26 sessions they hadn't caught a single defect that the targeted tests missed. So the sweeps were retired, by rule.

99 TEST MINUTES · 1 SQUARE = 1 MINUTE 56 min Full test sweeps Later defects caught across 26 sessions: 0 43 min Targeted tests on the change itself So the sweeps were retired, by rule. 99 MINUTES · 1 SQUARE EACH 56 min Full test sweeps Later defects caught across 26 sessions: 0 43 min Targeted tests on the change itself So the sweeps were retired, by rule.
Figure 6. Where the testing time went. Each square is one minute of one full run of the API tests. The full sweeps took about 56 of its 99 minutes and, across 26 sessions, never caught a defect that the targeted tests missed.Source: re-read of 307 build logs.

Process is something you tune as you go. On a team adopting agents, someone has to be watching for the point where it starts eating the product, and that someone has to be a person.

Typical AI use, and the difference

Most of the AI adoption I see falls into one of three patterns. Each one is watching the horse count.

Pattern How the AI is used What gets missed
Autocomplete with extra steps Suggestions bolted onto an unchanged way of working The work itself never changes shape, so the gains stay small
Vibe coding The agent builds, the tests go green, nobody records why Tests prove the agent's own assumptions, and nobody owns the decisions
Pilots that never ship Kept in a sandbox, away from real systems Nobody can assure what it produced, so it never reaches production

My approach works differently.

Approach How the AI is used What you get
A software production The work is shaped first, then agents follow patterns, summarise and do the grunt work A person holds every ruling, and the record shows why

The difference isn't the model or the tooling. It's who shapes the work, and whether the record lets anyone check it afterwards.

What to try first

You don't need a sixteen-week build to start. Three changes make the difference on any team:

  1. Give your agents a memory. A written handover and journal that every session reads before it starts and rewrites before it ends.
  2. Split building from reviewing. The session that wrote something never approves it, and some reviewers are briefed to attack it.
  3. Keep the rulings human. A named person owns every decision, written down with its reasoning.

Underneath all three is the lesson I most want to pass on. Agents aren't a replacement for your people. When the work is shaped and structured properly, it becomes a partnership: people bring the vision and the judgement, and agents bring patterns, summaries and tireless grunt work. That partnership is where the value is, and I can help your team build it.