An operator’s guide to Agent-Orch and Auto-Orch, post-commissioning.
Six weeks ago, a user guide to this platform would have read “here are the commands.” Today it reads “here is the operating model.” That shift — from command reference to operating model — is the real signal that this platform is becoming a product rather than just a codebase.
So much has changed in Agent-Orch and Auto-Orch that the mental model from a month ago is now obsolete. What follows is the operator’s manual for what replaced it.
Executive summary
The platform has evolved from an AI orchestration system into a governed AI execution engine.
The most important mental shift is this:
Auto-Orch decides what should happen. Agent-Orch governs how it happens.
Auto-Orch is your Chief of Staff. Agent-Orch is your Constitution.
The architecture
Auto-Orch
Purpose: operate AI employees.
Responsibilities:
- Maintain the mission backlog
- Select work
- Create playbooks
- Schedule missions
- Manage pause/rearm state
- Manage mission lifecycle
- Route work to Agent-Orch
- Learn from completed work
Think of Auto-Orch as operations management.
Agent-Orch
Purpose: execute governed work.
Responsibilities:
- Execute playbooks
- Route workers
- Enforce governance
- Preserve evidence
- Verify execution
- Protect repository identity
- Produce commissioning evidence
- Require human approval when appropriate
Think of Agent-Orch as constitutional government.
Current design philosophy
Everything important has exactly one authority. If two places decide the same fact, one of them will eventually be wrong.
| Authority | Owner |
|---|---|
| Routing | Agent-Orch |
| Validator results | Agent-Orch |
| Repository identity | Agent-Orch |
| Launch inputs | Agent-Orch |
| Pause state | Auto-Orch |
| Run lineage | Auto-Orch |
| Commissioning readiness | Agent-Orch |
| Platform attestations | Agent-Orch |
Never create a second authority for a fact that already has one.
Mission lifecycle
A mission normally flows through:
- Backlog
- Selection
- Playbook authoring
- Preflight
- Governed execution
- Independent evaluation
- Human approval (if required)
- Completion
- Learning
- Next cycle
Commissioning
Commissioning exists to answer one question: can this mission safely enter autonomous operation?
Commissioning is not ordinary mission work — it’s a higher bar. It proves:
- Routing
- Validators
- Repository identity
- Launch inputs
- The evidence chain
- Semantic review
- Independent evaluation
- Human approval
Only after commissioning should a mission be re-armed.
Controlled pilot
Linux Utilities is now operating under a controlled pilot. Characteristics:
- Audited pause removed
- Supervised commissioning complete
- Autonomous schedule limited
- Overnight execution
- Overlap protection
- Employee Zero observation
A controlled pilot is deliberately different from unrestricted autonomous production — it’s the step in between.
Human approval
Green steps do not mean approval.
Approval is based on:
- Evaluator recommendation
- Platform attestations
- Validator authority
- Repository identity
- The evidence chain
- Unresolved findings
Never approve from a worker’s summary. Always approve from the authoritative approval packet.
Validator authority
Workers do not decide whether validation passed — system validators do. Worker reports are supporting evidence; validator authority is authoritative.
Platform attestations
The platform creates immutable attestations for:
- Producer execution
- Evaluator execution
- Semantic judge execution
- Validator authority
- Repository identity
- Approval-boundary chain
- Terminal chain
These belong to the platform. Workers never attest their own execution.
Evidence chain
Evidence is append-only and never rewritten. Superseded runs remain preserved, and evidence is independently verifiable.
Never edit historical evidence.
Repository identity
Every governed worker attempt verifies:
- Repository
- Branch
- Worktree
- Git metadata
- Nested repositories
- Scratch redirection
Repository identity is immutable evidence.
Routing
Routing is deterministic — configuration alone determines it, and the runtime must match configuration. If they disagree, routing authority fails.
Current Linux Utilities crew:
| Role | Agent |
|---|---|
| Producer | Codex GPT-5.6 Luna |
| Reviewer / user tester | Claude Sonnet 5 |
| Judge | Claude Code |
Run lineage
Every governed run belongs to exactly one lineage. Runs may be completed, failed, waiting on approval, or superseded. Superseded runs are never deleted — lineage remains part of permanent evidence.
Pause
Pause is now first-class, and distinct from value-exhausted, idle, or failure states. Pause allows no autonomous execution, only supervised commissioning.
Validation-only
Validation-only may validate deterministic artifacts. It may not replace independent evaluation, user testing, semantic review, or human judgement — those require fresh governed execution.
Linux Utilities
Linux Utilities is now the reference commissioned mission. It serves as the reference playbook, the reference commissioning contract, the reference evidence model, and the reference governance implementation.
Future missions should inherit its commissioning model rather than rediscover it.
Employee Zero
Employee Zero is operations. Responsibilities:
- Freshness
- Deployments
- KB generation
- Monitoring
- Health
- Confidence holds
- Operational reporting
Employee Zero should observe more than it changes.
Normal daily workflow
Morning
- Employee Zero report
- Mission status
- Failures
- Repairs
- Health
- New evidence
During the day
- Product development
- AI process reengineering
- New AI employees
Evening
- Review autonomous work
- Approve only when governance requires it
- Re-arm only after evidence
Current mental model
Do NOT think: Agent-Orch launches AI. Think: Agent-Orch governs execution.
Do NOT think: Auto-Orch launches workers. Think: Auto-Orch operates AI employees.
Do NOT think: Workers prove success. Think: Evidence proves success.
Operating principles
- One authority for every important fact.
- Evidence before assertions.
- Runtime truth beats configuration.
- Never ask a component to certify its own execution.
- Human approval is evidence-based.
- Preserve history.
- Fail closed.
- Commission before production.
- Platform governs. Workers execute.
- Product work is now more important than platform work.
Current mission status
Linux Utilities
- Status: controlled autonomous pilot
- Platform: commissioned
- Governance: complete
- Next priority: build the next AI employee instead of expanding the governance layer, unless production evidence demands it.