In innovation work the same question always comes back, and usually only after something is already running: who is allowed to build this. Not who is able to, because that turns out to be most people once they hold the tools. Who is allowed. Who looks at it. Who rolls it back when it goes wrong on a Tuesday night.
Anthropic published a customer story this week about ABC Legal, a US company that delivers legal documents. The case itself is not the interesting part. Large company adopts AI and it goes well, you know that story. What it does contain is four concrete agreements that opened up building outside the IT department without letting the place run wild. Those agreements come apart from the product they are described in, and that is what I wanted out of it.
What happened, briefly
CTO Brandon Fuller rolled out Claude Enterprise to 1,100 employees. People started automating their own work unprompted, which is delightful until you ask where those automations actually live. The answer was: on laptops, as scheduled tasks on individual desktops. Every builder had their own corner and nobody had a view of the whole.
Fuller moved everything onto Claude Managed Agents, the managed platform where agents run in the cloud rather than on someone’s machine. Then he took the fifteen-person steering committee from finance, marketing, operations and development, none of them software developers, and had them clone the repository and build an agent themselves using Claude Code.
Within a week all fifteen had something working. Those fifteen trained their own teams. Within a month more than fifty agents were running, each with a name, an owner and one job.
The line that stayed with me longest is not about AI at all:
“I had to explain what a PR was to them. A lot of them thought it meant running, like a PR, the fastest you can.”
The barrier was cloning, branching, opening a pull request and waiting on somebody else. Not the model.
The four patterns
| Pattern | What it governs | What it costs |
|---|---|---|
| Agent as code | Nothing changes except through a reviewable change | Everyone has to learn git |
| Human in the loop as the starting position | A new agent recommends, a person decides | Slower start, somebody has to actually look |
| The PR as control surface | Approval, line comments and an immutable trail come free | Only works if the decision fits in text |
| Harvest and tune | Feedback becomes a proposed change, not a retrain | Two extra agents per agent treated this way |
An agent is text, so it belongs in a repository
Fuller has every agent defined as code. His reasoning: an agent is structured text, a prompt plus configuration, and anything that is text can live in a repository where the whole company can see it, review it and improve it. Prompt, tool list, schedule, credentials and memory all sit in configuration files next to the regular software. Nothing about an agent changes except through a pull request.
It makes building an agent visible to colleagues who are not working on it, which is more than version control on its own. A prompt on somebody’s laptop is a private arrangement with a model. The same prompt in a repository is a document other people can comment on.
Their next move goes the same way. They are hunting for more things that can exist “as code”: notification templates, event routing rules, dispatch logic. Anything that lands in a repository is something an agent can read and propose an improvement to.
Every agent starts by recommending
No agent starts out acting on its own. Every new one posts a recommendation for a human to review first. Only after it demonstrably agrees with human decisions often enough does it earn the right to act alone. Fuller: “Every agent earns trust before it acts alone. It doesn’t start there.”
That is a promotion path rather than an on switch, and that is the difference from how most organisations handle it. Usually “may this agent act independently” is a yes or no answered up front, in a risk assessment, by somebody who has never watched the agent work. Here the answer comes out of watching.
Where I think this pattern has a hole is further down, under the caveat.
Make the decision look like a pull request
This is the one I am taking. Fuller: “If you want an agent involved in a decision, make the decision look like a pull request.”
Once a decision has that shape you get line-by-line comments, an approval workflow and a trail nobody can edit afterwards, without building any of it. It comes free with version control. And it works for humans and agents at the same time, because both of them write text.
The limitation sits in the same sentence: the decision has to fit in text. A judgement call made across a table by four people who can see each other’s faces does not become a pull request without something going missing.
Harvest, tune, repeat
For the agents whose output actually gets graded, they use three roles that share one workspace and one credential vault but run on different schedules:
- The initial agent does the work as a job comes in and records an audit trail of every action.
- The harvester runs hourly or daily and gathers human feedback from Slack, where it arrives as thread replies and emoji reactions. Each one becomes a labelled data point.
- The tuner runs weekly, looks at everything at once, and proposes a change to the prompt or the config. Not to the model’s weights. It only drafts. A human reviews and merges the pull request.
Nothing gets retrained here, there is no dataset and there is no separate process. Feedback enters through the place where people already react and leaves through the place where changes already pass.
And they are honest about the scope: most of the fleet does not get this. Most agents are single-task runners whose output nobody grades, and they work alone.
The numbers, with the measurement attached
Measured July 2026, published 17 August 2026, by the vendor of the product.
- More than 50 agents in production. Each with a name, an owner and one job.
- Roughly 310 employees using Claude daily. Out of 1,100 staff that is 28 percent. The company-wide adoption the opening suggests is a bit over a quarter of the organisation.
- Up to roughly 50 percent lower cost for the human tasks some agents cover. Four hedges in one sentence: “up to”, “roughly”, “some”, and it is the cost of the task rather than of the department. It says explicitly that this was measured before heavy optimisation.
- Spend climbed through the spring and started falling in July while usage kept growing. No figures, no chart.
That last one tells me the most and is worked out the least. Cost falling while usage rises is exactly the claim you want a table for, and there isn’t one.
There is not a single incident in it either. No agent that got something wrong, no rollback that was needed, no example of a pull request that was rejected. In a piece about earning trust, the missing case where trust was taken back is the most conspicuous gap.
What I am taking from it
I design workshop formats where people without a programming background build something themselves. What keeps happening in the room: the building works, and afterwards there is a thing nobody knows where to put. That is exactly the problem ABC Legal started with, on the scale of one afternoon instead of 1,100 people.
Three things I am taking.
Move the question from “are you allowed to build” to “where does it end up”. Arranging permission up front is slow and it governs the wrong thing. If the agreement is that everything you build lands in a shared repository, then building is free and being visible is the price.
Treat the git hurdle as the real hurdle. I have been getting this wrong myself. My workshop formats explain prompting and say nothing about version control, while that is precisely where participants get stuck afterwards. Explaining the model takes ten minutes. Explaining why you submit your work to somebody else takes longer, and it is not a technical explanation.
Start with recommending, even when it feels slow. In a setting where decisions are made about people, an agent that recommends and a human who decides is not the intermediate step. It is usually the destination, and it is allowed to stay there.
What I am not taking is the assumption underneath it: that an agent can earn its way out of the loop. In public services that works differently, and that is the first caveat.
The caveat
The default shifts from “a person decides” to “a person once approved”. The criterion for independence is that the agent consistently agrees with the human decision. That is agreement, not correctness. If the human was systematically getting it skewed, an agent that faithfully reproduces the skew is qualified for independence under this criterion, and from that point nobody is watching. At a document delivery company that is a business risk. On a decision about somebody’s benefits it is a different thing. “What are we measuring this against” therefore matters more than “may it act alone”, and the piece does not answer the first question.
Responsibility lands with whoever clicks merge. That is the intent and it is tidier than what came before, where nobody knew. But it is also a marketing employee approving a change to an agent that touches customer records. A pull request produces a trail, not expertise. The risk is that everything looks reviewed because every change passed an approval, while the approver could not see the consequences. Anyone adopting this process also has to settle who is allowed to sign off on what, and that is not one of the four patterns.
What drains away is knowledge of the work itself, and the exit narrows at the same time. The account manager who used to pull those records by hand every week no longer does. That is the win, and it is also the moment nobody notices the report has been returning the wrong selection for three weeks. On top of that comes the second movement: the harness, the models, the console, the billing and the memory all come from one vendor in this design. The agents themselves do sit as text in your own repository, which means prompts and configuration travel with you if you leave. The runtime that executes them does not, and neither do the agents that have run for two years without anyone remembering how the manual version went. For a public sector organisation that is not a technical trade-off but a sovereignty question, and you ask it up front or not at all.
What I do myself: take the PR pattern, leave the promotion to independence, and write down for every agent how the work was done without it. That last one costs half an hour and it is the only thing that keeps an exit open.
Frequently asked questions
Do I need Managed Agents to use these patterns?
No. All four are product-independent. Agents as text in a repository, a promotion path from recommending to acting, decisions shaped as pull requests, and feedback returning through that same pull request: for that you need git and a place where people react. What the platform adds is execution without infrastructure of your own, plus versioning on every push, sessions you can replay, per-workspace billing and scheduling for recurring runs.
How is this different from Spotify’s agent fleet?
Who builds. At Spotify the agents run on the codebase and the builders and reviewers are engineers; everything there turns on verification, because a pull request merges automatically without anyone seeing it. At ABC Legal the builders come from finance and marketing and everything turns on visibility, because the reviewer is meant to look. Both fleets use the pull request as their control surface, for exactly opposite reasons.
Does “the PR as control surface” work for decisions that are not code?
Only if the decision fits in text. A recommendation memo, a routing rule, a template, a configuration: fine. A judgement call between four people in a room does not become a pull request without something going missing. The form demands that a decision consists of a proposal plus an approval, and not every decision has that shape.
How much of the company actually used this?
Roughly 310 of 1,100 employees, so 28 percent, measured in July 2026. The source headline says “every employee into a builder”; the number of people who actually built an agent is the fifteen from the steering committee plus the colleagues they trained, and that number is not given.
Sources
- Anthropic, How ABC Legal turned every employee into a builder with Claude Managed Agents, 17 August 2026
- Claude Platform Docs, Claude Managed Agents overview, accessed 19 August 2026
- Earlier work: A chatbot answers. An agent just does it., 11 July 2026
- Earlier work: How Spotify lets Claude loose on 20 million lines of code, 5 July 2026
Checked on 19 August 2026 against the customer story and the product documentation. Every figure here comes from Anthropic’s own article about their own product; there is no independent measurement and no counter-account from another party. I have not spoken to ABC Legal and have not seen the agents. The percentages are my own arithmetic from the absolute numbers given (310 of 1,100). The roughly 50 percent cost figure carries four hedges in the original and concerns the cost of the tasks agents take over, not the cost of the organisation. The four patterns are taken directly from the best-practices section of the source; applying them to public services, and the caveats, are mine and are not in the source.