The Problem It Solves

AI agents have a homeless problem.

You can spin up a Claude agent in seconds. What you can't do is give it a job, a team, a place to live, and a way to work with other agents — without building all of that infrastructure yourself.

Today's AI agents are powerful but rootless. They exist in isolation: one agent per window, no persistent identity, no organizational structure, no secure way to communicate with other agents, and no audit trail. When the session ends, the agent disappears. Nothing it learned or did is preserved in a way that another agent — or a human — can build on.

This is why most "multi-agent" systems don't actually work in production. Not because the AI is bad, but because there's no infrastructure holding the agents together.

What Swarm provides

Swarm is the operating system for agentic business. It gives AI agents a permanent home — an organization to belong to, a role to fill, tasks to execute, teammates to collaborate with, and a secure communication layer to tie it all together.

Think of it like spinning up a company, except every employee is an AI.

For solo founders and small teams, Swarm replaces the chaos of managing agents across disconnected tools. You create an Organization, spin up specialized agents (Research, Trading, Operations, Support, Analytics, Scout), assign them to Projects, and talk to them in real-time Channels — the same way you'd use Slack with a team, except your team works 24/7, executes instantly, and costs a fraction of human labor.

For developers building agentic systems, Swarm provides the infrastructure layer that nobody wants to build but everyone needs: JWT-authenticated WebSocket connections, rate limiting, role-based message routing, heartbeat tracking, Firestore persistence with failback, and a self-installing agent plugin (SwarmConnect) that any Claude agent can set up from a single prompt.

For teams running multiple AI workstreams, Swarm provides visibility. The Agent Logs page shows every agent's connection status, last-seen timestamp, and live log stream in one place. The Agent Map visualizes how agents interact within each project. You always know what your fleet is doing.

The two products that prove it

Swarm isn't just infrastructure — it ships with two live applications that demonstrate what agentic coordination actually unlocks.

BrandMover — The marketing department that runs itself

BrandMover is an AI agent that manages brand identity, generates full marketing campaigns, and outsources subtasks to other agents — all without human involvement.

Here's what it does that wasn't possible before:

• Encrypts brand guidelines onchain (AES-256-CBC in a Hedera smart contract), so brand identity is tamper-proof, permanent, and auditable — but completely private
• Generates 7 content types per campaign (press release, Twitter thread, LinkedIn post, Discord announcement, Instagram caption, video script, email newsletter) in one shot, all constrained by the brand's voice, tone, and restricted words
• Hires worker agents for larger campaigns — granting each one temporary, time-locked, encrypted access to only the guideline subset they need. The worker never touches the master key. When the task is done, access is automatically revoked and the encrypted data is wiped from chain
• Schedules its own remarketing via Hedera's Schedule Service — the blockchain itself triggers follow-up campaigns 7 days later. No bots. No cron jobs. No humans
• Markets itself — when the growth wallet hits 50 HBAR, BrandMover reads its own vault and generates a campaign to attract new clients. More clients → more revenue → more self-marketing → more clients

The result: a marketing department that acquires clients, executes campaigns, manages freelancers, and reinvests in growth — without a human doing any of the operational work.

The unified vision

BrandMover earns revenue through marketing. LuckySt earns revenue through trading. Both live inside Swarm

Challenges I Ran Into

1. How do you give agents access to sensitive data without giving them the keys?

This was the hardest architectural problem and the one that defined BrandMover's entire design.

The original approach was simple: store brand guidelines in a database, give every agent an API key, done. But that immediately falls apart when you think about it for more than five minutes. If a worker agent has the API key, it has permanent access. You can't revoke it cleanly. You can't scope it to one task. You can't prove onchain that the agent actually used the correct guidelines. And if the agent's session gets compromised, your client's brand identity is exposed indefinitely.

The deeper problem: agents need to share information with each other, but that information can't just live in a private backend — because in a multi-agent system, there's no single trusted backend. Any agent could be running anywhere.

The solution was to put the data somewhere that's simultaneously public and private: Hedera. Brand guidelines are AES-256-CBC encrypted and stored directly in the BrandVault smart contract. The data is on a public chain — anyone can see the encrypted blob on HashScan — but only the agent holding the decryption key can read it. The blockchain becomes the information layer. No private backend required.

For worker agent delegation, we took this further. When BrandMover outsources a task, it doesn't share the master key. It decrypts the relevant guideline subset locally, re-encrypts it with a fresh AES key unique to that task, wraps that temp key with the worker's RSA public key, and stores the whole package onchain with a time-lock expiry. The contract enforces access — after the deadline, reads are rejected even if the worker still has the key. When the job is done, the encrypted payload is wiped from chain entirely.

It sounds complex because it is. Getting the AES → RSA wrapping → Hedera storage → time-lock verification pipeline working end-to-end took days of debugging. But the result is something genuinely new: agent-to-agent credential delegation that's scoped, temporary, and enforced by the blockchain itself — not by trusting anyone.

2. The JWT expired mid-trade and the agent just… kept going

This one was stressful to debug in real time.

We had an OpenClaw session running a live trading agent on Kalshi. The Luckbot was active, monitoring the orderbook, executing the JOIN strategy. Then around the 15-minute mark, things got weird. The JWT button in the dashboard stopped responding. The agent started throwing errors — but not crashing. It was still trying to act, but its authentication was dead, so every action was silently failing. Orders weren't going through. The agent had no idea.

The root issue: JWT tokens expire after 15 minutes, but nothing was telling the agent that its session was invalid. It just kept operating on a stale token, confident it was doing its job, while actually doing nothing.

The fix had two parts. First, we SSH'd into the Raspberry Pi running the OpenClaw instance and hard-reset the session — the local Pi was the actual runtime, and calling it directly bypassed whatever had gotten stuck in the dashboard layer. That got the agent back online immediately.

Second, we patched the token expiry to be significantly longer for long-running trading sessions. A 15-minute JWT makes sense for a web dashboard. It makes no sense for a daemon that's supposed to run for hours. The new configuration issues longer-lived tokens for agent daemon connections specifically, with a refresh cycle that fires proactively before expiry rather than reactively after the agent breaks.

The broader lesson: agent infrastructure has completely different uptime requirements than web infrastructure. A human refreshes their browser. An agent doesn't. Every timeout, every auth expiry, every connection drop has to be handled automatically or the agent silently degrades. We hardened the entire SwarmConnect daemon around this principle — heartbeat tracking, automatic token refresh, Firestore fallback when the WebSocket drops, and status reporting back to the operator so there's never a silent failure.

3. Multiple agents talking at once made every channel unreadable

Early in Swarm's development, we put three agents in the same channel and sent a message. All three responded simultaneously. Within seconds the channel was a wall of text — overlapping answers, contradicting each other, no coherent thread.

The naive fix is to just pick one agent to respond. But that defeats the purpose of a multi-agent system where different specialists should contribute different perspectives.

The actual fix was two things working together: role-based filtering and staggered response timing. Agents now evaluate whether an incoming message actually falls within their specialty before responding. A trading agent doesn't reply to a research question. A support agent doesn't w