Menu
The shape of PilotSwarm — the pieces, how a turn flows through them, and the rules that constrain each layer.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
The order of operations for changing a live agent safely — diagnose, patch, publish, converge, verify, roll back. Use whenever you are about to modify an agent package that something is already running on.
Deploy PilotSwarm to AKS using the repo's canonical scripts and checks. Use when refreshing secrets, building/pushing the worker image, rolling out to AKS, or verifying provider/model changes in the live cluster.
Reset remote PilotSwarm state for AKS safely. Use when wiping the PilotSwarm database/blob state, clearing stale orchestration history, or recovering from namespace drift and replay/nondeterminism issues.
Use when bringing up a fresh, isolated PilotSwarm environment (`mysandbox`, `myenv2`, etc.) via the npm Bicep/GitOps orchestrator at `deploy/scripts/deploy.mjs`. Covers `new-env` scaffolding, EDGE_MODE × TLS_SOURCE selection, the `all` aggregate, per-service redeploys with `--steps`, force-redeploy semantics, verification, and teardown. Strictly separate from the legacy bash path operated by `scripts/deploy-aks.sh`.
Use after deploying a PilotSwarm stamp with VPN_GATEWAY_ENABLED=true when an operator needs the Azure VPN client profile (azurevpnconfig.xml). Wraps deploy/scripts/auth/Get-VpnClientProfile.ps1 — downloads the gateway-issued profile zip via 'az network vnet-gateway vpn-client generate' and extracts it under the gitignored deploy/envs/local/<env>/vpn-client/ folder. The XML is the same for every user (no per-user credentials), and end users still authenticate with their own Entra ID at connect time.
How to compute model latency and estimated $ cost from PilotSwarm observability data. Read this before reporting that a model is "slow" or "expensive" — most apparent slowness is orchestration overhead, not model inference, and most cost numbers are guesses unless they reference a real published price card.
| name | pilotswarm-architecture |
| description | The shape of PilotSwarm — the pieces, how a turn flows through them, and the rules that constrain each layer. |
A durable execution runtime for GitHub Copilot SDK agents, powered by duroxide (a Rust durable-orchestration engine). What durability buys: crash recovery, durable timers, session dehydration, multi-node scale-out.
Both connect to the same PostgreSQL. Duroxide coordinates between them, which is why the client can hold no handler functions: everything crossing that boundary must survive a database round-trip.
Client → duroxide orchestration → SessionProxy activity
→ SessionManager → ManagedSession → CopilotSession (Copilot SDK)
The orchestration is a generator replayed from the beginning on every new
event, so it must yield the identical sequence each time. Date.now(),
Math.random(), crypto.randomUUID(), setTimeout, and any I/O are
therefore banned inside it — the deterministic substitutes are
ctx.utcNow(), ctx.newGuid(), ctx.scheduleTimer(), and activities.
Changing the yield sequence creates a new orchestration version, which is why
versions are frozen rather than edited.
Session state lives in the CMS (copilot_sessions schema); facts live in
their own schema. All data access goes through stored procedures with
versioned migrations applied under advisory locks, so concurrent workers can
start safely against the same database.
A session can spawn sub-agents, each its own session with its own conversation and tools, running concurrently under a parent. Capability arrives as agent packages: a manifest plus agents, skills, worker tools, and MCP servers.