Skip to content

How it fits

One ticket, four planes, one gate. The team harness defines what the agents run, hangar runs them, flightdeck judges the runs and Tower governs the risky decisions. Every change leaves through a reviewed pull request.

DoorsMany doorsJira, GitHub, Slack, MCP,schedulesTeam harness repoDefineNative files, harness.lock,one digesthangarRunSandboxes, sessions, jobsand trials on GKEVerify, push through thegateway, land on approvalTowerGovernRules, human approvals,signed receiptsGitHubOne gate: the PRA second human approvesthe exact commitflightdeckJudgePaired statistics andbehavior specs on every runworklockdecidePRevery runtrialspromote the next harness
Four planes, one loop, one gate · the seven steps, numbered, full size
A ticket's journeySolid: on main · dashed: hangar wiring openDoorsReady for agentA ticket moves; a signed webhookreaches hangar1hangar · intakeAdmitTainted: ticket text is untrustedWithin budget and reviewer capacity2hangar · sandboxClaim team-default@stableThe manifest records harness_digestEvery step streams into a trace3Tower · GovernAsk before a risky stepAllow, deny or wait, with a receiptA wait goes to someone else4hangar · gatewayVerify and open the PRRepo checks, one commit, a draft PRA second human approves the commit5Outbox · compactorCaptured onceThe run lands in the GCS outboxand in Parquet overnight6flightdeck · harness repoJudge, then promoteStable vs candidate on pinned trialsA different person moves stable7the next claim uses the new stableTower's side is built; hangar's wiring ishangar#172 and #173.
The seven steps, numbered as below

A ticket's journey

  1. An engineer moves ABC-123 to Ready for agent in Jira, the default door.
  2. hangar receives the signed webhook, marks the job tainted (ticket text is untrusted) and admits it within budget.
  3. hangar claims a sandbox pinned to team-default@stable and records a manifest carrying its harness_digest.
  4. For anything risky the agent asks Tower: allow, deny or wait. A wait goes to a second person.
  5. hangar runs the repo's checks, pushes one commit and opens a draft PR. A second human approves that commit.
  6. The finished run lands once in the outbox, and flightdeck compacts it to Parquet overnight.
  7. A harness change runs stable against candidate on pinned trials; flightdeck's verdict decides what stable becomes.

Each step's progress lives on the roadmap; the flows that start elsewhere (a harness change, a risky action, the nightly pipeline, onboarding a repo) are on Flows.

Three rules

Many doors, one inbox, one gate. Work starts wherever people already are: a Jira status, a GitHub label, Slack, an MCP client. Questions and approvals come back to one inbox, and nothing reaches a branch except through a pull request a human approves.

Each tool owns one plane. hangar never analyses runs, flightdeck never runs sandboxes, Tower decides but never enforces, and ai-dlc stays off the agent's hot path. They meet only at versioned contracts.

Fail closed, measure everything. Untrusted input taints a run and raises the bar to land it. Every run is written once to an outbox, so a harness change is judged on paired evidence rather than impressions.

Who owns what

  • Team harness (Define): the harness as native files and harness.lock; its channels name which digest is stable.
  • hangar (Run): doors, admission, sandboxes, the manifest and trace, the outbox, trials, and the PR gate.
  • flightdeck (Judge): the Parquet data plane, paired statistics, behavior specs, pin sets and the report on the PR.
  • Tower (Govern): the decision point, passports, approvals and hash-chained receipts.
  • ai-dlc (Setup): engineers' machines and the optional workflow plugin a harness may pin.
  • Spaceport (Capability, frozen): governed data over four MCP tools.
  • agent-factory: Airframe, these docs, the deck and the roadmap.

The seams between them are versioned files and APIs. Contracts lists each one, who produces and consumes it, where it is defined and its status.

Where to go next

  • Team harness: the Define plane, with the example you can copy.
  • Architecture: the C4 views and where each container runs.
  • Flows: improving the harness, a risky action, the nightly pipeline and onboarding a repo.
  • Glossary: every term on this page.