AI workloads · Autopilot
Any AI agent workload, bounded and audited
I think AI agents are going to become real teammates for platform teams, and they deserve the same paved road as people: the same contracts, the same checks, the same audit trail, just with less authority by default. Autopilot is Hangar's sixth product. It runs any agent workload on the platform that already runs the container apps, and it all comes back to one idea.
Durable changes are git commits. Ephemeral runs are direct requests to Crossplane.
Committing every agent session to git would be slow, noisy and impossible to review. So a run may skip git only if all five of these hold; if any fails, it goes through a pull request like everything else.
- It has a hard deadline that needs nothing else to enforce it.
- It holds no durable state, and reaches the durable plane only as a pull request.
- One narrowly scoped identity creates it, in one reserved namespace.
- It can only narrow what git grants, never widen it.
- It can be rebuilt from git plus the task spec.
Where it stands
- Built Clearance core: tool tiers, path scope, narrow-only limits, sessions and run trees, CEL policy, hash-chained audit, gateway (261 tests, no cluster needed)
- Built The AppSpec planner: one sentence to a reviewed change set, checked against the real schemas
- Built Nine Skyport agent definitions and six Preflight cases
- Draft The AgentRun XRD, its composition and function
- Proposal Real adapters, authentication, the model proxy forwarder and the CI gates
Chapter 01
Where it fits
Hangar already had a rule: no component holds a live write credential, and every change is a git commit. Autopilot keeps that rule for anything durable and adds exactly one new kind of thing beside the existing platform.
Chapter 02
What an agent workload is
Any agent workload is one of six shapes (task, session, service, scheduled, event, team), built from a durable, reviewed definition and a disposable run. A run gets a sandbox, a budget and a deadline, and it always ends, whether or not anyone is watching. A team is a tree in which every child is narrower than its parent.
Chapter 03
Where it runs
Backends are managed the Hangar way: three fleet classes behind one contract, and two gates out of every sandbox, one for tools and one for models. Dev clusters get the write path and the runs; upper clusters get neither.
Chapter 04
Identity and authority
An agent proves who it is on every call and gets a scoped token that is never kept. What it may do depends on its tool tier, and its effective authority is the minimum of five inputs, which runtime can only lower. Its pull requests meet every gate a human's do, plus two about agents.
Chapter 05
Knowing what it did
The flight recorder reuses the telemetry Hangar already has and adds one tamper-evident hash chain. Preflight scores every agent change against incidents that have already been solved. The existing AI triage moves behind Clearance, so it gets the same bounds as everything else.
Chapter 06
Getting there
Four rollout phases, each closed by a live check before the next begins, inside a plan of six milestones measured by one number: how operable Airframe is by agents.
Chapter 07
The demo: Skyport
Skyport, Hangar's reference airline system, gains six AI workloads, one per shape. The event-shaped one turns a delayed flight into one draft, a team, and a human decision.
Further reading
The reference set of ten diagrams (agent substrate, tool gateway, autonomy ladder, eval harness and more) is in the diagram gallery. The full design, with every claim labelled Built, Draft or Proposal, is in docs/autopilot/design.md. How far Airframe has come toward what agents need is on the scorecard, measured after every milestone.