| name | swarm-invocation-designer |
| description | Design multi-agent invocation, swarm coordination, and lightning-fast inter-agent communication for developer tools and Port Daddy. Use when deciding how users summon multiple agents, how agents talk, how work is sharded, how claims and worktrees prevent collisions, or whether ICP/IPC/message-bus communication should be hot path or durable path. NOT for generic chat, single-agent prompting, CRDT editor internals without agent orchestration, or operating live concurrent agents in a shared repo (use multi-agent-coordination for that). |
| license | Apache-2.0 |
| allowed-tools | Read,Write,Edit,Bash,Grep,Glob |
| metadata | {"category":"Agent & Orchestration","tags":["swarm","multi-agent","invocation","ipc","coordination"],"provenance":{"kind":"first-party","owners":["port-daddy"]},"pairs-with":[{"skill":"fipa-00025-interaction-protocol-library","reason":"Supplies role, conversation, and protocol design vocabulary."},{"skill":"real-time-collaboration-engine","reason":"Supplies latency, batching, presence, and conflict-resolution patterns."},{"skill":"port-daddy-agent-skill","reason":"Supplies Port Daddy claims, notes, locks, tubes, salvage, and handoff mechanics."},{"skill":"multi-agent-coordination","reason":"Covers operating live concurrent agents; this skill designs the invocation and protocol layer they run on."}],"io-contract":{"kind":"deliverable","consumes":["[Truncated]","[Truncated]"],"produces":["[Truncated]","[Truncated]","[Truncated]"]}} |
Swarm Invocation Designer
Design the control surface and protocol layer for summoning, steering, and observing multiple agents.
Use This For
- Turning "ask several agents" into a typed invocation with roles, budgets, files, worktrees, stop conditions, and receipts.
- Designing hot-path agent communication: local IPC, Unix sockets, WebSocket, gRPC, NATS, Redis Streams, shared memory, or in-process queues.
- Designing durable coordination: append logs, Port Daddy notes, tuple space, tubes, actor inboxes, transcripts, and PR receipts.
- Disambiguating ICP (Internet Computer) from IPC and deciding which coordination layer can feel instantaneous.
Do Not Use This For
- Making agents chat constantly when a note or tuple is enough.
- Treating blockchain/canister consensus as a low-latency local control bus.
- Spawning agents without ownership, budget, or recovery semantics.
Core Model
sequenceDiagram
participant U as Operator
participant C as Control Plane
participant H as Hot Bus
participant D as Durable Log
participant A as Agent Roles
U->>C: goal + constraints
C->>D: invocation receipt
C->>A: role assignments + claims
A->>H: small status/control messages
A->>D: transcript, commands, artifacts
C->>U: live board + final receipt
Use two channels:
- Hot path: tiny, typed, ephemeral messages for steering, presence, cancellation, and heartbeat. Optimize for p95 latency and low serialization overhead.
- Durable path: append-only transcript, claims, commands, decisions, artifacts, and review receipts. Optimize for auditability and replay.
ICP vs IPC: Which Layer Is Fast
If the user means IPC (inter-process communication), yes: agents can speak very quickly through Unix domain sockets, loopback WebSockets, gRPC, shared-memory rings, NATS, Redis Streams, or an in-process event bus. For LLM agents, model latency usually dwarfs transport latency; optimize message size, batching, and tool-call scheduling before obsessing over microseconds.
If the user means ICP as Internet Computer Protocol canisters, do not put the hot path through consensus. Use canisters for durable coordination, identity, receipts, escrow, or cross-organization governance; keep live steering on a local or regional bus and periodically commit signed receipts.
Invocation Design Steps
- Name the operator intent and the stop condition.
- Split roles, not identities: planner, implementer, reviewer, tester, researcher, or integrator.
- Assign isolation: one worktree per writer, claims per file or symbol, locks only for scarce resources.
