Docs · Hangar

Skyport AI workloads: one agent per workload shape

Skyport already exercises every Airframe stack and component with five services and a broker (airframe/docs/user/skyport-demo.md). This extends it with six AI workloads, one per shape, so every part of Autopilot has a real caller, a visible effect, and a test that can fail.

The definitions are real and tested: autopilot/agents/skyport/*.yaml (nine files: six workloads and three team members), with one Preflight case each in autopilot/preflight/cases/skyport-*.yaml.

Status: definitions and cases Built. Everything that would run them is Proposal until Autopilot phase A and B exist (see roadmap.md).

The six workloads

Diagram: diagrams/plan/07-skyport-ai-workloads.html. The event and team flow: diagrams/plan/08-skyport-event-to-team.html.

Why these six

They are business-domain agents, so the demo shows agents operating a system, not only agents operating the platform. The platform-facing agents already exist or are planned: HolmesGPT is the event and service shape for triage (diagrams/autopilot/17-triage-before-after.html), and the coding agent is the delegated task shape for platform work (the parachute test).

A deliberate rule: nothing here applies a change

No Skyport agent has a write tool. They read, they draft, they store artifacts, they ask a human, and they spawn narrower runs. Anything consequential goes through human.request. A test asserts it: test_nothing_in_the_demo_can_apply_a_change_except_by_spawning_narrower_runs. The demo shows what “humans on the loop” looks like without the demo being able to break Skyport.

What each needs that does not exist yet

The trigger bridge (event shape)

An ordinary Airframe PythonApplication with a RabbitMQ attach consumer, so the demo also exercises the component it depends on. It:

1. binds a queue ai.disruption to flights.events with flight.*.delayed (the definition’s bindingKey);
2. for each message, derives task_id = event_task_id(agent, message_id) so redelivery maps to the same run (RabbitMQ is at-least-once);
3. applies the definition’s maxPerHour as a storm brake (a delayed-flights storm must not start a thousand runs);
4. calls Clearance open_triggered as its own workload identity, then launch;
5. acks only after the audit record exists; malformed messages are rejected and audited, not dropped.

It holds no model key and no repo credential. Its authority is “may start this one definition”. Tested pieces: amqp_topic_match, match_event, event_task_id, RateLimiter, idempotent open_triggered. The consumer itself is the build work.

The session channel (session shape)

Runs have no inbound network by policy, so Tower cannot connect to a gate-copilot pod. Instead Clearance holds a per-session message queue: Tower posts the human’s message to Clearance, the agent calls chat.recv (long-poll) and chat.send. The sandbox only ever dials out. Those two tools exist only for kind: session (rule R018).

The service agent (service shape)

passenger-assistant is an application: PythonApplication plus a Redis component, deployed and released like baggage-api, with the chart’s agent: block giving its pods the same tokens, egress policy and labels a run gets. It is the only workload facing the public, so its definition asks for the hardened sandbox.

That fails closed on the dev cluster, by design. It has no gVisor or Kata runtime class, so the chart (and function-agentrun) reject it rather than run it weaker. To run the demo on the dev cluster, change the definition to standard in a reviewed commit and record why. A run can narrow a definition but never widen it, so lowering isolation is only ever a commit. That moment is worth a paragraph in the quickstart.

Safety demonstrations built into the demo

Quickstart parts (numbered in the order built)

The existing part 3 (broker) is done. Parts 4 and 5 are the existing Skyport phases 3 and 4; the AI parts slot in after them because the agents read baggage-api. Each part follows the house rule: walk it live before it is called done, and the quickstart’s verified-state note says exactly what was walked.

Where the code lives (proposed)

airframe/examples/skyport/
  flight-api/  boarding-api/  baggage-api/        # existing and next
  agents/
    flight-briefer/  gate-copilot/  passenger-assistant/  delay-digest/
    disruption-responder/  irregular-ops-team/  ops-researcher/  ops-drafter/  ops-checker/
    trigger-bridge/                               # an ordinary Airframe app
    fixtures/                                     # API fixtures, event streams, the injection text
autopilot/ (new repo; today ~/tech/autopilot)
  agents/skyport/*.yaml   preflight/cases/skyport-*.yaml

Definitions stay next to Clearance because they are policy, reviewed as policy. The agent code lives with the demo because it is an example, versioned with the Airframe it exercises.

Cost control

A hosted model is the default. Every run has a token budget (modelTokens), the model proxy enforces it and trips the breaker on overrun, and delay-digest and flight-briefer are the only scheduled or on-demand spenders. A Modelplane hub is a later trial (M5), not a demo dependency.

Acceptance for the whole extension

1. Each agent runs end to end on the dev cluster and its Preflight case passes.
2. Each case’s seeded bad run fails (the harness can say no).
3. kubectl shows no run namespace older than its expiresAt, with Clearance stopped.
4. One task_id traces a disruption from broker message to the team’s final artifact in the Flight recorder.
5. The scorecard has not regressed.