4. The human–agent operating model

Adding agents to an engineering organization does not tell the organization how to work. Someone still has to decide who defines the outcome, who may plan, who may change a repository, who validates, who accepts, and who is on the hook when it goes wrong. This chapter is the answer to those questions, written as a design: the responsibility split between people and agents, the roles on each side, the decision rights that never move, the governed lifecycle every Mission passes through, and the handoff and escalation contracts that let work continue when the person who started it has gone home. After reading it you should be able to assign every decision and every action in a factory to the right owner, and redraw the same model for a five-person startup and a regulated enterprise.

The problem

Without an explicit operating model, organizations fall into one of two failures. In the first, humans inspect every action. Operators become the bottleneck, learn to approve routine work without understanding it, and governance survives in form only — the approval theater described in Chapter 3. In the second, humans surrender control to systems that cannot own business risk. Agents infer authority from prompts, validate their own output, and convert "the task finished" into "the business accepted it" — unsafe autonomy.

The reason both happen is that traditional organizations keep authority in job titles, meetings, and tacit knowledge. A senior engineer knows which change needs security review. A product manager knows when scope has drifted. A release manager knows which deployment needs an executive decision. Almost none of that is written into the delivery system. Agents cannot safely inherit ambiguity. They act through tools at machine speed, across shifts, and may continue when the initiating person is unavailable. Their reasoning is probabilistic, their context is bounded, and their output sounds more certain than the evidence allows.

Agent governance then fails in predictable ways: a policy with no decision owner, a system owner who does not know their autonomy ceiling, reviewers who approve without independent evidence, incident authority that depends on finding an executive. The fix is not more committees. It is a small, explicit authority system with durable inputs and outputs, escalation paths, and independent assurance — organizational design expressed in software.

How it works

Human-led, agent-executed

The traditional model runs humans plan → humans implement → humans test → humans review → humans deploy → humans investigate → humans document. The target model runs: humans establish intent, constraints, priorities, and risk tolerance → agents investigate and plan → humans review consequential decisions → agents execute → automated systems validate → humans approve according to risk → agents deploy, observe, and continue learning. Human-led does not mean human-performed; agent-executed does not mean agent-authorized. Delegating execution never delegates accountability, and human leadership moves upward — from supervising activity to designing the system in which activity is safe and valuable.

Humans own product vision, business priorities, customer understanding, ethical judgment, architectural direction, risk tolerance, tradeoff decisions, high-impact approvals, exception handling, team development, strategic learning, and final accountability.

Agents perform requirements analysis, codebase investigation, dependency analysis, implementation planning, code generation and modification, refactoring, unit, integration, and regression testing, security and dependency analysis, documentation, pull-request preparation, log and telemetry analysis, incident triage, root-cause investigation, release preparation, environment validation, routine operational work, evidence collection, and continuous-improvement proposals.

Shared human–agent work is where the model earns its credibility against "agents replace developers" stories: architecture, product design, complex debugging, incident response, acceptance criteria, risk evaluation, experiment design, code review, release decisions, postmortems, and strategic prioritization. The future is not humans versus agents; it is human judgment multiplied by autonomous execution.

Three parties, not two: the responsibility model

The humans-own / agents-perform split leaves out the party that does most of the governing. A factory has three kinds of actor, and the third is the one people forget when they draw "human in the loop" as a person watching an agent.

Stated plainly, the three actors divide the work like this. Humans define intent, constraints, priorities, risk, and consequential decisions. Agents investigate, plan, use tools, modify software, and execute bounded work. Deterministic code enforces contracts, scope, identity, tests, verification, evidence, security boundaries, currentness, and acceptance gates. Every row in the table below is a consequence of that division, and every failure mode later in this chapter is one of the three actors doing another's job.

Agents propose and execute. Deterministic systems validate and govern. Humans retain decisions whose consequences require judgment or authority. The sentence does real work. Every time a human is asked to check something a deterministic system could have checked (was the diff inside scope? did the tests run against this commit? is the budget exhausted?), the operating model has leaked a machine job onto a person, and that leak is what eventually produces approval theater. Every time an agent is allowed to decide something a deterministic system should decide (may I call this tool? is my work current?), authority has leaked into a probabilistic component. The design goal is to route each decision to the party that can be held to it: code for facts, people for judgment, agents for work.

In a running control plane the three parties resolve into more specific actors — a human operator, a planning agent, an execution harness, a worker runtime, an independent verifier, a publisher, the deterministic control plane, and the advisory memory, observability, and learning systems — and the discipline that keeps the model honest is to write down, for each one, not only what it owns but what it cannot do on its own. That second column is where the leaks show up, and it applies to the human row too: an operator can accept, merge, and release, and cannot bypass server-side policy or invent missing evidence, which is why approval is a server-enforced authority boundary rather than a state a UI can set. Chapter 42 gives the eight-actor table as Mission Control keeps it.

The daily rhythm: business hours and overnight

The model has a clock. During business hours developers do the work that needs judgment: defining problems, outcomes, and acceptance criteria; reviewing and refining plans; weighing architectural and technical tradeoffs; reviewing code changes and test results; approving pull requests; resolving ambiguity, risk, and escalations; and improving the tools, workflows, and guardrails agents use. Agents do the execution: researching the codebase, drafting plans, writing and modifying code, creating and updating tests, running builds, tests, lint, security scans, and validations, investigating failures and correcting defects, preparing pull requests with evidence, responding to review feedback — and continuing through the day and overnight.

A developer may approve a plan before leaving. The next morning the review should answer, without reconstruction from logs or chat: what was completed, what code changed and why, what tests were added or modified, which validations passed or failed, what risks and assumptions surfaced, what decisions the agents made, whether the work meets the acceptance criteria, and whether the pull request is ready to merge. The developer experience should feel like leading a high-performing team: describe the outcome, review the plan, approve execution, let the team work, be interrupted only for judgment or authorization, return to an organized review package, approve with confidence.

Agent roles describe authority, not personality

A role is a bundle of permissions and prohibitions. Five logical roles cover the factory; a simple workflow may run several in one runtime, but the boundaries stay explicit.

The Researcher or Planner investigates the repository and context, identifies unknowns, proposes a versioned Plan, and states its assumptions. It cannot approve its own Plan.

The Orchestrator sequences eligible WorkOrders, checks dependencies, dispatches within policy, tracks progress, requests corrective work, and escalates. It cannot widen scope, alter policy, or mark assertions passed.

The Worker performs one authorized WorkOrder: implement, test, document, produce artifacts. It cannot self-certify acceptance or start unrelated repository mutation.

The Validator evaluates frozen criteria against exact artifacts through an independent execution path and reports pass, fail, stale, unknown, or waiver-required. It cannot edit the implementation it certifies or approve its own waiver.

The Recovery worker forms a new hypothesis from retained failure evidence and performs bounded corrective work. It does not erase the failed Attempt.

Human decision rights

Humans retain the decisions that define value or accept material consequences. An agent may prepare the packet and recommend; it is never the accountable owner.

Three levels of governance and the decision-rights matrix

The table above names owners inside a delivery organization. Around it sits an enterprise authority system with three levels. Executive governance sets strategy, values, risk appetite, prohibited uses, enterprise standards, material exceptions, investment, and final accountability. Enablement and control maintains the inventory, policy, architecture standards, assessments, training, lifecycle reviews, control tests, measurement, and reporting. Accountable system and business owners own use-case value, implementation, local controls, monitoring, incident response, evidence, and retirement. Independent assurance challenges claims and evidence, and data, architecture, security, privacy, legal, compliance, finance, people, and operations join whenever their domain is affected.

The matrix assigns decisions, not vague oversight. A is accountable, R performs the work, C must be consulted, I is informed. Local names may change; the technical separation may not.

Two rules hold the matrix together. The person who produces a consequential artifact cannot be its only assurance source. And approval authorizes a bounded action while acceptance confirms the outcome; the two decisions must not be collapsed. A RACI table is a design artifact — decision records and control tests are what prove the model actually operates.

The governed lifecycle

Every Mission passes through the same governed lifecycle. Each state has entry criteria, exit criteria, an owner, required evidence, allowed tools, approval conditions, and failure and escalation paths. This is where quality-engineering discipline becomes the advantage: most teams focus on agent capability, while reliable delivery actually comes from controlled transitions, evidence, validation, and accountability.

The twelve verbs of the operating cycle — define, research, plan, decide, authorize, execute, hand off, validate, recover, accept, release, learn — are these states seen from the participants' side: a human defines; an agent researches; the factory proposes a versioned execution-and-validation contract; a human decides on the exact Plan; the factory materializes bounded WorkOrders and runs policy and capability preflight; Workers execute Tasks through immutable Attempts; every role hands off; independent validators validate; failures produce new hypotheses and bounded corrective work; a human accepts on evidence, risk, deviations, and uncertainty; governed delivery proceeds through separate approval and production-verification states; and the factory proposes reusable improvements that humans promote.

Every agent action inside this lifecycle runs within a governed work order that defines the problem, expected business outcome, scope and constraints, acceptance criteria, required tests and quality gates, authorized tools and repositories, risk level, approval requirements, execution budget, escalation conditions, and definition of done. And the lifecycle distinguishes states that are often conflated: work attempted, completed, validated, approved, merged, deployed, and verified in production are different things and are never treated as interchangeable.

Handoffs replace conversational memory

Hospitals learned long ago that a shift change is where patients get hurt, and they replaced "let me tell you about bed 4" with a structured handover. The factory needs the same thing. A handoff is a durable contract, not a chat summary. It records the producing and consuming roles; the Mission, WorkOrder, and Attempt identities; completed, incomplete, and unknown criteria; commands, exit codes, artifacts, and changed files; known risks, blockers, assumptions, and uncertainty; the next action and accountable owner; and whether the outcome is complete, incomplete, or needs human input.

Unknown is a valid state. Inventing continuity is not. The next role does not begin while the predecessor's handoff is structurally incomplete.

Escalate judgment, not routine activity

The factory interrupts a human when it lacks authority, evidence, a safe recovery path, or an unambiguous decision. The triggers are: conflicting or missing requirements; policy denial or expired approval; material scope or architecture change; validator disagreement; failed, stale, or missing evidence; a security, privacy, legal, or compliance concern; an exhausted budget or corrective-iteration limit; unexpected repository state or dependency; an irreversible action; and uncertainty above the policy threshold.

An attention item states the decision required, why autonomy stopped, the affected scope, risk and urgency, available evidence, safe options, expected consequences, a recommendation, the uncertainty, and what resumes afterwards. That is the difference between a decision and a transcript.

The operator attention contract

The attention item is one side of a contract; the other side is a promise about when it may be sent. The operator attention contract binds both. The factory may interrupt a person only when one of three things is required: judgment (a decision the criteria do not settle), authority (a grant only a human holds: Plan approval, acceptance, merge, a risk exception), or credentials (a login, a token, an installation the runtime cannot obtain for itself). Anything else, including progress, routine completion, a retry that succeeded, and a check that a gate already proved, stays in the record and out of the inbox.

In return, every interruption arrives as a decision packet that answers six questions in a fixed order, so that a person can act on it without opening anything else:

The last field is the one most systems omit and the one that makes the packet usable. A person who does not know what happens after they click will either not click or click and then watch, and both waste the attention the contract exists to protect. Chapter 7 gives the packet's fuller form for governance decisions; the six fields here are the minimum any interruption must carry.

Human touches and overnight continuity

Two measures tell you whether the contract is holding. The first is the human touch: any manual override, approval, or takeover during agent execution. Some touches are the contract working (an authority grant at a gate). Many are the contract failing (a takeover because the agent stalled, an override because a check was wrong, an approval that a policy should have made). Counted per unit of work, human touches per agent task is the Factory Health measure that says how much of a person the factory still consumes for each thing it delivers, and its trend is the trend of leverage. A factory whose touches per task are rising while its throughput rises has not automated anything; it has moved work from typing to clicking.

The same count, taken per outcome rather than per task, is the operating metric for the whole model. A human touchpoint is any event at which a human must intervene for progress: a clarification, a replan, a correction, a pull-request comment, a manual test, a credential provisioned, an approval, a merge, a deployment, a recovery. Human touchpoints per accepted outcome is the number every subsection of this chapter is trying to lower without lowering quality: the attention contract removes touchpoints that carry no judgment, deterministic gates remove touchpoints that were really machine checks, work shaping removes the clarification touchpoints that come from unshaped intent, and the judgment boundary keeps the touchpoints that should remain. Watch it beside the manual takeover rate, and read the pair as Chapter 8 describes: autonomy is how much correction the agent needed, automation is how much of the workflow ran without a person, and a hundred correct pull requests each approved by hand is high autonomy with no automation.

The second measure is whether the work is still there in the morning. Overnight continuity is the property that governed work survives everything that ends a conversation: a model change, a context-window limit, a process restart, a handoff between workers, and the end of the chat session that started it. Continuity is not the same as persistence. The durable records of Chapter 5 make the state survive; continuity also requires that the work continues under bounded retries and escalates when the bound is hit, rather than looping silently or waiting for the person who went home. A Mission carries a stop condition for exactly this reason, and a control plane should refuse to compile a Plan from a Mission draft that has none.

The decision contract

Whatever the level — portfolio, system, release, incident, or autonomy — every consequential decision leaves the same record: subject, exact version, purpose, risk, and requested authority; the accountable owner and participating roles; policy baseline, evidence, counterevidence, uncertainty, and exceptions; alternatives, always including a lower-autonomy option; the decision, its conditions, expiry, review trigger, and reason; dissent or unresolved concern; downstream grants or restrictions; and correlation to later outcomes, incidents, and learning proposals. Hidden model reasoning is neither required nor a valid authority artifact; what is retained is observable inputs, decisions, actions, outputs, and evidence.

A reviewer may approve, reject, request revision, restrict, or escalate. A disagreement never defaults to broader authority: the existing ceiling stands until the designated tie-break owner decides. Security and privacy owners may contain within their delegated emergency scope, but material business acceptance stays with the business owner. Deadlines, escalation paths, and substitutes are preassigned for every critical decision, so authority never depends on locating a particular person.

Cadence follows risk and events

Reviews exist to produce decisions, control changes, or evidence. Meetings that produce none of those are ceremony and should be removed.

Avoiding more review work

The obvious objection to all of this is that it manufactures review. It does the opposite when built correctly. Approval volume should fall as evidence quality and bounded autonomy improve, because the factory stops asking humans to approve agent activity and starts asking them to decide about intent, exceptions, risk, and acceptance. Routine low-risk work proceeds within policy; surprises receive attention; high-risk work receives deeper review; and the reviewer sees an evidence-backed packet, not a pile of generated code.

Concretely: produce structured evidence rather than larger volumes of output, decompose work into smaller changes, validate automatically, summarize clearly, and route by risk. Review burden is itself a metric — if agent output increases human review time, the workflow is not yet delivering leverage. Each pull request should therefore arrive with a structured summary: original objective, approved plan, files and systems changed, key technical decisions, important code changes, acceptance-criteria results, test and validation evidence, known risks, unresolved questions, rollback strategy, agent confidence and uncertainty, and recommended reviewer focus areas.

Autonomy changes the frequency of decisions, not their ownership

At Level 1, humans initiate and review nearly every action. At Level 2, humans define WorkOrders and review all material outputs. At Level 3, agents plan and execute while humans handle material risk and final accountability. At Level 4, policy may permit deployment for bounded low-risk classes. At Level 5, humans govern the factory and its policies rather than routine work. Human accountability is present at every level; greater autonomy changes which decisions require individual intervention, not who owns the risk.

How the organization changes

The transformation is a set of shifts rather than a reorganization chart: from human execution to human supervision; from static roles to human–agent teams; from manual testing to continuous validation; from individual tools to orchestrated workflows; from activity measurement to outcome measurement; and from centralized decisions to policy-based autonomy. Engineers become more focused on intent, architecture, judgment, and review. Managers shift from coordinating task execution toward designing systems, managing risk, developing talent, and improving decision quality. Quality moves from a downstream testing function to a continuous validation capability embedded through the lifecycle.

Work shaping, product taste, and the judgment boundary

The shifts above describe the direction. Three ideas describe what the humans on the intent side actually do once the shift has happened.

Work shaping is the transformation of ambiguous demand into bounded, agent-legible work with explicit goals, constraints, scope, risk, and verification criteria. It is the craft that replaces implementation as the engineer's main output: humans move from writing implementation to shaping executable intent. A shaped piece of work says what outcome is wanted, what must not change, how far the agent may reach, what risk tier it sits in, and how anyone will know it is done; an unshaped one is a sentence in a ticket that an agent will complete confidently and wrongly. Chapter 6 treats shaping as the intent-layer discipline and gives it a specification to fill.

Product taste is the judgment about what should exist, which trade-offs matter, and what deserves priority. The factory can answer "can I build this?" at almost any scale; "should we, and what should it be?" stays with people. Taste is not a soft skill added to the operating model; it is the input the whole ring in Chapter 2 waits on, and a factory that automates everything downstream of a bad product decision produces bad product faster.

Both sit on the human judgment boundary, the set of decision points that stay human because they need taste, ambiguity resolution, accountability, prioritisation, novel synthesis, or risk acceptance. Chapter 7 defines the boundary and lists the seven kinds of decision on it; the point for the operating model is that the boundary is where human attention should be spent by design, and the decision-rights tables in this chapter are the boundary written down as owners.

Two roles the factory creates

The transformation also creates two roles that existing titles do not quite cover, and organisations that do not name them end up with the work done by nobody or by everybody.

The factory steward is accountable, for one domain, for shaping intent, owning outcomes, holding the product and architectural opinions, deciding exceptions, and improving the factory. It is the composite of product manager, tech lead, architect, and operator that agent-mediated delivery collapses into one accountable person, because the handoffs between those four are what the factory removed. A steward does not review every change; a steward owns the Definition of Correct for the domain and the outcomes that come back from it. In the decision-rights table above, the steward is usually the Product or Business Owner and the Engineering Lead in one chair for a bounded domain.

The software-factory process engineer improves the systems, constraints, feedback, and workflows through which agents produce software. When a recurring failure appears, the process engineer's job is to find the root cause and improve the harness, the context, the verifier, or the skill, rather than to fix this instance again. This is the discipline Chapter 2 calls factory engineering, staffed: the person who works on the meta loop rather than in the inner one. Quality engineers, platform engineers, and senior developers with a systems bent all grow into it, and the role is the destination of the last step of bottleneck migration (Chapter 1).

Role fungibility and latent quality capacity

Two second-order effects of the operating model matter for who gets to build. Role fungibility is the agent-mediated ability of people to execute useful work across functional boundaries by delegating specialised implementation to governed agents: a designer lands a production pull request, a go-to-market lead changes the website, an engineer writes a product specification. The builder doors above are the mechanism; the governance in this chapter is what makes it safe, because the deterministic systems supply the repository boundaries, deployment risk, and testing discipline the builder does not carry. Fungibility is not a reason to remove specialists; it is a reason to stop making specialists the queue for every small change.

Latent quality capacity is cheap capacity for work that never competed for engineering time: UI consistency, accessibility, copy, dependency hygiene, refactoring, coverage, documentation, technical debt. Every team has a backlog of it that has been rationally deprioritised for years, and a factory with slack capacity can run it as maintenance loops that need no prioritisation meeting. Factories raise quality, not only velocity, and this is where much of the quality gain comes from. Chapter 8 shows how to count it as return rather than treating it as free.

Builders beyond developers

Developers are the first persona, and the word builder is chosen deliberately to be wider than that. A builder is anyone who can express intent clearly enough for the factory to translate it into executable work: product managers, quality engineers, designers, security engineers, and other agents. They do not arrive through the same door.

A developer enters through the IDE or CLI, a product manager through a product requirements document, a quality engineer through acceptance scenarios, a designer through a prototype, and another agent through an API. Behind every door are the same capabilities: identity, context, tools, policy, environments, evaluation, signals, and delivery. What differs is what the builder brings and what they lack. A non-developer has product intent, often sharper than the engineer's, but does not carry repository boundaries, deployment risk, testing discipline, or architectural constraints in their head. The factory compensates rather than excludes: it clarifies intent, generates acceptance criteria for review, surfaces risk, applies repository and organisational context, and enforces guardrails automatically, so the product manager's request lands as a governed WorkOrder rather than as an unbounded prompt. The responsibility model above does not change for these builders; the deterministic systems simply do more of the translation.

The paved road must be the fastest road

Adoption cannot be mandated, and it does not follow from governance being correct. Builders take whichever path gets them to a working result soonest. If the governed path is slower than pasting code into a chat window, the chat window wins and the factory governs nothing. So the design constraint on every control in this chapter is that the safest paved road also needs to be the fastest paved road: guardrails built into the environment, identity and policy already attached to the ephemeral workspace a builder gets in minutes, verification that runs without being asked. The same constraint explains why prototype-to-production continuity matters. A prototype that already sits on the platform's identity, policy, secure tools, evaluation, and deployment interfaces becomes production-ready by raising the evidence and operational bar, not by being rebuilt; a product manager who can prototype in fifteen minutes while engineers need two weeks to reconstruct the result has moved the bottleneck, not removed it. Chapter 34 and Chapter 38 cover the platform side.

Junior engineers: tools that educate while they execute

The reflex with less experienced engineers is to restrict their tools. The better design is tools that teach. When the factory's review finds a problem in a junior engineer's change, the finding should explain which architectural boundary was crossed, why that risk matters, what evidence supports the finding, what to inspect next, and the organisational context a senior colleague would have supplied in a hallway conversation. The same decision packet that lets a principal engineer decide quickly is, for a junior engineer, a lesson attached to real work. That does not replace mentoring; it makes each mentoring conversation start further along. The measure is whether the platform increases engineering capability, not merely coding throughput: an organisation whose juniors ship more but understand less has borrowed against its own future.

Developer trust, adoption, and escape hatches

Trust in the factory is existential and asymmetric. One destructive change, or one reviewer agent that is noisy and wrong, undoes months of careful adoption, and the technical system may recover from a failure faster than developer trust does. Treat trust as a measured product outcome rather than a hoped-for side effect:

• Repeat usage. Builders come back without being told to.
• Accepted outcomes. The share of factory-produced work that is accepted rather than rewritten.
• Reduced rework. Less human editing per accepted change over time.
• Self-service onboarding. A new team reaches its first accepted outcome without a platform engineer in the room.
• Time saved. Measured against a baseline, not asserted.
• Continued use after support leaves. The forward-deployed engineer moves on and usage holds.

Trust also needs escape hatches, because a builder who cannot see why the factory did something will assume the worst. Recommendations explain themselves; policy decisions are visible, including the denials; there is a feedback channel that visibly changes behaviour; and errors are recoverable rather than terminal. None of these lowers a gate. They make the gate legible, which is what turns a control from an obstacle into a reason to keep using the system.

How to build it

1. Write the responsibility split down. Publish the humans-own / agents-perform / shared lists for your organization and treat them as policy.
2. Define the five agent roles as permission sets, with explicit prohibitions (no self-approval, no scope widening, no self-certification, no editing what you validate, no erasing failed Attempts). Check role compatibility before assignment: a Worker must not be the Validator for the same material artifact.
3. Populate both decision-rights tables with named people and named backups. Block activation or promotion of any scope without an owner.
4. Implement the twelve states as a state machine with the seven attributes per state (entry, exit, owner, evidence, tools, approvals, escalation). Make attempted, completed, validated, approved, merged, deployed, and verified distinct states.
5. Make the handoff a schema, validated on write: reject overlapping assertion outcomes, false completeness, missing commands, or incomplete work without a stated risk.
6. Make the attention item and decision packet the only way a human is interrupted. Lead with surprises; keep routine lineage one click away.
7. Record every consequential decision in the decision contract, including dissent and the lower-autonomy alternative.
8. Preassign tie-break owners, deadlines, and substitutes for every critical decision.
9. Configure the overnight shift: allowed Missions, risk boundaries, budgets, concurrency, notification rules, stop conditions. Design the morning briefing to separate completed outcomes, review-ready changes, recovered failures, exhausted budgets, and decisions needing judgment.
10. Instrument the model: decision latency, overdue reviews, exception age, self-approval attempts, control-test failures, time to contain, time to verified recovery, outcomes by approved autonomy tier, and human review time per accepted change.

For a small team, combine titles freely but preserve critical separation by technical means: independent CI evaluation, protected approvals, two-person control for irreversible actions, immutable evidence, and an outside reviewer for material exceptions. Document conflicts of interest. Limited headcount changes the mechanism, not the need for a credible challenge. Separation of duties should strengthen as scale and consequence grow.

Proportional control answers the cost objections. Strong role separation adds handoffs, so low-risk work may use lightweight automated handoffs that keep the same lineage and evidence semantics. Separate validators repeat work, and that cost buys independence; risk-based verifier selection, focused tests, artifact reuse with provenance, and sampling control the expense without letting the Worker certify itself. When human approval is the throughput constraint, removing approval is rarely the answer — better intent, smaller WorkOrders, stronger evidence, clear recommendations, and exception-only routing usually create more leverage with less risk.

Failure modes

Failed validation is not one of these. It is a normal feedback path, and a model in which validators never fail is more suspicious than one in which they sometimes do.

Central governance improves consistency but can become a bottleneck; federated ownership improves speed but fragments standards. The workable shape is centrally governed minimum controls with locally accountable implementation and risk-based escalation. This chapter prescribes neither job titles nor legal conclusions nor a universal committee structure.

In Mission Control

Pinned to commit 8014d5af, studied 2026-08-08. Mission Control's North Star assigns intent, judgment, governance, and approval to humans and bounded execution, iteration, validation, and evidence collection to agents. The governed Mission contract defines four runtime roles: Orchestrator, Worker, Validator, and Operator.

Implemented: Mission records retain state, owner, budget, stop condition, corrective limits, current Plan, active WorkOrder, blockers, and required human action. Plan submission freezes a proposed revision; approval materializes linked assertions and WorkOrders idempotently while leaving dispatch as a separate decision. Dispatch checks approved Plan authority, released WorkOrder state, predecessor handoff, budget, corrective limits, and serial mutation — exactly one repository-mutating WorkOrder may be active per Mission, with read-only work concurrent when the Plan permits. Worker and Validator handoffs record role, WorkOrder, WorkflowRun, assertion outcomes, commands, artifacts, risks, next action, and next owner, and the handoff validator rejects overlapping outcomes, false completeness, missing commands, or incomplete work without a stated risk. Acceptance fails on missing, failed, stale, unvalidated, receipt-less, or improperly waived assertions, or on incomplete WorkOrders or handoffs; failed validation blocks the Mission and directs the operator toward bounded corrective work.

No fresh browser journey was performed. The operating model becomes proven only when repeated browser and runtime evidence shows work surviving process restart, handoff, validation failure, corrective execution, and delayed human review without bypassing authority.

Retain this

• Three parties: humans own intent, judgment, material risk, and accountability; agents propose and execute bounded work; deterministic systems validate and govern. Facts go to code, judgment to people, work to agents. Human-led is not human-performed; agent-executed is not agent-authorized, and autonomy changes how often a human decides, never who owns the outcome.
• Five agent roles — Planner, Orchestrator, Worker, Validator, Recovery worker — are permission sets, and no role certifies its own work. Twelve lifecycle states each carry entry, exit, owner, evidence, tools, approvals, and escalation; attempted, completed, validated, approved, merged, deployed, and verified are different states.
• A handoff is a durable contract, not a chat summary; unknown is a valid value, invented continuity is not. Interrupt humans only for judgment, authority, or credentials, with a decision packet, never for routine activity with a transcript — approval authorizes, acceptance confirms, and disagreement never widens authority.
• A human touch is any override, approval, or takeover during agent execution; human touches — and human touchpoints per accepted outcome — are the leverage measures this whole model is built to lower without lowering quality. Review burden is itself a metric: if agents add review time, there is no leverage yet.
• Overnight continuity means work survives model changes, context limits, restarts, handoffs, and the end of the chat session, under bounded retries and escalation, never silent looping; a Mission needs a stop condition before its Plan is compiled.
• Humans move from writing implementation to shaping executable intent: work shaping turns ambiguous demand into bounded, agent-legible work, and product taste decides what should exist — both sit on the human judgment boundary, where attention is spent by design. Name the factory steward (intent, outcomes, exceptions, and improvement for one domain) and the process engineer (root-causes recurring failures into the harness).
• A builder is anyone who can express intent clearly enough to be translated into governed work; the factory compensates for what non-developers lack rather than excluding them. The safest paved road must also be the fastest, trust is a measured product outcome protected with escape hatches, and tools should educate while they execute.

Go deeper

• Previous: Chapter 3, First principles. Next: Chapter 5, Authoritative records defines the Mission, Plan, WorkOrder, Attempt, and Evidence records this model runs on.
• Chapter 7, Governance, policy, and risk-proportional approval; Chapter 8, Economics, metrics, and human attention; Chapter 14, Durable execution; Chapter 36, Resilience, incidents, and the control tower; Chapter 38, Enterprise adoption.
• Glossary: handoff, attention item, decision packet, Orchestrator, Worker, Validator, governed work order.
• Sources: Jay West, Mission Control North Star (business-hours/overnight model, review package, governed work order); Jay West, AI Software Factory Mission (humans own / agents perform / shared, governed lifecycle, transformation shifts); Jay West, factory architecture notes (three-party responsibility model, builders beyond developers, paved road, junior engineers, developer trust and adoption metrics, escape hatches); Mission Control repository glossary and lexicon, reviewed 2026-09-02 (operator attention contract, human touch, human touches per agent task, overnight continuity, stop condition before Plan compilation); Jay West, AI Software Factory Study Guide chapters 3 and 16; public practitioner talks, 2026 (work shaping, product taste, factory steward, process engineer, role fungibility, latent quality capacity, human touchpoints per accepted outcome); NIST AI Risk Management Framework 1.0 and Generative AI Profile; Mission Control at the studied commit: North Star, V1 product strategy, Governed Missions contract, convex/missions.ts, missionGovernance.ts, missionExecution.ts, MissionDetailView, MissionPlanWorkspace.