Factory Governance
Factory governance defines what agents may do, how their work is judged and who can change the rules they operate under. People establish the policies, engineering standards and decision rights; the factory applies those controls as work runs.
Governance applies wherever work receives authority, a result is accepted or a rule changes. An agent may have permission to implement a change while needing separate review and approval before that change can proceed.
Bound the work an agent can do
Section titled “Bound the work an agent can do”Define the resources and operations each task needs. Reading an issue, editing code, merging a change and deploying it are different capabilities. Permission to perform one does not establish permission to perform the others.
Instructions tell an agent how to work. Tool permissions, credential scope and execution controls determine what it can actually do. A prompt asking an agent to leave a file unchanged provides no enforced protection if the agent retains write access to it.
Access controls and acceptance criteria address different risks. Restricting an agent’s permissions limits its reach; evaluating its output checks whether it performed the task correctly.
Decide how work is accepted
Section titled “Decide how work is accepted”Atomic workflows define outputs, acceptance criteria and routes for handling results. Governance establishes which checks and approvals are required, and who has authority to make the relevant decisions.
- Deterministic checks assess conditions that can be expressed mechanically, such as type correctness or a required test passing. A required check must be connected to a progression rule to block work when it fails.
- Agent evaluations assess qualities that need interpretation, such as completeness or architectural fit. Defined criteria and recorded findings make these judgements inspectable, though reviewers can still miss problems.
- Human judgement resolves questions of intent, trade-offs and acceptable risk. People can make these decisions before implementation, as well as review completed work.
For example, a team might require approval of a design before implementation begins, then use tests and agent evaluations to assess the result. The workflow routes work according to those outcomes. The implementation agent supplies its output and evidence; the workflow determines whether the conditions for progression are met.
An approval authorises a specific request, such as accepting a particular version of a design. Its scope matters: approving that design does not also authorise deployment. A decision records a question, the options considered, the chosen outcome and the reasoning behind it. Together, they explain what was authorised and why a particular approach was chosen.
Keep the rules and decisions traceable
Section titled “Keep the rules and decisions traceable”Versioning workflows, policies and standards lets you establish which rules governed a result. Record the versions used for the work so a later rule change doesn’t obscure how an earlier result was judged. Creating a new version and choosing when it takes effect are separate decisions.
For each acceptance or approval, retain the subject, applicable rules, evidence and the person or process that authorised it. This makes it possible to examine why work proceeded: whether a check passed, an evaluator accepted the result or a person approved an exception. Preserve that history when a decision changes, so the original reasoning and its replacement remain distinguishable.
Govern changes to the factory
Section titled “Govern changes to the factory”Changing a workflow, acceptance check or approval requirement changes how later work is performed or judged. Establish who can propose each change, what evidence is required and who can authorise it to take effect.
Repeated findings might justify a stronger check. Repeated human decisions might reveal a stable rule that can be automated. Automated decisions that need frequent correction might justify more human review. Assess these changes against your team’s objectives for quality, completion time, cost and human effort.
Self-Improvement explains how run evidence becomes a tested proposal. Proposing an improvement does not grant authority to activate it.