--- title: "AI agent governance patterns: how people approve, check and audit agent work" slug: harness-ai-agent-governance-patterns date: 2026-10-02 excerpt: "A reference of thirteen patterns for taking AI agents to production: what a person sees at an approval, who checks the work, what gets written down when nobody is at the desk, and what an audit log has to hold. Each one is tied to how a shipping harness behaves, with a declared method and a last-verified date." featured_image: "https://bbtxujdxvidaghmhxkqs.supabase.co/storage/v1/object/public/generated-images/blog-1790973843628-harness-ai-agent-governance-patterns.webp" featured_image_alt: Illustration of a wooden desk with a paper document under a magnifying glass, a rubber stamp beside it, and an open ledger book with a ribbon, lit by a teal desk lamp. author: Kinan Hamwi author_url: https://www.linkedin.com/in/kinanhamwi/ canonical_url: https://cerevisor.com/blog/harness-ai-agent-governance-patterns updated_at: 2026-10-02T20:44:05.680009+00:00 --- # AI agent governance patterns: how people approve, check and audit agent work By the founder of Cerevisor. Last verified 2 October 2026 against Cerevisor 3.7.1. Method and limits are at the end. TLDR Governing AI agents in production comes down to four jobs: a person approves the right thing, someone other than the builder checks it, choices made with nobody at the desk get written down, and the record of a run can be trusted afterwards. This page lists thirteen patterns that do those jobs, the failure each one prevents, and the exact behaviour of one shipping harness for each. It is meant to be cited when a team designs its own approval and audit rules. On 30 September, [Claude Code](/blog/harness-supervisory-engineer-org-chart-box) shipped a fix that reads like a confession from the whole industry: “Fixed background jobs showing done while waiting for your approval.” A job that says done while it is waiting for a yes is the governance problem in one line. The approval existed. The record of it was wrong. I build Cerevisor, a harness, which is the software that runs AI agents, hands them their tools, and decides what they are allowed to do. An agent here means an AI model given a task and tools and left to take several steps on its own. Version 3.7.1 went out today, and a large part of it was not about making agents smarter. It was about the moments where a person says yes, where a second agent says pass, and where nobody is there to say anything. So this is a reference, and it will stay one. Thirteen patterns, grouped by the job they do. For each I give the failure it prevents and how Cerevisor behaves, checked against the source code today. Where another tool shipped the same idea in the last ten days, I say so. --- ## What an AI agent governance pattern is, and the four jobs it covers A governance pattern is a repeatable rule for how people stay in charge of agent work. It is a design decision in the harness, the kind that still holds at four in the afternoon on a Friday when a policy document is the last thing anyone opens. The patterns sort into four jobs. Thirteen patterns, grouped by the job they do JobPatternFailure it prevents **Approve**1. Show the work, not a summary of itApproving a description 2. Give a third answer: ask for changesApproving flawed work to avoid a restart 3. Ask again when the work changedA yes that lands on a newer version 4. Treat silence as a noA run that proceeds because nobody answered 5. Tell the next agent who approved, and whenApprovals that vanish downstream **Check**6. Write down what done means before buildingGoalposts that move to fit the result 7. A checker that did not build the workSelf-graded homework 8. A verdict only counts if the checker left the files aloneA checker that fixes its way to a pass **Run unattended**9. Make unattended a declared mode with two consentsDrifting into autonomy by accident 10. Keep a decision record per itemChoices nobody can reconstruct 11. Bound the tries, the spend and the blast radiusA loop that retries all night **Audit**12. No record, no runWork that happened with no trace 13. Be honest about what replay meansTrusting a re-run as if it were a recording --- ## AI approval workflow patterns: what the person at the checkpoint sees An approval checkpoint is a point in a workflow where the run stops until a person answers. Most tools have one. The patterns below are about what makes that stop worth something. **Pattern 1: show the work, not a summary of it.** Before 3.7.1, our approval card showed a snippet of the agent’s chat reply. That is an agent describing its plan, which is a different thing from the plan. Now the review panel shows the documents the agent actually wrote, one tab per file, up to four of them, formatted the way they would read in a file viewer. A very long file shows its first part and says it was cut. The agent’s own closing message is folded away underneath, where a sales pitch belongs. **Pattern 2: give a third answer.** A checkpoint with only yes and no pushes people toward yes. Saying no stops the run and wastes the work so far, so a plan that is nine tenths right gets waved through. Cerevisor now has three answers: Approve, Stop here, and Ask for changes with a note. Asking for changes sends the agent that wrote the [work back](/blog/harness-ai-coding-assistant-takeover-gap) to revise it with that note and its earlier files, then the same approval returns with the new documents. This is capped at three rounds per approval in one run. After that, only Approve and Stop here are offered, because a fourth round of notes is usually a sign the request itself needs rewriting. **Pattern 3: ask again when the work changed.** Here is a failure that only appears once pattern 2 exists. One agent’s work can feed two approval steps. A person asks for changes at the first, and while the agent revises, the second card is still open on screen showing the old version. Clicking Approve there would approve work that no longer exists. Cerevisor tracks which version each card showed. If the version moved, the approval is not taken at its word: the same step asks again with the new documents and the line “The work changed since you last looked.” A Stop is always honoured as given, since “do not run this” is never made wrong by newer work. **Pattern 4: treat silence as a no.** In an ordinary Cerevisor run, an approval that nobody answers settles as a rejection. The default window is five minutes, and a workflow can save its own. The timeout is written to the audit log, and a click that arrives shortly after the window closed is logged as arriving late instead of disappearing. 5 min default window before an unanswered approval in an ordinary Cerevisor run counts as a no The opposite default also has a place. When a person has declared they are at the desk (the attended setting of Factory mode, described below), nothing waits against a clock: the approval waits until it is answered or the run is stopped. The principle is that the timer follows a stated fact about whether someone is there. It should never be a guess. **Pattern 5: tell the next agent who approved, and when.** An approval that only lives in the interface is lost the moment the next agent starts. Cerevisor passes one line into the next agent’s instructions saying that the person running the workflow approved this output, and at what time. If no person was involved, the line says the approval was automatic and that the run was unattended. The receiving agent, and anyone reading its instructions later, can tell a human yes from a machine yes. The same concerns showed up in other tools this week. The Claude Code changelog for version 2.1.286, dated 30 September, includes this: > "Added a count such as "2 of 5" to the permission prompt when several permission requests stack up" Claude Code changelog, version 2.1.286, 30 September 2026 Two days later, version 2.1.288 changed waiting prompts to show the oldest first, “so a new prompt no longer covers the one you’re reading.” Our review panel does the same, one request at a time, oldest first, with a count of how many are waiting. When two teams land on the same queue rule in the same week, it is probably a real pattern and not a taste. GitHub went a different way on 22 September with assisted approvals for Copilot in JetBrains: “Low-risk tool calls receive automatic approval, while higher-risk actions continue to prompt you for a decision.” That is a sixth approval idea worth knowing, sorting requests by risk so fewer reach a person. It trades fewer interruptions for trust in whatever does the sorting, so the question to ask is where the sorted-away decisions get recorded. --- ## Independent checking: why the agent that built the work cannot sign it off An approval covers the plan. Something still has to judge the result. **Pattern 6: write down what done means before building.** In Cerevisor’s ready-made Factory workflow, the planning agent writes a numbered list of acceptance criteria, meaning statements that must be observably true when the work is finished. Each one says how to check it: a command and what it must print, a file and what it must contain, or a behaviour and how to see it. The building agent aims at that list and is told not to edit it. That instruction is a request, not a lock, and I would rather say so than imply otherwise. **Pattern 7: a checker that did not build the work.** A separate agent, which I will call the checker, judges the result against the request and the criteria. It had no part in building. It is told to use the result the way a person would before reading any code, and to change nothing. Its verdict is a short file: the first line says pass or fail, then each criterion gets one of three results, met, not met, or could not check. Two rules about reading that verdict matter more than they look. Could not check is not a pass. And a pass that still lists a criterion as not met contradicts itself, so Cerevisor trusts it neither way and treats the work as unchecked. A missing verdict counts the same. An item is done when the check passes. The builder saying so does not count. Key Insight A verification step has three outcomes, not two. "Could not check" must be its own result, and it must count against the work. Any design that folds it into pass will, sooner or later, pass something nobody looked at. --- ## The failure we named: a checker that fixes the work it is judging **Pattern 8: a verdict only counts if the checker left the files alone.** This is the pattern I would most like other teams to copy, because the failure is so natural. A capable checking agent finds a broken test. It is helpful by training. It fixes the test, runs it again, and writes pass. The verdict is now true and worthless, because nobody checked the fix. The fix in Cerevisor: in a project that uses git, the version history tool most software teams use, the harness takes a fingerprint of the project when the checker starts. A fingerprint is a short code computed from the files, which changes if any file changes. It takes another when the run moves on or ends. If anything the checker should have left alone has changed, the verdict is thrown away and the item goes to a person with the message “The checker changed project files, so its verdict was not used.” That ending is never retried automatically, since a second try would invite the same behaviour. New files that appear while the checker runs, such as test output, do not count as a change. Edits to files that existed before do. This pattern has honest limits, and a reference should carry them: - It works only in a git project. Outside one, the checker is trusted without the comparison. - If the project holds more than 5,000 files, or 200 MB, that are new and not yet saved to the history, the first fingerprint is not taken. The item keeps its status, and both its summary and its decision record say the comparison could not be made. - Build output that already exists, is not on the project’s ignore list, and gets rewritten by the checker’s own test run counts as the checker changing files. A good item is refused. The fix is one line: put build output on the ignore list. That last one is easy to hit and confusing the first time, which is why it is written into the documentation. The full behaviour is in the [Factory mode guide](https://cerevisor.com/docs/guides/software-factory). > A checker that can edit the work can make any work pass. Read access is what makes a verdict mean something. --- ## Running with nobody at the desk: the decision record and the limits Unattended means the run carries on with no person available to answer. It is where governance usually thins out, so three patterns belong here. **Pattern 9: make unattended a declared mode with two consents.** In Cerevisor’s Factory mode, a queue of work items that one workflow processes one at a time, attended and unattended are separate settings. Unattended needs two agreements: one saved in the workflow, and a one-time agreement on that specific computer. The second does not travel with the [workflow file](/blog/cerevisor-v34-v35-share-and-steer). So a workflow received from a colleague, already set to unattended, will not start that way on a new machine until its owner confirms there. What changes in the mode is spelled out. Agents lose the tool for asking questions and are told nobody is there. An agent whose only job is to interview the person is left out of the run. Approval steps pass at once. A permission request that arrives mid-run is refused automatically. **Pattern 10: keep a decision record per item.** Every one of those automatic choices is written to a plain text file in the item’s own folder. Each entry has what was asked, what was answered, and who answered. The who column is the point. In our file it takes values like “you”, “decided by the model”, “the factory (unattended)”, “nobody answered in time” and “refused automatically (unattended)”. It also lists which model was chosen for each agent, and a warning when a model’s cost could not be counted against the spending limit. A draft circulating at the IETF, the internet standards body, points the same way. Revision 06 of the Agent Audit Trail draft, dated 29 September, proposes a common record format for agent actions and includes an optional field that “captures human interventions.” It is one author’s individual draft and not a standard. But the instinct matches: who decided belongs in the record itself. **Pattern 11: bound the tries, the spend and the blast radius.** Four limits, each quoted from the product: - A failed item is tried again, three times in all by default, adjustable from one to five. Each new try starts from the last one’s work and is told what went wrong. - An unattended item with no spending limit set stops at US$5. The limit is checked between tries and never during one, so a single try can take an item past it. The next try is then not started. - Three items in a row that do not finish pause the whole queue. - Finished work is saved as local snapshots on a separate branch, a side line of the project’s history. Nothing is pushed to a shared server, merged or rebased. What happens to that branch is a person’s call. Some endings are never retried at all: a person pressing Stop, a declined approval, a checker that changed files, a run that could not be recorded. Retrying those would either repeat the problem or override a human decision. --- ## The AI agent audit log, and what replay honestly means An audit log is a file that records what happened in a run, in order, and is only ever added to. Cerevisor writes one per run to a folder on the user’s own computer. It holds each approval requested and how it was settled, each permission decision, each tool call, and the full instructions each agent received. It is a local file, readable in any text editor, which is the point of a [local-first harness](https://cerevisor.com/docs/guides/building-workflows/run-and-monitor). **Pattern 12: no record, no run.** Alongside the log, each run is recorded to disk as it goes. If that recording cannot be written, the default is that the run stops. A person can switch to the opposite setting and let runs continue unrecorded, but they have to choose it. I think this default is right for any tool that acts on real files. An agent that works with no record is hard to tell apart from one that did something else. The Claude Code release of 2 October fixed a cousin of this problem, permission requests that ended unanswered and left no decision event behind. Gaps in the record are the thing to hunt. **Pattern 13: be honest about what replay means.** Replay is the most oversold word in this area. A [language model](/blog/small-language-model-laptop-no-gpu) does not give the same output twice, so re-running a workflow is a new run and proves little about the old one. What a harness can honestly offer is two different things. The first is a recording: the stored outputs and events of the original run, readable later exactly as they were. The second is a partial re-run: in Cerevisor, resuming from one agent re-runs that agent and everything after it while keeping every other agent’s recorded output from the last run. One is evidence. The other is a way to continue. A team’s audit rules should say which one they mean. --- ## What to ask AI governance tools before trusting their approval step Most AI governance tools are sold on dashboards. The patterns above turn into plainer questions for a demo, and they work on any product, ours included. - At an approval, does the person see the actual document, or the agent’s description of it? - Is there an answer between yes and no, and is it capped? - If the work changes while an approval is open, what happens to a yes? - What does an unanswered approval become, and after how long? - Can the checking agent write to the project? If so, how would anyone know it did? - Is “could not check” a separate result, and does it count as a fail? - When nobody is at the desk, where is each automatic decision written, and does the record say who decided? - If the run’s record cannot be written, does the run continue? A vendor that answers all eight from memory has thought about this. So has one that says “I don’t know, let me check the code,” which is the answer I trust more. --- ## How this reference was checked Every statement about Cerevisor on this page was checked on 2 October 2026 against the source code of version 3.7.1, by finding each number and each behaviour in the code and reading the function that uses it. Where the release notes and the code could have differed, the code was followed. Each number is quoted as it appears in the product and none is calculated from another. The three outside sources were opened on the same day and each is dated inside the ten days before publication: the Claude Code changelog (versions dated 24 September to 2 October), the GitHub changelog entry of 22 September, and the IETF draft revised on 29 September. Quotations are verbatim. I make no claim about how those tools behave beyond what their own notes say. What this page does not contain: a benchmark, a comparison ranking, or any measure of how often these patterns catch a real problem. I do not have that data in a form I would publish. The patterns describe mechanisms, and the page will be updated with a new verified date when the mechanisms change. --- ## Start with one workflow and three patterns Thirteen is too many to adopt at once, and most teams do not need all of them on day one. If I were starting over, I would pick one workflow that already runs every week and add three things this month. - **Put the document on the approval** Change one approval step so the reviewer reads the plan itself. In Cerevisor this is an approval connection between two agents, described in the [control flow guide](https://cerevisor.com/docs/guides/building-workflows/control-flow-conditions-loops-gates). - **Add a checker that cannot write** Give a second agent the criteria and the result, and no permission to edit. Make it the last step. Count "could not check" as a fail. - **Read one decision record end to end** Run one item with nobody answering, then open the record and see whether a stranger could tell who decided what. If not, that is the first thing to fix. - **Write the rule down** One paragraph: what needs a human yes, what silence means, and where the record lives. That paragraph is the governance policy. The rest is implementation. The approval and Factory features described here are in [Cerevisor 3.7.1](https://cerevisor.com/releases/v3-7-1), and the patterns themselves are free to take into any tool. None of this needs a governance programme with a steering committee. It needs someone to decide, once, what a yes means. #### Sources - [Claude Code changelog, versions 2.1.282 to 2.1.288](https://code.claude.com/docs/en/changelog) - Anthropic, 2026-09-30 - [Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems (draft-sharif-agent-audit-trail-06)](https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/) - IETF Datatracker, 2026-09-29 - [New features and improvements in Copilot for JetBrains](https://github.blog/changelog/2026-09-22-new-features-and-improvements-in-copilot-for-jetbrains/) - GitHub Changelog, 2026-09-22 - [Cerevisor 3.7.1 release notes](https://cerevisor.com/releases/v3-7-1) - Cerevisor, 2026-10-02