Swarm (Agentic Operating System and Graph Memory)

Operating system and graph memory management for model agnostic agentic AI. Build complex systems using Swarm spaces as building blocks, collaborate and fully manage with other users.

Comment

Project Story

About the Project

Swarm is a platform for coordinating people, AI agents, and autonomous workflows in shared workspaces called Spaces.

A Space contains conversations, agents, runs, artifacts, approvals, operational context, and a Swarm Graph that records how work and knowledge connect. Agents execute through Cores, which can be hosted by Swarm Cloud or connected from external infrastructure. Facets are installable programs that package agent instructions, permissions, integrations, outputs, and automation behavior.

Inspiration

AI work is fragmented across chat applications, local coding tools, automation services, model providers, and internal systems. Context is repeatedly copied between tools, while agent activity is difficult to inspect or coordinate. It's silly that we use .md files for managing things like harnesses and memory.

Swarm started from the idea that agents need a persistent operating environment rather than another isolated chat interface. People should be able to discuss work, invoke agents, review results, approve actions, and run long-lived automation from the same Space.

How It Was Built

Swarm uses an API-first architecture designed to support web, desktop, mobile, SDK, and MCP clients.

The platform includes:

  • A Go API and worker system
  • PostgreSQL for canonical platform records
  • Next.js and TypeScript for the web application
  • GCP Cloud Run for scalable API, worker, and Core execution
  • A model gateway for provider routing, usage accounting, and credential isolation
  • Permit-based authorization for users, agents, Cores, and external connections
  • Idempotent commands, durable events, receipts, and outbox processing
  • Payload references for large files, logs, artifacts, and code
  • Tenant isolation through Entities, Teams, Spaces, and resource-scoped permissions

Agent outputs are stored as artifacts and presented through structured Thread Cards. These cards can expose progress, approvals, references, and actions without replacing the underlying canonical data.

What We Learned

Reliable agent systems require more than model calls and logs. They need explicit execution boundaries, durable context, retry-safe commands, structured outputs, and clear authority over external actions. Also realized that people don't just want an agent management system, but a place to have human conversations as well with team members so I combined the two in the latest version.

We also learned that cloud and connected runtimes should follow the same protocol. This allows a Space to use Swarm Cloud while supporting customer-managed infrastructure without creating separate permission or execution systems.

Challenges

The main challenges were:

  • Supporting autonomous behaviour without hiding consequential actions
  • Preventing duplicate work and billing during retries
  • Isolating tenants, credentials, files, and runtime execution
  • Keeping long-running and dynamically spawned agent work observable
  • Designing flexible primitives without creating large collections of hard-coded types (eliminating enum bloat)
  • Presenting complex agent activity through a clear interface
  • Maintaining consistent behaviour across hosted and connected Cores

Swarm brings human communication, agent execution, automation, context, and review into one system built on shared platform contracts.

Built With

Share this project:

Updates