# Governance is how the work is made, not a document about it Status: draft. Owner: Andrew Flett. Last reviewed: 2026-09-04. Canonical: https://agentic.madebymany.com/principles/governance-is-how-the-work-is-made Governance is one word doing four jobs, and this page does one of them. Procurement means the questionnaire: which tools, where the data goes, who the subprocessors are. Legal means who owns the output and who pays when it is wrong. Brand means whether a thing made with AI says so. Those three are answered from a document, and they are hygiene. The fourth is how the work is governed, and that is the same question as how the work is made: what an agent may do on its own, who reads what it produced, and who answers for it. That question is ours, and it is answered here in the way the work is built rather than in a policy beside it. ## What an agent may do without a person An agent may commit, and it may open a pull request. It may not merge its own work, trigger a production deploy, send anything to a client, spend anything, or widen its own remit. That is the posture of every loop in the suite, propose-only by default, and it is relaxed only by an explicit decision by a person, recorded where it can be found. Before an agent starts on a piece of work a person is named as the one it acts for, and that name is what a client gets when they ask who was responsible. A backlog that drains itself with nobody triggering each item is deliberately out of scope, because it removes the person as the driver. What we do not hand to an agent at all, research with real participants, accessibility judgement, anything that would ship unread, is the line [judgement stays with people](/principles/judgement-stays-with-people) draws, and the reason [reaching further](/principles/ai-takes-people-further) is worth it. ## Review means someone read it We do not say "human in the loop", because it can mean anything from a person reading every line to a person who was in the building. Review here means a person read the change and decided it was right. A generated change meets the same bar as a written one, and there is more generated than there used to be, so there is more to read rather than less. Agents made a change cheaper to produce and no cheaper to review. The gates go first, so that reading is spent well. Formatting, types, tests, accessibility, visual regression and performance budgets run on every commit and every pull request, and a change is proven before anyone gives it attention. The reviewer's attention then goes to whether the change is right, not whether it is tidy. A gate enforces defects and never house style: a build that fails over punctuation is enforcing the wrong thing. ## Every checkpoint has a name The checks a machine cannot make are placed where they are irreducible and given a name. On a small senior team one person often carries several of these; the list names the responsibility, not a headcount. - **Merge review.** A senior or design engineer reads every change on its way in, whether a person or an agent raised it, and merges it. The gates have already passed; the question left is whether the intent is met. - **Manual and assistive-technology QA.** One QA specialist, embedded in the team, runs the exploratory pass on critical journeys, the keyboard and screen-reader passes, and the real-device pass on the agreed matrix. - **Release sign-off.** The accountable owner, the client or the product owner, makes the decision to go live, and it is recorded against the deployment rather than said in a channel. - **Acceptance.** The delivery lead and the stakeholder judge whether the work meets the spec's success criteria, which is a different question from whether CI is green. Design and domain review, meaning taste and business logic before anything is built, and spec and triage come before all of these. ## Provenance travels with the change Every commit an agent makes names the model that made it, as a co-author on the commit itself, and every pull request names the person who read it and merged it. That is the whole of what a client is asking for when they ask what was generated and who checked it, and it lives in the repository they own rather than in a report we send them. The test in the strapline is answered by the log: if a change caused an incident tomorrow, the model that wrote it and the person who approved it are both on it. ## A model is a decision we record Which model does the work, and at which tier, is a decision about the project, and it is written down beside the rest of the stack rather than left to whichever tool happened to be open. When a model is deprecated or its behaviour shifts under a live product, the change is made the way any other dependency change is made, through a pull request a person reads, and it leaves the same trail. Nobody is asking this yet. They will, and the answer costs nothing to have early. ## What a client gives us stays theirs Client material goes nowhere the client would not expect. That covers the cases that predate agents, a name on a public page or a document in a repository, and the one agents make new: material pasted into a hosted model, which is retained by whoever runs the model on terms most people have not read. Planning material carrying a client's own words is kept out of the repository entirely. The public pages collect nothing about the people reading them, no analytics, no tracking, no cookie, and where we set up analytics on a client's product, the skill that does it is written privacy-first: no personal data in event properties, and cookieless wherever the tool allows. Three rules sit under all of that. The data flow is drawn before the work starts: what leaves the client's estate, where it goes, what comes back, on one page the client can read and object to. The tools we run are set not to train on what we send them, and a tool that cannot be set that way does not see client material. Where the client's boundary is the rule, their tenancy, their tools, their approval before anything crosses it, we work inside that boundary rather than beside it. Which material may reach a hosted model, what a provider retains, and when a client is told are the [client data and confidentiality position's](/positions/client-data-and-confidentiality) to answer. ## It is in place, and it travels Where software is built, every gate and every checkpoint above is in place and named. Elsewhere the check is a reader, and provenance travels instead: a position served into a deck carries its status and its date, so a draft is never quoted as settled. ## Related agentic skills - [mxa-orchestrate](https://agentic.madebymany.com/playbook/skill/mxa-orchestrate) - [mxa-verify-merge](https://agentic.madebymany.com/playbook/skill/mxa-verify-merge) - [mxa-verify-promote](https://agentic.madebymany.com/playbook/skill/mxa-verify-promote) - [mxa-stack](https://agentic.madebymany.com/playbook/skill/mxa-stack) - [mxa-measure](https://agentic.madebymany.com/playbook/skill/mxa-measure)