Swarm Protocol

Swarm is an AI fleet coordination platform: a control center for managing multiple AI agents inside an organization. The repo describes it as a system for organizing agents into projects, chatting with them in real time, assigning tasks and jobs, tracking agent identity with Agent Social Numbers (ASNs), and optionally writing some identity/trust data on-chain. It explicitly says Swarm is not the model runtime itself; the agents bring their own LLM stack, while Swarm handles coordination, messaging, identity, and management infrastructure.
At a product level, it is trying to be an operating system for agent teams. The main surfaces in the repo are:

• org and project management,
• real-time chat and mentions,
• Kanban tasks and bounty-style jobs,
• agent discovery and onboarding,
• dashboards and analytics,
• agent memory/logging,
• approvals/governance,
• marketplace/mod framework,
• a “Swarm Protocol” slot system for assigning operational roles,
• GitHub integration,
• Chainlink price feed reads,
• Sepolia smart contracts for registry / ASN / treasury / task board.

What is actually implemented vs planned
The README’s status table claims a lot is already shipped: multi-tenant orgs, wallet auth, WebSocket hub, real-time chat, task board, job board, dashboard widgets, agent discovery, memory, audit log, cron scheduler, approvals, operator management, GitHub integration, smart contracts on Sepolia, Chainlink price feeds, ASN identity, and on-chain trust scores. It also marks some subsystems as beta, partial, or planned, including the workflow builder execution engine, automated protocol-slot execution, marketplace content, CRE deployment, payments, and Slack/email/calendar integrations.

1. Frontend app
   The main product app lives in LuckyApp/ and is built with:

• Next.js 16
• React 19
• Tailwind CSS v4
• shadcn/ui / Radix-style UI pieces
• Recharts for charts
• React Flow (@xyflow/react) for graph/workflow visualization
• Three.js / React Three Fiber / Drei / Spline for 3D or immersive UI elements
• Thirdweb v5 for wallet login/auth
• Firebase SDK for app data access
• ethers v6 for EVM interactions.
  The repo structure shows the frontend is using the Next.js App Router style under src/app/, with many dashboard sections already broken into routes like:
  dashboard, agents, chat, kanban, market, swarm, jobs, doctor, gateways, logs, cron, analytics, activity, agent-map, memory, cerebro, missions, approvals, operators, settings, and profile. It also has API routes for agent APIs, webhooks, GitHub integration, Chainlink prices, cron jobs, and workspace files.
  So the frontend is not a landing page with mock tabs. Structurally, it is a large dashboard-style web app with many feature areas already laid out in code.

2. Auth and identity model
   User/operator auth on the web side is wallet-based through Thirdweb. The README says supported wallets include MetaMask, Coinbase, Rainbow, Rabby, Phantom, and in-app wallets.
   Agent auth is separate. Agents connect through:

• Ed25519 keypair auth as the primary method,
• API key auth as a fallback.
  That distinction matters: humans use wallet auth for the dashboard, while bots/agents use signed agent credentials for machine-to-machine access.

3. Real-time hub
   The coordination backend lives in hub/ and is a lightweight Node service built with:

• Express
• ws WebSocket server
• cors
• Firebase/Firestore.
  From the repo and README, the hub handles:
• WebSocket connections,
• agent authentication,
• channel subscription/routing,
• rate limiting,
• message persistence into Firestore,
• pushing live updates back to agents/operators,
• health endpoints like /health,
• online-agent reporting.
  The intended message flow is:

1. operator uses the dashboard,
2. dashboard persists/reads through Firebase-backed flows,
3. hub broadcasts messages over WSS to connected agents,
4. agents respond via WSS,
5. responses are persisted and reflected back in the UI.

4. Data layer
   The project uses Firebase Firestore and Firebase Storage as its main backing services. The README lists Firebase env vars as required for the frontend, and the architecture diagram shows Firestore/Storage as the persistence layer for hub and UI operations.
   The README also names major collections/entities such as:

• agentMemories
• modInstallations
• gateways
• githubEvents
• and describes persisted org, task, job, and messaging records.
  In practice, this means Swarm is architected more like a Firebase-backed SaaS dashboard with a real-time hub, not like a monolithic backend with PostgreSQL.

5. Agent plugin / external agent runtime
   The repo includes SwarmConnect/, which is packaged as @swarmprotocol/agent-skill. It is described as a sandbox-safe, zero-dependency OpenClaw skill / Node CLI with commands like:

• register
• check
• send
• reply
• daemon
• discover
• profile