The Human-Agent Operating Model
Define how people and agents divide decisions, execution, oversight, and accountability.
A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Jump to validation criteriaOpen the source exercise
Draw the Product Owner, Mission Approver, Orchestrator, Worker, Validator, Engineering Lead, Risk Owner, and Release Approver. Connect them through the Mission lifecycle from intent to production verification.
For each boundary, state:
- the artifact transferred;
- the authority granted;
- the evidence required;
- the decision owner;
- the escalation condition; and
- what resumes after the decision.
Then redraw the model for a five-person startup and a regulated enterprise. Preserve the same accountability while changing how many people hold the roles.
4. Tradeoffs and alternatives
Strong role separation increases handoffs and can slow small changes. The answer is proportional control. Low-risk work may use lightweight automated handoffs while retaining the same lineage and evidence semantics.
Separate validators can repeat expensive work. That cost buys independence. Risk-based verifier selection, focused tests, artifact reuse with provenance, and sampling can control expense without letting the worker certify itself.
Human approval can become the throughput constraint. Removing approval is not the only remedy. Better intent, smaller WorkOrders, stronger evidence, clear recommendations, and exception-only routing often create more leverage with less risk.
Small organizations may combine human titles. One founder may be Product Owner, Engineering Lead, Mission Approver, and Release Approver. Technical separation between implementation and validation must remain. Separation of duties should increase with organizational scale and consequence.
5. Current Mission Control Implementation
This assessment uses Mission Control commit
8014d5af427b43ff5c5a63cfdf82ec92742c208c,
studied on 2026-08-08.
Mission Control's North Star explicitly assigns intent, judgment, governance, and approval to humans. Agents own bounded execution, iteration, validation, and evidence collection. The governed Mission contract defines four runtime roles: Orchestrator, Worker, Validator, and Operator.
Implemented mechanisms
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.
Mission dispatch checks approved Plan authority, released WorkOrder state, predecessor handoff, budget, corrective limits, and serial mutation. Exactly one repository-mutating WorkOrder may be active in a Mission. Read-only work may run concurrently when the approved Plan permits it.
Worker and Validator handoffs record role, WorkOrder, WorkflowRun, assertion outcomes, commands, artifacts, risks, next action, and next owner. The handoff validator rejects overlapping assertion outcomes, false completeness, missing commands, or incomplete work without a stated risk.
Mission acceptance fails when assertions are missing, failed, stale, unvalidated, lack receipts, or use an unauthorized waiver. It also fails when WorkOrders or handoffs remain incomplete. Failed validation blocks the Mission and directs the operator toward bounded corrective work.
Capability assessment
| Operating capability | Status at studied commit | Interpretation |
|---|---|---|
| Human-defined Mission | Implemented | UI and Convex records capture governed intent and lifecycle. |
| Versioned Plan approval | Implemented | Submission freezes the proposal; approval releases exact WorkOrders and assertions. |
| Orchestrator, Worker, Validator, Operator roles | Implemented in the Mission contract | Role-specific permissions and state checks exist. |
| Structured handoffs | Implemented | Handoffs preserve assertion outcomes, commands, artifacts, risks, and next action. |
| Independent validation requirement | Implemented mechanism | Validator-run and receipt linkage are enforced for required assertions. |
| Corrective iteration | Implemented mechanism | Failed validation can block the Mission and bounded corrective work may be requested. |
| Exception-first operator experience | Product doctrine with partial UI proof | Required-human-action fields and decision surfaces exist; approval-fatigue reduction has not been measured. |
| Complete governance-role matrix | Partial | Runtime roles are clear, but all business, security, compliance, architecture, and release owners are not one enforced matrix. |
| Risk-proportional approval automation | Partial | Risk and approval controls exist; comprehensive cross-lifecycle policy proof remains incomplete. |
| Overnight autonomous operating shift | Product target, not proven here | Durable state exists, but this chapter did not demonstrate an unattended end-to-end shift. |
No fresh browser journey was performed for this chapter. The assessment is grounded in product contracts, source, and existing tests at the pinned commit. It does not promote the complete operating model into a proven V1 claim.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence