pilotswarm-architecture
The shape of PilotSwarm — the pieces, how a turn flows through them, and the rules that constrain each layer.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
The shape of PilotSwarm — the pieces, how a turn flows through them, and the rules that constrain each layer.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.