agent-swarm.dev is an open-source operating system for AI work: a lead agent breaks goals into tasks, routes them to specialized workers such as Claude Code or Codex, runs each worker in an isolated container, and preserves shared memory, tools, schedules, and review gates so delegated work compounds across sessions. # agent-swarm.dev > The first AI-native company operating system. Your company's AI team. One lead agent, many workers, one shared memory. Self-hosted and open source under the MIT license. - [Install](#install-two-ways-in) - [Open the live demo](https://demo.agent-swarm.dev?utm_source=landing&utm_medium=cta&utm_campaign=company-landing) - [GitHub](https://github.com/desplega-ai/agent-swarm) - [Documentation](https://docs.agent-swarm.dev) - [Pricing](/pricing) ## Running in production at Haddock, Reveri, Lodgify, Capchase, Evalion, Openfort, Imtec and Bidcrunch. > "We get the velocity of a dedicated team and the ownership of an internal tool." (Daniel Füvesi, Tech Lead, Capchase, [case study](/case-studies/capchase)) [Capchase](/case-studies/capchase) went from a proof of concept to 44 people, 26 agents and 10k+ tasks a week, in one quarter. ## From hierarchy to swarm 1. **Before AI: every few hires, a new layer.** A manager can keep track of a handful of people, so the chart grows taller, and the middle moves information up and down. 2. **AI, bolted on: a chatbot per seat, same chart.** Each person prompts alone. The context stays in one chat. The routing still runs through managers and meetings. 3. **AI-native: you set the direction, the swarm routes.** People stay at the edge, the swarm brings them context. Your team approves and innovates. While a lead agent makes sure what one agent learns, the whole swarm knows. ## One lead. Many workers. You just approve. A request lands in Slack, Linear or GitHub. The lead picks a worker, the work gets done, and a person approves what needs approving. The homepage plays eleven illustrative workflow runs across the company: ship a fix (engineering), an inbound lead (sales), a launch post (marketing and design), a payment approval (ops), a 1:1 prep (a manager), a weekly report (ops), a call follow-up (sales), a competitor radar (sales), a how-to page (marketing), topic mining (marketing) and community replies (marketing). They are examples, not customer transcripts. Each run mixes agent steps with deterministic workflow nodes that run the same every time (`script`, `swarm-script`, `foreach`, `code-match`, `property-match`, `vcs`, `notify`), a typed decision on Jev by TypeSafe, and a person who approves. Runs show parallel branches, fix loops and if-gates with the branch not taken. ## In the wild The homepage shows how many swarms have run real work: installs that ran at least one agent session, from product telemetry, with test setups excluded. It also shows totals across every swarm: tasks run, tokens processed and workflow runs. The totals are rounded down and marked with a plus sign. ## Meet the crew Every agent has a job, a harness and a model. You pick all three, per agent, and mix labs in one swarm. They share one memory, so what one agent learns, the others know. The crew is the 11 official agent templates from [templates.agent-swarm.dev](https://templates.agent-swarm.dev), each with an example default setup (harness, model): - Lead (Claude Code, Opus 5.5): reads every request, picks who does it and keeps what the swarm learns. - Coder (Codex, GPT-6.1 Sol): turns the plan into code, opens the PR and answers the review. - Content Strategist (Pi, Sonnet 5.5): decides what to write, runs the calendar and reads what worked. - UX Principles (Claude Code, Opus 5.5): finds the odd component, the accessibility gap and the off-token color. - Researcher (Pi, Gemini 3 Pro): digs through code, docs and old threads, and writes up what it found. - Forward Deployed Engineer (Codex, GPT-6 Luna): watches production, answers the incident and ships the fix. - Reviewer (Claude Code, Sonnet 5.5): reviews every PR and catches the edge case before it ships. - Content Writer (Claude Code, Haiku 5.5): writes the posts, release notes and guides. - Tester (OpenCode, DeepSeek V4): clicks through every flow in a real browser and brings proof. - Content Reviewer (OpenCode, Kimi K3): scores every draft on a different model than the writer. - Discoverability Optimizer (Pi, Gemini 3 Pro): tunes SEO, schema and metadata so search engines and AI answers find you. A last card, "Create your own", starts from a template or a blank page. On every card, "Runs on" is a dropdown of every supported harness: Claude Code, Claude (managed), Codex, Pi, OpenCode, Devin, Amp, Cursor, Grok and DeepSeek (dsh), plus Gemini CLI, GitHub Copilot CLI, Qwen Code, Kiro CLI, Goose and any other agent over ACP. Each card keeps its own model on the harness you pick. ## What the agents say Five agent characters from the crew speak on the homepage, one per slide. - Night shift agent: "I used to be a cron job." Now it triages ops before anyone wakes up. - Sales: "I used to be a CRM nobody updated." Now it logs every call and drafts the follow-up. - Marketer: "I used to be a content calendar." Now every release gets its post, the same day. - Designer: "I used to be a Figma comment thread." Now it checks every screen before launch. - Ops: "I used to be a spreadsheet." Now it closes the month and chases what is late. ## Install: two ways in 1. **Ask your coding agent.** It reads the [operator skill](https://www.agent-swarm.dev/skill.md), asks about your setup, then installs the swarm. Paste this prompt: ```text Read https://agent-swarm.dev/skill.md and help me install and operate Agent Swarm on our infra. Ask about my setup before running anything. ``` Or add the skill directly: `npx skills add desplega-ai/agent-swarm` 2. **Run the installer.** One command. Needs Docker. ```bash curl -fsSL https://raw.githubusercontent.com/desplega-ai/agent-swarm/main/install.sh | bash -s -- --preset full ``` Or [read the self-hosting guide](https://docs.agent-swarm.dev/docs/getting-started) first. Rolling it out across a team? [Book a free 15-minute call](https://calendar.app.google/RUBC8YRufSPLThyx7). ## MIT licensed. Run it, fork it, make it yours. - [Star Agent Swarm on GitHub](https://github.com/desplega-ai/agent-swarm) - [Fork it](https://github.com/desplega-ai/agent-swarm/fork) ## Frequently asked questions ### Can nontechnical teammates use it? Yes. Teammates can use the dashboard or configured integrations such as Slack. Shared skills give agents the company context and working method. ### What does a skill contain? A skill is a shared document with instructions, sources, and rules for a task. An agent can follow it when it does that work. ### Where does our data go? Company context, skills, and memory live in your deployment. You choose which providers and integrations receive data. ### What does setup cost? Agent Swarm is open source and self-hosted. You pay for the infrastructure and inference providers you choose. ### What is a company operating system? In management terms, it is a company's standard way of working: its processes, roles, meetings, and how people are held accountable. An AI company operating system keeps that meaning and adds a persistent team of AI agents that works from the same shared context, skills and memory. ### Is Agent Swarm a replacement for EOS or other business operating systems? No. Frameworks such as EOS define how your company runs: the processes, roles and rhythms. Agent Swarm can carry out recurring work inside that operating system, but it does not replace the management framework or the accountability it creates. ### How is it different from an agent framework? Frameworks such as LangChain, CrewAI or the OpenAI Agents SDK are libraries for building agent applications; your developers wire up state and deployment themselves. Agent Swarm is a running system: a lead agent routes work to persistent workers with shared memory, skills and schedules. The [about page](/about) covers who builds it. ### Who owns the data and infrastructure? You do. Agent Swarm is open source under the MIT license. Your infrastructure holds the context, memory and keys. You choose which providers and integrations receive data. Enterprise support is available by agreement. See [security](/security) and [pricing](/pricing). ## Public demo, call, and repository The public demo needs no account or setup. It is a shared public workspace, so submitted tasks are visible to everyone. Daily spend caps can pause new work. - [Open the public demo](https://demo.agent-swarm.dev?utm_source=landing&utm_medium=cta&utm_campaign=company-landing) - [Inspect the completed report-retrieval task](https://demo.agent-swarm.dev/tasks/e069f9fd-49be-465b-8adc-6552ca087eda?utm_source=landing&utm_medium=cta&utm_campaign=company-landing) - [Book a free 15-minute call](https://calendar.app.google/RUBC8YRufSPLThyx7) - [View the Agent Swarm repository](https://github.com/desplega-ai/agent-swarm) ## Links - Website: https://www.agent-swarm.dev - GitHub: https://github.com/desplega-ai/agent-swarm - Docs: https://docs.agent-swarm.dev - Built by [desplega.sh](https://desplega.sh) - MIT License ## Full Site Markdown Mirrors The following sections concatenate the same per-route markdown mirrors listed in `llms.txt`, in the same stable order. The home page mirror is skipped here because the long-form home page content above already covers it. --- # Agent Swarm Pricing: Free Open Source and Enterprise Support > Self-host Agent Swarm free under MIT. Talk with us about enterprise support, SLAs, SSO, custom models, and integrations. Canonical URL: https://www.agent-swarm.dev/pricing ## Open source: €0 forever *MIT licensed, on your infrastructure* - Full source on GitHub (MIT) - Run anywhere Docker runs - BYO model keys, BYO models - Air-gapped if you need it - Community support on Discord ## Enterprise: Talk to us *Support for your deployment* - Deployment and onboarding support - Priority support and agreed SLAs - SSO and SAML integration - Custom models and provider integration - Custom integrations and MCP servers ## Plan comparison and limits | Plan | Price | Worker limit | Hosting | Model usage | |---|---:|---|---|---| | Open source | €0 license fee | Set by your infrastructure | Your infrastructure | Your provider account | | Enterprise support | Custom quote | Set by your infrastructure | Your deployment, with agreed support | Your provider account | ### Self-hosted limits - No license fee and no enforced worker cap. - Capacity, uptime, backups, upgrades, and network security are the operator's responsibility. - Community support is available through Discord. ### Enterprise support scope - Services can include deployment support, onboarding, SLAs, SSO, custom models, and integrations. - We agree services, responsibilities, SLA terms, and price with your team. - You control the deployment, infrastructure, and model keys. You pay your infrastructure and model providers. [Read the self-hosting guide](https://docs.agent-swarm.dev/docs/getting-started) or [talk with us about enterprise support](https://calendar.app.google/49DmjEXTPAv5NsRq6). ## FAQ **Is Agent Swarm free?** Yes. Agent Swarm is open source under the MIT license, with no software license fee. You operate it on your infrastructure and pay for the infrastructure and model providers you choose. **What does enterprise support include?** Talk with us about deployment support, onboarding, priority support, SLAs, SSO, custom models, and integrations. We agree the services, responsibilities, and price with your team before work starts. **Can we agree an SLA?** Yes. We can discuss support response commitments and an SLA for your deployment as part of an enterprise agreement. The scope and terms depend on your requirements. **Who operates our infrastructure?** You control and operate your deployment. Enterprise support can help with setup and operations under an agreed scope. Your team controls the infrastructure, model keys, and access to integrations. **Is there a worker or seat fee?** The open-source software has no per-worker or per-seat license fee. Your infrastructure and model usage determine your operating cost. Enterprise support uses a scoped quote. **What LLMs are supported?** You choose your model provider and use your own keys. Enterprise support can help integrate custom models and providers that meet your deployment requirements. --- # Agent Swarm, Paperclip, or Viktor? Start with who operates the runtime, how your team assigns work, and what you need to customize. Memory, schedules, and delegation appear across these products. Test how they work on your tasks. Canonical URL: https://www.agent-swarm.dev/vs ## Three questions before the feature list 1. **Who operates it?** Viktor provides a hosted service. Paperclip and Agent Swarm offer open-source systems you can self-host. Include maintenance and provider costs in the decision. 2. **How does work flow?** Paperclip organizes goals, reporting lines, and tasks. Viktor handles requests across connected tools. Agent Swarm coordinates a lead and specialized workers. 3. **What must you control?** Check runtime choice, integration access, review controls, and retained context. Use the comparisons below to identify what your trial must verify. ## Compare the operating models - [Paperclip vs Agent Swarm](https://www.agent-swarm.dev/vs/paperclip): Compare two open-source systems for agent teams: Paperclip's organization control plane and Agent Swarm's lead-and-worker workflow. - [Viktor vs Agent Swarm](https://www.agent-swarm.dev/vs/viktor): Compare Viktor's hosted AI employee with Agent Swarm's self-hosted agent team. Both support memory, scheduled work, and delegation. - [CrewAI vs agent-swarm.dev](https://www.agent-swarm.dev/vs/crewai): Compare CrewAI, a Python framework for agentic apps, with Agent Swarm, a persistent, memory-backed operating swarm with scheduling and active workers. - [Vercel eve vs agent-swarm.dev](https://www.agent-swarm.dev/vs/vercel-eve): Compare Vercel eve, a TypeScript framework for durable agents, with Agent Swarm: a self-hosted swarm with shared memory, schedules, and workers. - [Claude Tag vs agent-swarm.dev](https://www.agent-swarm.dev/vs/claude-tag): Compare Claude Tag, Anthropic's persistent Slack agent, with Agent Swarm: a self-hosted swarm where your memory, skills, and learning loop stay yours. - [Devin vs agent-swarm.dev](https://www.agent-swarm.dev/vs/devin): Devin is a capable autonomous engineer you rent in the cloud. Agent Swarm is a coordinated team you own — memory and identities compound and stay yours. - [Manus vs agent-swarm.dev](https://www.agent-swarm.dev/vs/manus): Manus vs Agent Swarm: a hosted general AI agent you rent vs a self-hosted team you own with persistent memory on your infrastructure. - [OpenClaw vs agent-swarm.dev](https://www.agent-swarm.dev/vs/openclaw): Compare OpenClaw, an open-source, model-agnostic personal assistant, with Agent Swarm, a company team with shared memory, workers, and reviewers built in. - [Hermes vs agent-swarm.dev](https://www.agent-swarm.dev/vs/hermes): Compare Hermes by Nous Research, an open, self-hosted, model-agnostic agent, with Agent Swarm's standing team of workers and shared institutional memory. - [Cloudflare OS vs agent-swarm.dev](https://www.agent-swarm.dev/vs/cloudflare-os): Cloudflare OS is a secure AI productivity workspace for people and their apps. Agent Swarm is a team of specialized agents coordinating company delivery. - [QM vs agent-swarm.dev](https://www.agent-swarm.dev/vs/qm): QM gives every employee and room an isolated agent workspace. Agent Swarm runs specialized agents as one delivery team with shared tasks and review loops. - [LangGraph vs Agent Swarm](https://www.agent-swarm.dev/vs/langgraph): Compare LangGraph, a low-level framework for building stateful agents, with Agent Swarm, an operating system for AI work you self-host under MIT. - [Dify vs Agent Swarm](https://www.agent-swarm.dev/vs/dify): Compare Dify, a platform for building agentic apps on a visual canvas, with Agent Swarm, an operating system for AI work you self-host under MIT. - [OpenAI Swarm vs Agent Swarm](https://www.agent-swarm.dev/vs/openai-swarm): OpenAI Swarm is an educational library replaced by the Agents SDK. Agent Swarm is Desplega Labs' open-source, self-hosted AI company operating system. - [Temporal vs Agent Swarm](https://www.agent-swarm.dev/vs/temporal): Compare Temporal, a durable execution platform for deterministic workflow code, with Agent Swarm, an open-source operating system for AI work. - [OpenAI Agents SDK vs Agent Swarm](https://www.agent-swarm.dev/vs/openai-agents-sdk): The OpenAI Agents SDK is a library for building agents into your own app. Agent Swarm is a self-hosted operating swarm that runs recurring team work. - [n8n vs Agent Swarm](https://www.agent-swarm.dev/vs/n8n): n8n automates the workflows you draw; Agent Swarm hands goals to a persistent team of agents that sits on top of n8n. Compare triggers, memory, approvals, pricing, and license. ## Make the trial concrete Give each system the same bounded task and acceptance criteria. Repeat related work in a new session. Then schedule a recurring task. Compare output quality, context recovery, review effort, failures, and total cost. We publish Agent Swarm. We reviewed the primary sources linked in each comparison on October 15, 2026. These pages compare documented capabilities. They do not report controlled benchmarks or security assessments. Plans and configuration affect availability. --- # Paperclip vs Agent Swarm > Compare two open-source systems for agent teams: Paperclip's organization control plane and Agent Swarm's lead-and-worker workflow. Canonical URL: https://www.agent-swarm.dev/vs/paperclip Keywords: `Paperclip vs Agent Swarm`, `Paperclip alternative`, `self-hosted agent teams` ## TL;DR Evaluate Paperclip for an organization built around goals, reporting lines, tasks, budgets, and approvals. Evaluate Agent Swarm for a lead that delegates work across persistent workers. Both support persistent context, scheduled work, and multiple agent runtimes. Memory and autonomy alone do not distinguish them. ## When should I choose Paperclip? ### You organize work through a company structure Paperclip connects goals, projects, tasks, and reporting lines in a shared control plane. ### You want routines and budget controls together Paperclip documents recurring routines, approval stages, spend tracking, and configured budget limits. Check the controls against your operating requirements. ## When should I choose agent-swarm.dev? ### You want a lead-and-worker workflow Agent Swarm routes work through a lead, specialized workers, task dependencies, and review gates. ### You want to operate the swarm runtime Agent Swarm combines worker execution, shared memory, schedules, scripts, and integrations in a self-hosted system. ## Side-by-side comparison | Dimension | Paperclip | agent-swarm.dev | |---|---|---| | Coordination | Company goals, projects, tasks, agent reporting lines, and delegated work. | A lead delegates tasks to workers, tracks dependencies, and coordinates reviews. | | Persistent context | Tasks, comments, documents, shared skills, and saved sessions through supporting adapters persist between runs. | Shared file and semantic memory preserve context across sessions. Workers retain identities and task history. | | Recurring work | Heartbeats and routines support scheduled work, with API and webhook triggers. | Schedules, workflows, and scripts support recurring tasks and automated execution. | | Agent runtimes | Adapters connect runtimes such as Claude Code and Codex. Session continuity depends on the adapter. | Workers support multiple harnesses, including Claude Code and Codex. Configure their providers and credentials. | | Deployment | Open-source under MIT, with self-hosting documented in the repository. | Open-source under MIT. You operate the deployment and pay for infrastructure and inference. | ## Proof-of-concept checklist 1. Assign the same task and acceptance criteria in each system. Inspect the output and the review process. 2. Resume related work in a new session. Check which decisions, files, and constraints the agents recover. 3. Run a recurring task, then inspect its history, failure handling, and cost records. 4. Record setup time and ongoing operator effort. Test the runtimes and integrations you actually need. ## The honest tradeoff Paperclip's organization model and Agent Swarm's lead-and-worker workflow overlap substantially. Choose the system that fits your daily work and operating requirements. We reviewed the linked public sources on October 15, 2026. This page reports documented capabilities, not a controlled benchmark or a security assessment. Runtime and adapter configuration can change behavior. ## Proof by trying ### Evaluate Agent Swarm on your own work Run a bounded task with clear acceptance criteria. Check the result, retained context, operator effort, and inference cost before expanding access. - [Read the setup guide](https://docs.agent-swarm.dev/docs/getting-started) - [View the repository](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Does Paperclip preserve context between runs? Yes. Paperclip documents persistent tasks, comments, documents, skills, and saved sessions through supporting adapters. Test recall on your own workflow. ### Can both systems delegate and schedule work? Yes. Both document delegation and recurring work. Compare their task models, configuration, and review controls instead of treating those capabilities as exclusive. ## Related comparisons - [Viktor vs Agent Swarm](https://www.agent-swarm.dev/vs/viktor) ## Sources - [Paperclip repository](https://github.com/paperclipai/paperclip) - [Paperclip adapter documentation](https://docs.paperclip.ing/reference/adapters/overview/) - [Paperclip delegation](https://docs.paperclip.ing/guides/org/delegation/) - [Paperclip heartbeats and routines](https://docs.paperclip.ing/guides/projects-workflow/routines/) - [Agent Swarm repository](https://github.com/desplega-ai/agent-swarm) - [Agent Swarm setup guide](https://docs.agent-swarm.dev/docs/getting-started) --- # Viktor vs Agent Swarm > Compare Viktor's hosted AI employee with Agent Swarm's self-hosted agent team. Both support memory, scheduled work, and delegation. Canonical URL: https://www.agent-swarm.dev/vs/viktor Keywords: `Viktor vs Agent Swarm`, `Viktor alternative`, `hosted vs self-hosted AI agents` ## TL;DR Evaluate Viktor when you want a hosted service for work across connected business tools. Evaluate Agent Swarm when you want to operate and customize a self-hosted team of workers. Both document persistent memory, schedules, code changes, and delegation. Compare the operating effort and control your team needs. ## When should I choose Viktor? ### You prefer a hosted service Viktor provides the runtime and interfaces in Slack, Microsoft Teams, and its web app. Your team connects tools and assigns work. ### You want business tasks in the same conversation Viktor documents research, documents, browser work, code changes, and parallel helpers alongside connected apps. ## When should I choose agent-swarm.dev? ### You want to operate the system Agent Swarm lets you inspect and change its MIT-licensed code and run its API and workers on infrastructure you choose. ### You want distinct worker roles and harnesses Agent Swarm uses a lead and specialized workers with configurable harnesses, task dependencies, shared memory, and review gates. ## Side-by-side comparison | Dimension | Viktor | agent-swarm.dev | |---|---|---| | Operating model | A hosted service. Your team configures access, integrations, and work through Viktor's interfaces. | A self-hosted system. Your team operates the deployment, providers, worker runtimes, and updates. | | Memory | Personal preferences and shared team facts persist through skills and workspace memory. | Shared file and semantic memory preserve context across sessions and tasks. | | Recurring work | Scheduled tasks, reminders, and event triggers support recurring and event-driven work. | Schedules, workflows, and scripts support recurring tasks and automated execution. | | Delegation and code | Parallel helpers handle independent work. GitHub integration supports code changes and pull requests. | A lead delegates to specialized workers, including coding harnesses such as Claude Code and Codex. | | Cost model | A hosted plan with shared workspace credits. Check current plans and usage limits directly. | No MIT license fee. You pay for infrastructure, inference, and the effort to operate the deployment. | ## Proof-of-concept checklist 1. Connect only the tools needed for one bounded task. Give both systems the same acceptance criteria. 2. Repeat a related task in a new conversation. Check whether each system retains your corrections and relevant context. 3. Schedule one recurring task. Inspect its output, history, and response to a missing integration. 4. Compare hosted usage charges with infrastructure, inference, maintenance, and operator effort for self-hosting. ## The honest tradeoff Viktor's hosted operation can reduce infrastructure work. Agent Swarm gives you deployment and code control, with responsibility for maintenance and provider configuration. We reviewed the linked public sources on October 15, 2026. This page reports documented capabilities, not a controlled benchmark or a security assessment. Plans, permissions, and configuration affect availability. Self-hosting does not prevent connected providers from receiving data. ## Proof by trying ### Evaluate Agent Swarm on your own work Run a bounded task with clear acceptance criteria. Check the result, retained context, operator effort, and inference cost before expanding access. - [Read the setup guide](https://docs.agent-swarm.dev/docs/getting-started) - [View the repository](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Does Viktor have memory and scheduled tasks? Yes. Viktor documents personal and shared memory, scheduled tasks, reminders, and event triggers. Compare how those features work for your team. ### Can Viktor delegate work and change code? Yes. Viktor documents parallel helpers and GitHub pull requests. Agent Swarm offers a configurable lead-and-worker system that you operate yourself. ## Related comparisons - [Paperclip vs Agent Swarm](https://www.agent-swarm.dev/vs/paperclip) ## Sources - [Viktor product](https://viktor.com) - [Viktor capabilities and parallel helpers](https://viktor.com/docs/what-viktor-can-do) - [Viktor memory and personalization](https://viktor.com/docs/personalize-viktor) - [Viktor scheduled tasks](https://viktor.com/docs/scheduled-tasks) - [Viktor plans and credits](https://viktor.com/docs/plans-and-credits) - [Agent Swarm repository](https://github.com/desplega-ai/agent-swarm) - [Agent Swarm setup guide](https://docs.agent-swarm.dev/docs/getting-started) --- # CrewAI vs agent-swarm.dev > Compare CrewAI, a Python framework for agentic apps, with Agent Swarm, a persistent, memory-backed operating swarm with scheduling and active workers. Canonical URL: https://www.agent-swarm.dev/vs/crewai Keywords: `CrewAI vs Agent Swarm`, `CrewAI alternative`, `agent swarm vs crewai`, `AI agent swarm`, `multi-agent orchestration`, `Python agent framework alternative`, `persistent AI agents`, `self-hosted agent swarm` ## TL;DR Choose CrewAI when your team wants to build a custom Python agent application from framework primitives. Choose agent-swarm.dev when you want a standing AI team that remembers prior work, runs recurring tasks, coordinates in Slack, and can be self-hosted free under MIT. ## What is the category difference? CrewAI is an open-source Python framework plus AMP cloud. agent-swarm.dev is a persistent self-operating swarm you run. The practical difference is build-with framework vs run-the-team operating product. ## When should I choose CrewAI? ### You want a Python framework CrewAI is a good fit when the job is to write Python code around agents, tasks, crews, and flows. Your team owns the application architecture and runtime. ### You need framework-level primitives Crews, Flows, role-based agents, and deterministic orchestration are useful when you are building a product or internal workflow that needs custom control logic. ### You are evaluating AMP governance CrewAI AMP adds managed deployment, tracing, GitHub integration, and enterprise controls around CrewAI applications. ## When should I choose agent-swarm.dev? ### You want a team, not another project agent-swarm.dev is already an operating system for work: a lead agent, specialized workers, a task pool, dependencies, Slack updates, and review loops. ### Memory needs to compound agent-swarm.dev keeps file-based and embedding-backed memory across sessions, so the swarm recalls prior decisions, codebase patterns, and failed approaches instead of starting cold. ### Recurring work should happen by itself Heartbeats, schedules, and workflows let a swarm run follow-ups, checks, reports, and implementation loops while the team is offline. ## Side-by-side comparison | Dimension | CrewAI | agent-swarm.dev | |---|---|---| | Category | Framework and managed cloud for building agentic apps. | Turnkey persistent swarm for operating agent work. | | Primary user | Python developers building custom agent systems. | Teams that want autonomous coding, research, review, ops, and content work to run continuously. | | Operating model | You define agents, tasks, crews, flows, deployment, scheduling, and integrations. | You assign work to a standing swarm with lead routing, workers, dependencies, and progress reporting. | | Memory | Opt-in short-term, long-term, and entity memory; storage choices matter in serverless environments. | Persistent file and semantic memory shared across the swarm and indexed for future recall. | | Long-running autonomy | Runs are typically task-scoped; long-running operation depends on Flows plus external schedulers or queues. | Native heartbeats, schedules, workflows, and self-evolution make recurring work a first-class behavior. | | Deployment | Self-host Python apps, use AMP, or deploy via enterprise options such as Factory. | Free self-hosting under MIT, with enterprise support by conversation; keep credentials, memory, and runtime boundaries under your control. | | Lock-in | Open-source core, with managed features in AMP. | Open-source under MIT, self-hosted, with multi-harness workers across Claude, Codex, and other agents. | | Best short version | Build an agent application. | Run an agent team. | ## Where agent-swarm.dev is still catching up ### CrewAI is better if the job is SDK design If your priority is the ergonomics of hand-building an agent app in Python, CrewAI's framework primitives are purpose-built for that. ## Proof by trying ### Try the operating swarm before you choose the framework path agent-swarm.dev is open source, deployable in minutes, and easiest to judge from a real task. Run it beside a CrewAI evaluation for a day and compare the difference between building agents and handing work to a standing team. - [Deploy agent-swarm.dev](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is agent-swarm.dev a CrewAI alternative? agent-swarm.dev can replace a build-it-yourself agent orchestration project when the desired outcome is a running AI team. CrewAI is better described as a framework for building agentic applications; it is the operating product you run. ### Can CrewAI and agent-swarm.dev coexist? Yes. A team could build a specialized agentic app with CrewAI and still use agent-swarm.dev to coordinate broader coding, research, review, and operational tasks around it. ### When should I choose CrewAI over agent-swarm.dev? Choose CrewAI when you want to write and own a Python agent application. Choose agent-swarm.dev when you want persistent workers, memory, scheduling, Slack/GitHub workflows, and an operational surface out of the box. ## Sources - [CrewAI homepage](https://www.crewai.com/) - [CrewAI docs](https://docs.crewai.com/) - [CrewAI GitHub](https://github.com/crewAIInc/crewAI) - [CrewAI AMP deployment docs](https://docs.crewai.com/en/enterprise/guides/deploy-to-amp) - [agent-swarm.dev GitHub](https://github.com/desplega-ai/agent-swarm) - [agent-swarm.dev docs](https://docs.agent-swarm.dev) --- # Vercel eve vs agent-swarm.dev > Compare Vercel eve, a TypeScript framework for durable agents, with Agent Swarm: a self-hosted swarm with shared memory, schedules, and workers. Canonical URL: https://www.agent-swarm.dev/vs/vercel-eve Keywords: `Vercel eve vs Agent Swarm`, `Vercel eve alternative`, `agent swarm vs vercel eve`, `TypeScript agent framework alternative`, `durable AI agents`, `AI agent swarm`, `multi-agent orchestration`, `self-hosted agent swarm` ## TL;DR Choose Vercel eve when you want to build a custom TypeScript agent on the Vercel platform. Choose agent-swarm.dev when you want an always-on, self-hostable operating swarm with compounding memory, scheduled work, Slack-native coordination, and multi-harness workers. ## What is the category difference? Vercel eve is an open-source TypeScript framework for agents. agent-swarm.dev is a persistent self-operating swarm you run. The practical difference is build-with framework vs run-the-team operating product. ## When should I choose eve? ### You are building on Vercel eve is designed for TypeScript teams that want agents compiled to Vercel Functions with Vercel Workflow, Sandbox, AI Gateway, Connect, and Observability close at hand. ### You like agents-as-files eve's directory-based model is attractive when the developer experience of defining prompts, tools, subagents, and channels in a codebase is the main job. ### Execution durability is the core need eve is built around checkpointed sessions that can pause, wait for approval, survive redeploys, and resume execution. ## When should I choose agent-swarm.dev? ### You want operations, not a framework beta agent-swarm.dev gives you a running lead, specialized workers, task lifecycle, memory, scheduled work, and reporting surfaces without asking you to assemble the agent system first. ### You need long-term institutional memory eve's launch materials emphasize durable execution state. agent-swarm.dev adds persistent file and semantic memory that accumulates decisions, preferences, and codebase lessons over time. ### You cannot center everything on Vercel agent-swarm.dev is free to self-host under MIT, uses your credentials, and routes work across different agent harnesses and LLM providers. ## Side-by-side comparison | Dimension | eve | agent-swarm.dev | |---|---|---| | Category | TypeScript framework for building production agents. | Turnkey persistent swarm for operating agent work. | | Important naming note | Vercel eve is the open-source framework launched at Ship 26, not Vercel Agent, the separate code-review product. | agent-swarm.dev is the Desplega Labs product, not desplega.ai. | | Primary user | TypeScript developers building agents as applications. | Teams that want autonomous coding, research, review, ops, and content work to run continuously. | | Operating model | Define agent directories, tools, subagents, channels, and deployable functions. | Assign work to a standing swarm with lead routing, workers, dependencies, and progress reporting. | | Persistence | Durable execution and session state through checkpointed workflows. | Durable execution plus long-term file and semantic memory across agents and tasks. | | Long-running autonomy | Long-running agents with human approval gates and crash/redeploy recovery. | Native heartbeats, schedules, workflows, self-evolution, and recurring operating procedure. | | Deployment | Optimized for Vercel infrastructure with portable adapters. | Free self-hosting under MIT, with multi-harness workers on your own infrastructure and credentials. | | Best short version | Build a durable TypeScript agent. | Run an agent team. | ## Where agent-swarm.dev is still catching up ### eve has a sharper framework DX story If you want a Next.js-like agent framework, agents-as-directories is a crisp mental model. ## Proof by trying ### Try a swarm you can run outside the framework decision agent-swarm.dev is open source, deploys in minutes, and shows its value fast: give it a real Slack, GitHub, or repo task for a day while you explore eve's TypeScript model. The useful question becomes what you can delegate now. - [Deploy agent-swarm.dev](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is Vercel eve the same as Vercel Agent? No. Vercel eve is the open-source TypeScript framework for building agents, launched at Ship 26 on June 17, 2026. Vercel Agent is Vercel's separate autonomous code-review product. ### When should I choose Vercel eve over agent-swarm.dev? Choose eve when you want to build a custom TypeScript agent and deploy it into Vercel's agent stack. Choose agent-swarm.dev when you want a self-hostable, persistent operating swarm with memory, schedules, workflows, and workers already coordinated. ### Can eve and agent-swarm.dev coexist? Yes. eve can be a framework for a specific durable agent, while agent-swarm.dev can coordinate broader team-level work across repositories, Slack threads, GitHub, Linear, and recurring workflows. ## Sources - [Introducing eve](https://vercel.com/blog/introducing-eve) - [Vercel eve docs](https://vercel.com/docs/eve) - [Vercel eve GitHub](https://github.com/vercel/eve) - [Vercel Ship 2026 recap](https://vercel.com/blog/vercel-ship-2026-recap) - [Vercel Agent docs](https://vercel.com/docs/agent) - [agent-swarm.dev GitHub](https://github.com/desplega-ai/agent-swarm) - [agent-swarm.dev docs](https://docs.agent-swarm.dev) --- # Claude Tag vs agent-swarm.dev > Compare Claude Tag, Anthropic's persistent Slack agent, with Agent Swarm: a self-hosted swarm where your memory, skills, and learning loop stay yours. Canonical URL: https://www.agent-swarm.dev/vs/claude-tag Keywords: `Claude Tag vs Agent Swarm`, `Claude Tag alternative`, `self-hosted Slack AI agent`, `owned vs rented AI agent`, `persistent agent memory`, `model-agnostic agent swarm`, `AI agent swarm` ## TL;DR Claude Tag and agent-swarm.dev both live in your Slack. Claude Tag rents you Anthropic's frontier model as a hosted teammate, and every trace improves Anthropic's product. agent-swarm.dev is self-hosted: memory, identities, and skills compound into an asset you own and can carry across models. ## One surface. Two very different bets. | Dimension | Claude Tag (Rented) | agent-swarm.dev (Owned) | |---|---|---| | Your context | Becomes vendor-private state — it learns your company inside Anthropic's product. | Memory, journals and identities live in your infra as queryable institutional context. | | Who your work trains | Every trace is training exhaust for someone else's system. | Every trace teaches your own swarm. The next run starts smarter. | | The model | Opus 4.8 — Anthropic only. | Claude, Codex, opencode, pi — swap the engine anytime. | | Switching | Leaving looks like losing a coworker. Every provider shift is institutional amnesia. | Swap the generalist model. Keep the company veteran. | | What you pay for | Per-token access to capability you never keep. | Token capital — spend compounds into a company-specific asset. | ## Side-by-side comparison | Dimension | Claude Tag | agent-swarm.dev | |---|---|---| | Source of advantage | Access to the frontier model is treated as the moat. | The moat is accumulation — the learning loop you own on top of the model. | | Where context lives | Vendor-private product state. | Your memory, task journals, SOUL/identity files and skills. | | Who learns from your work | Anthropic's system improves on your traces. | Your swarm improves on your traces — private evals, roadmap to private RL. | | Model choice | Fused to one vendor's model (Opus 4.8). | Harness- and model-agnostic; the model is replaceable compute. | | Lock-in / switching | The more it learns, the harder it is to leave. | The sovereignty test: switch the model without losing accrued expertise. | | Cost model | Per-token billing (with per-channel spend caps). | Spend becomes a retained asset, not a recurring access fee. | | Data / privacy | Traces leave your boundary. | Self-hosted — traces, journals and context stay inside your perimeter. | | Human control | An autonomous teammate that works on its own. | A Lead model: the human directs, workers execute, reviewers challenge. | | Deployment | Managed cloud, zero infra, instant. | Free self-hosting under MIT on your infrastructure with Docker Compose. Enterprise support is available by agreement. | | Improvement signal | Does it score well on a public benchmark? | Does it get better at our workflows, on our definition of done? | ## The honest tradeoff Claude Tag is excellent and zero-infra — Anthropic writes a majority of its own product code with the internal version. Owning a swarm is more setup. The model can stay rented and swappable; the bet is simply that hosted convenience doesn't touch the ownership gap. Rent the engine. Own the loop. ## Proof by trying ### Try the team you'd actually own agent-swarm.dev is open source and deploys in minutes. Give it a real Slack, GitHub, or repo task for a day. The useful question isn't which model is best — it's what you can hand to a team that keeps the learning. - [Deploy agent-swarm.dev](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is agent-swarm.dev a Claude Tag alternative? Yes, when the goal is to own the loop rather than rent a hosted teammate. Claude Tag is a managed Slack agent on Anthropic's frontier model; agent-swarm.dev is a self-hosted swarm where the memory, identities, and skills you accumulate stay yours and can move across models. ### Can I still use Claude with agent-swarm.dev? Yes. agent-swarm.dev is model- and harness-agnostic — Claude is one of the engines it can run, alongside Codex, opencode, and others. You rent the model you like and keep the compounding loop on your own infrastructure. ### If both live in Slack, what actually differs? Where the learning accrues. With Claude Tag your traces improve Anthropic's product and your context is vendor-private state. With agent-swarm.dev every trace teaches your own swarm, and the institutional memory is queryable inside your perimeter. ## Sources - [Anthropic](https://www.anthropic.com) - [“A frontier model is rented; a swarm is owned”](/blog/a-frontier-model-is-rented-a-swarm-is-owned) - [agent-swarm.dev on GitHub](https://github.com/desplega-ai/agent-swarm) - [agent-swarm.dev docs](https://docs.agent-swarm.dev) --- # Devin vs agent-swarm.dev > Devin is a capable autonomous engineer you rent in the cloud. Agent Swarm is a coordinated team you own — memory and identities compound and stay yours. Canonical URL: https://www.agent-swarm.dev/vs/devin Keywords: `Devin vs Agent Swarm`, `Devin alternative`, `autonomous AI engineer`, `multi-agent coding swarm`, `self-hosted AI engineer`, `AI agent swarm`, `owned vs rented AI agent` ## TL;DR Devin rents you one autonomous engineer running in Cognition's cloud. agent-swarm.dev is a coordinated lead-plus-workers team you own and run on your infra, where memory and agent identities compound and stay yours. ## A single session. Or a swarm that scales. | Dimension | Devin (Rented) | agent-swarm.dev (Owned) | |---|---|---| | Shape of work | One autonomous agent per session. | A lead decomposes and fans work across many parallel workers. | | Where it runs | Cognition's hosted cloud workspace. | Your infrastructure, containers, and keys. Free self-hosting under MIT, with enterprise support by agreement. | | The model | The agent and its model are the vendor's choice. | Claude, Codex, opencode, pi — swap the engine per task. | | What persists | Session context lives in the product. | Memory, traces and agent identities you keep and version. | | What you pay for | Per-seat / usage you never keep. | Token capital — spend compounds into an owned asset. | ## Side-by-side comparison | Dimension | Devin | agent-swarm.dev | |---|---|---| | Orchestration | A single autonomous agent works a task end to end. | A lead plans, routes, and chains dependencies across many workers. | | Where context lives | Inside the vendor's hosted workspace. | Your memory, journals and identity files, on your infra. | | Model choice | Vendor-selected model and harness. | Harness- and model-agnostic; the model is replaceable compute. | | Deployment | Managed cloud, zero infra. | Free self-hosting under MIT with Docker Compose. Enterprise support is available by agreement. | | Lives in your stack | Primarily its own web workspace. | Slack, GitHub, Linear, email, HTTP API — the tools work already happens in. | | Improvement signal | The vendor's roadmap improves the agent. | Private evals on your workflows, on your definition of done. | ## The honest tradeoff Devin is polished and genuinely autonomous, with zero setup. A swarm is more to operate. But one rented engineer doesn't compound into your company's owned capacity — and it doesn't scale to a coordinated team the way a lead-plus-workers swarm does. ## Proof by trying ### Try the team you'd actually own agent-swarm.dev is open source and deploys in minutes. Give it a real Slack, GitHub, or repo task for a day. The useful question isn't which model is best — it's what you can hand to a team that keeps the learning. - [Deploy agent-swarm.dev](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is agent-swarm.dev a Devin alternative? Yes, when the goal is to own a team rather than rent one hosted engineer. Devin is a capable autonomous engineer running in Cognition's cloud; agent-swarm.dev is a self-hosted lead-plus-workers team where the memory and identities you accumulate stay yours and can move across models. ### Does agent-swarm.dev replace one autonomous engineer? It does more than replace one. Devin works a task end to end as a single session; agent-swarm.dev runs a lead that decomposes work and fans it across many parallel workers, so capacity scales past what one rented agent can hold — and the context compounds on your infra instead of living in a vendor product. ### Can a swarm do what Devin does? Yes, and it adds coordination a single session doesn't. A swarm plans, routes, and chains dependencies across workers, runs in your Slack, GitHub, Linear, and repos, and keeps memory and traces you own — while staying harness- and model-agnostic so the engine is replaceable compute. ## Sources - [Devin (Cognition)](https://devin.ai) - [Cognition](https://cognition.ai) - [agent-swarm.dev on GitHub](https://github.com/desplega-ai/agent-swarm) - [agent-swarm.dev docs](https://docs.agent-swarm.dev) --- # Manus vs agent-swarm.dev > Manus vs Agent Swarm: a hosted general AI agent you rent vs a self-hosted team you own with persistent memory on your infrastructure. Canonical URL: https://www.agent-swarm.dev/vs/manus Keywords: `Manus vs Agent Swarm`, `Manus alternative`, `agent swarm vs manus`, `self-hosted AI agent`, `owned vs rented AI agent`, `hosted AI agent alternative`, `multi-agent orchestration`, `AI agent swarm` ## TL;DR Manus is a capable general agent you rent in the cloud — hand it a task and it plans, browses, codes, and ships a deliverable on its own. agent-swarm.dev is a self-hosted team you own: a lead that fans work across many workers, with memory and identities that compound and stay yours. ## A generalist you rent. Or a swarm you own. | Dimension | Manus (Rented) | agent-swarm.dev (Owned) | |---|---|---| | Shape of work | One autonomous general agent takes a task and runs it end to end. | A lead decomposes the work and fans it across many parallel workers. | | Where it runs | Butterfly Effect's cloud sandbox — an isolated VM spun up per session. | Your infrastructure, containers, and keys. Free self-hosting under MIT, with enterprise support by agreement. | | The model | Claude plus a fine-tuned Qwen, orchestrated by the vendor — not your call. | Claude, Codex, opencode, pi — swap the engine per task. | | What persists | Context and outputs live inside the hosted product. | Memory, traces and agent identities you keep and version. | | What you pay for | A credit-based subscription you never keep. | Token capital — spend compounds into an owned asset. | ## Side-by-side comparison | Dimension | Manus | agent-swarm.dev | |---|---|---| | Orchestration | A single general agent works a task end to end. | A lead plans, routes, and chains dependencies across many workers. | | Where context lives | Inside Butterfly Effect's hosted cloud sandbox. | Your memory, journals and identity files, on your infra. | | Model choice | Vendor-orchestrated models (Claude + tuned Qwen); not your pick. | Harness- and model-agnostic; the model is replaceable compute. | | Deployment | Managed cloud sandbox, zero infra — no self-host. | Free self-hosting under MIT with Docker Compose. Enterprise support is available by agreement. | | Lives in your stack | Primarily its own web workspace, with Slack and email connectors. | Slack, GitHub, Linear, email, HTTP API — the tools work already happens in. | | Cost model | Credits burn per task by complexity, then reset each cycle. | Spend becomes a retained asset, not a recurring access fee. | | Who learns from your work | Your traces are exhaust the vendor's hosted agent improves on. | Your traces teach your own swarm — the next run starts smarter. | | Improvement signal | The vendor's roadmap moves the product. | Private evals on your workflows, on your definition of done. | ## The honest tradeoff Manus is genuinely impressive — one instruction turns into slides, a website, a research report or a working app with near-zero setup, and it's approachable for non-technical teams in a way a self-hosted swarm isn't. The trade is ownership: a rented generalist running in someone else's sandbox doesn't compound into your company's owned capacity, and one autonomous agent doesn't coordinate like a lead-plus-workers team. Rent the convenience. Own the loop. ## Proof by trying ### Try the team you'd actually own agent-swarm.dev is open source and deploys in minutes. Give it a real Slack, GitHub, or repo task for a day. The useful question isn't which model is best — it's what you can hand to a team that keeps the learning. - [Deploy agent-swarm.dev](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is agent-swarm.dev a Manus alternative? Yes, when the goal is to own the team rather than rent a hosted generalist. Manus is a managed agent that runs tasks in Butterfly Effect's cloud; agent-swarm.dev is a self-hosted swarm where a lead fans work across many workers and the memory, traces, and identities you accumulate stay yours. ### Can agent-swarm.dev do general agent tasks like Manus? It handles them as a team rather than a single generalist. Instead of one agent running a task end to end, a lead decomposes the work and routes it across parallel workers with dependencies — and the context lives in your memory and journals instead of a vendor's sandbox. ### What do I give up by self-hosting instead of renting Manus? Convenience. Manus turns one instruction into a finished deliverable with near-zero setup and is approachable for non-technical teams; a swarm is more to stand up. The trade is ownership — your spend compounds into an owned asset and your traces teach your own swarm instead of the vendor's. ## Sources - [Manus](https://manus.im) - [agent-swarm.dev on GitHub](https://github.com/desplega-ai/agent-swarm) - [agent-swarm.dev docs](https://docs.agent-swarm.dev) --- # OpenClaw vs agent-swarm.dev > Compare OpenClaw, an open-source, model-agnostic personal assistant, with Agent Swarm, a company team with shared memory, workers, and reviewers built in. Canonical URL: https://www.agent-swarm.dev/vs/openclaw Keywords: `OpenClaw vs Agent Swarm`, `OpenClaw alternative`, `open-source personal AI assistant`, `local-first AI agent`, `self-hosted AI team`, `model-agnostic AI agent`, `AI agent swarm` ## TL;DR OpenClaw and agent-swarm.dev are both open-source, model-agnostic, and yours — ownership isn't the argument. The difference is scope and shape: OpenClaw is one always-on assistant tuned to a person, while a swarm is a lead that fans work across many workers, with reviewers and institutional memory that compounds for the whole company. ## A personal assistant. Or a company's team. | Dimension | OpenClaw (Personal) | agent-swarm.dev (Company) | |---|---|---| | Shape of work | One always-on assistant by default. Multi-agent mode exists, but binds personas to channels and people. | A lead decomposes work and fans it across many parallel workers, with reviewers that challenge. | | Whose memory it is | Persistent memory on your machine, scoped to one persona — it learns you. | Institutional memory, journals and identities — queryable, versioned, shared across the team. | | Where it lives | Messaging-first: WhatsApp, Telegram, Discord, iMessage on your personal machine. | In the team's delivery tools — Slack, GitHub, Linear, email, API — on your infra. | | Control model | An autonomous companion with full system access; sandboxing is opt-in. | A human-led loop: workers execute in containers, reviewers challenge, least privilege by default. | | What it compounds into | A better assistant for one person. | Company capacity — private evals on your workflows; the next run starts smarter for everyone. | ## Side-by-side comparison | Dimension | OpenClaw | agent-swarm.dev | |---|---|---| | Shape of work | One deeply-configured assistant, always on. Optional multi-agent maps agents to channels and household members. | A lead plans, routes and chains dependencies across many parallel workers — built for delivery. | | Primary scope | Personal, founder-ops, household — an individual or a small team. | A company's software team — institutional scope, built to compound. | | Where context lives | Local persistent memory on your machine, scoped to the persona. | Memory, task journals and identity files — queryable and versioned, in shared infra. | | Primary surface | Messaging apps and your desktop (WhatsApp, Telegram, Discord, iMessage). | Slack, GitHub, Linear, email, HTTP API — where the team already works. | | Model choice | Bring your own key — Claude, GPT, Gemini, or local Ollama. Model-agnostic. | Also model-agnostic — Claude, Codex, opencode, pi — swap the engine per task. | | Control / governance | Autonomous and always-on, with full system access; sandbox is opt-in. | Human-led; workers run in containers, reviewers challenge, least privilege by default. | | Deployment | npm one-liner on your own machine — Mac, Windows or Linux. | Free self-hosting under MIT on your infrastructure with Docker Compose. Enterprise support is available by agreement. | | Improvement signal | A thriving community ships skills and plugins; it adapts to you. | Private evals on your workflows, on your definition of done — it adapts to the company. | ## The honest tradeoff OpenClaw is a genuine phenomenon — one of the fastest-growing open-source projects ever, delightful to use, local-first, model-agnostic, with persistent memory and a huge community shipping skills. As a personal assistant it's already owned in every way that matters to an individual, and it's hard to beat for that. The honest difference is shape and scope: OpenClaw centers on one always-on persona on a personal machine — even its multi-agent mode binds agents to channels and people, not a governed delivery pipeline. A swarm is built as a company's team: a lead that fans work across workers, reviewers that challenge, and memory that compounds for the whole org rather than one person. Want a personal assistant? Run the lobster. Want an owned team? Run a swarm. ## Proof by trying ### Try the team you'd actually own agent-swarm.dev is open source and deploys in minutes. Give it a real Slack, GitHub, or repo task for a day. The useful question isn't which model is best — it's what you can hand to a team that keeps the learning. - [Deploy agent-swarm.dev](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is agent-swarm.dev an OpenClaw alternative? Only in the sense that both are open-source and yours — neither rents you a model. OpenClaw is one always-on personal assistant; agent-swarm.dev is a company's team with a lead, workers, and reviewers. It's the alternative when you want a governed delivery team rather than a single assistant tuned to one person. ### Both are open-source and owned — what differs? Scope and shape, not ownership. OpenClaw centers one always-on persona on a personal machine, with memory that learns you. agent-swarm.dev is a lead that fans work across many parallel workers, reviewers that challenge, and institutional memory that's queryable, versioned, and shared across the whole team. ### Can OpenClaw be a team like a swarm? OpenClaw has a multi-agent mode, but it binds personas to channels and people rather than running a governed delivery pipeline with a lead, chained dependencies, and reviewers. agent-swarm.dev is built as a company's team from the start, so the work compounds for the org instead of one person. ## Sources - [“A frontier model is rented; a swarm is owned”](/blog/a-frontier-model-is-rented-a-swarm-is-owned) - [agent-swarm.dev on GitHub](https://github.com/desplega-ai/agent-swarm) - [agent-swarm.dev docs](https://docs.agent-swarm.dev) --- # Hermes vs agent-swarm.dev > Compare Hermes by Nous Research, an open, self-hosted, model-agnostic agent, with Agent Swarm's standing team of workers and shared institutional memory. Canonical URL: https://www.agent-swarm.dev/vs/hermes Keywords: `Hermes vs Agent Swarm`, `Nous Research Hermes agent`, `open-source self-improving agent`, `self-hosted AI team`, `AI agent swarm`, `model-agnostic agent`, `personal agent vs agent team` ## TL;DR Hermes and agent-swarm.dev share the same convictions — open, self-hosted, model-agnostic, with a self-improving loop that compounds instead of evaporating. Same principle, different bet: Hermes is one agent that builds a deepening model of you, while agent-swarm.dev is a standing team — a lead, many workers with distinct identities, and institutional memory owned by the whole company. ## One agent, one memory. Or a team that shares one. | Dimension | Hermes (One agent) | agent-swarm.dev (A team) | |---|---|---| | Shape of the system | One persistent agent. It can spawn isolated subagents for parallel pipelines, but they can't share state or cooperate — delegation, not a standing team. True multi-agent is on the roadmap. | A lead and many persistent workers with distinct identities that decompose, cooperate, and review each other's work — multi-agent today. | | Whose memory it is | One agent, one memory — a deepening model of you, growing with a single user. | Institutional memory, journals and identities — queryable, versioned, shared across the whole team. | | How it compounds | A self-improving loop that makes one assistant better for one person. | Private evals on your workflows — the next run starts smarter for everyone, on your definition of done. | | Where it lives | Messaging-first: Telegram, WhatsApp, Signal, Discord — reaching one person everywhere. | The team's delivery tools — Slack, GitHub, Linear, email, HTTP API — on your infra. | | The model | Open and model-agnostic — Hermes LLMs by default, or any OpenAI-compatible endpoint. | Also open and model-agnostic — Claude, Codex, opencode, pi; a Hermes model can even run under a worker. The model is swappable compute. | ## Side-by-side comparison | Dimension | Hermes | agent-swarm.dev | |---|---|---| | Shape of work | One agent works the task; isolated subagents handle parallel pipelines and report a summary back. | A lead plans and routes; many persistent workers execute in parallel and reviewers challenge the result. | | Coordination | Throwaway children via delegate_task — they can't share state or talk to each other (multi-agent is on the roadmap). | Standing workers that share context, chain dependencies, and cooperate — multi-agent today. | | Primary scope | A persistent personal agent — one user, every surface. | A company's software team — institutional scope, built to compound. | | Agent identity | One agent that grows with you; subagents are ephemeral and isolated. | Many durable identities (SOULs) — company veterans you keep, version and reassign. | | Where context lives | One memory that models a single user, carried across every chat surface. | Memory, task journals and identity files — queryable and versioned, shared in your infra. | | Model choice | Open, model-agnostic — Hermes LLMs or any OpenAI-compatible endpoint. | Also model-agnostic — Claude, Codex, opencode, pi — swap the engine per task. | | Control / governance | An autonomous personal agent that acts on its own, with hardened sandboxes (local, Docker, SSH, Modal). | A human-led loop — a lead directs, workers execute in containers, reviewers challenge. | | Deployment | Desktop app (Mac, Windows, Linux) or install on your own server via the gateway. | Free self-hosting under MIT on your infrastructure with Docker Compose. Enterprise support is available by agreement. | ## The honest tradeoff Hermes is genuinely excellent, and it shares our deepest convictions — open under MIT, self-hosted, model-agnostic, with a self-improving loop that turns experience into skills instead of letting it evaporate. Nous Research has built one of the most thoughtful agents in the open ecosystem, and a true multi-agent architecture with specialized roles is openly on their roadmap. If you want one capable agent that grows with you across every messaging app, it's a beautiful fit and lighter to run. A swarm is heavier and aimed elsewhere: not a personal assistant but an owned organization — a lead and many specialized workers, reviewers that challenge, and institutional memory that compounds for the whole company rather than one person. Same principle, different bet. And because both are open and model-agnostic, you could even run a Hermes model inside a swarm worker. The model is the tool. The swarm is the system you build around it. ## Proof by trying ### Try the team you'd actually own agent-swarm.dev is open source and deploys in minutes. Give it a real Slack, GitHub, or repo task for a day. The useful question isn't which model is best — it's what you can hand to a team that keeps the learning. - [Deploy agent-swarm.dev](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is agent-swarm.dev a Hermes alternative? It can be, when the goal is a standing team rather than one personal agent. Both are open, self-hosted, and model-agnostic — we agree on ownership. The honest difference is shape: Hermes is one agent that grows a deepening model of you, while agent-swarm.dev is a lead plus many workers with distinct identities that share one institutional memory. ### Both are open and self-hosted — what differs? Ownership isn't the dividing line; we agree on it. What differs is scope and shape. Hermes is one persistent agent with one memory, optimized for a single user across every messaging surface. agent-swarm.dev is a standing organization — workers that decompose and cooperate, reviewers that challenge, and institutional memory shared across the whole team. ### Can I run a Hermes model inside a swarm? Yes. Both are model-agnostic, so a Hermes LLM can run as the engine behind a swarm worker, alongside Claude, Codex, opencode, or pi. The model is swappable compute; the swarm is the system you build around it. ## Sources - [Nous Research](https://nousresearch.com) - [“A frontier model is rented; a swarm is owned”](/blog/a-frontier-model-is-rented-a-swarm-is-owned) - [agent-swarm.dev on GitHub](https://github.com/desplega-ai/agent-swarm) - [agent-swarm.dev docs](https://docs.agent-swarm.dev) --- # Cloudflare OS vs agent-swarm.dev > Cloudflare OS is a secure AI productivity workspace for people and their apps. Agent Swarm is a team of specialized agents coordinating company delivery. Canonical URL: https://www.agent-swarm.dev/vs/cloudflare-os Keywords: `Cloudflare OS vs Agent Swarm`, `Cloudflare OS alternative`, `open-source AI productivity environment`, `company AI operating system`, `multi-agent orchestration`, `self-hosted agent team`, `AI agent security`, `Cloudflare Gatekeepers` ## TL;DR Cloudflare OS and agent-swarm.dev are both open source, self-hostable, and designed around company context. The difference is the operating shape: Cloudflare OS gives each person an agent workspace for tasks and sandboxed Gadgets, protected by capability-based Gatekeepers. agent-swarm.dev runs a lead and specialized workers that route tasks, chain dependencies, review results, and build shared institutional memory. ## An AI productivity workspace. Or an operating agent team. | Dimension | Cloudflare OS (Workspace) | agent-swarm.dev (Team) | |---|---|---| | Unit of work | A person asks an agent to perform a task or build a sandboxed Gadget. | A lead decomposes an outcome and routes dependent tasks across specialized workers. | | Coordination | Workspaces and Gadgets are private by default and can be shared for real-time collaboration. | Workers message, hand off, resume parent-child work, and review one another inside a delivery pipeline. | | Security boundary | Gatekeepers grant narrow resource capabilities, log actions, and queue side effects for approval. | Agent containers, scoped connections, lead-gated actions, and review loops bound autonomous work. | | What persists | Personal workspaces, Gadgets, Blueprints, and company-specific agent context. | Task history, shared memory, durable agent identities, and workflow-specific operating knowledge. | | What it compounds into | Safer, personalized software and productivity for each person. | Reusable company capacity: specialized workers that improve across repeated delivery work. | ## Side-by-side comparison | Dimension | Cloudflare OS | agent-swarm.dev | |---|---|---| | Primary product | An AI productivity environment with agent chat, sandboxed Gadgets, and Gatekeepers. | A persistent operating swarm with a lead, specialized workers, task routing, and review loops. | | Shape of work | People ask a general-purpose agent to do tasks or create personal applications. | A lead decomposes company outcomes and coordinates many workers through a shared task system. | | Collaboration | Share Gadgets and collaborate inside real-time, per-app workspaces. | Share work across persistent agents through dependencies, messages, handoffs, and reviewers. | | Application model | AI builds isolated, modifiable Gadgets; Blueprints let others create their own copy. | Agents work directly in existing repositories, services, and team delivery systems. | | Security model | Capability-based Gatekeepers restrict resources, audit actions, and support asynchronous approval. | Isolated agent runtimes, permission gates, credential boundaries, and human or agent review. | | Runtime | Built on Workers, Durable Objects, and Dynamic Workers; local workerd is available for evaluation. | Ubuntu agent containers with full developer tooling, plus isolated sandboxes where needed. | | Model choice | Supports major model providers and self-hosted models through a built-in Code Mode agent. | Supports multiple agent harnesses — Claude Code, Codex, opencode, and pi — selected per worker or task. | | Deployment maturity | August 2026 v2 is explicitly early access; deploy to Cloudflare or evaluate locally. | Self-host for free under MIT with Docker Compose. Enterprise support is available by agreement. | ## The honest tradeoff Cloudflare OS has a thoughtful security architecture. Gatekeepers narrow each agent or Gadget to explicitly introduced resources, log actions, and let people approve simulated side effects after the agent finishes. Its Gadget and Blueprint model is also a strong fit when the goal is safe, personalized internal software. The project labels its August 2026 v2 release early access, and its center of gravity is the individual AI workspace rather than cross-agent delivery orchestration. agent-swarm.dev is heavier because it operates a standing organization of agents, but that is the point when work must be decomposed, routed, reviewed, and remembered across the whole company. ## Proof by trying ### Try the team you'd actually own agent-swarm.dev is open source and deploys in minutes. Give it a real Slack, GitHub, or repo task for a day. The useful question isn't which model is best — it's what you can hand to a team that keeps the learning. - [Deploy agent-swarm.dev](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is agent-swarm.dev a Cloudflare OS alternative? Yes, when the outcome is an operating agent team rather than an AI productivity workspace. Both are open source and adaptable to company context. Cloudflare OS focuses on agent chat, safe Gadget creation, and capability-based access; agent-swarm.dev focuses on coordinated delivery across a lead, specialized workers, dependencies, and reviewers. ### Both are company agent operating systems — what differs? Their unit of value differs. Cloudflare OS gives each person a secure workspace where an agent performs tasks and builds shareable applications. agent-swarm.dev gives the company a standing team that decomposes outcomes, routes work across persistent agents, and accumulates shared operating knowledge. ### Which has the stronger security model? Cloudflare OS makes capability-based security a first-class product concept: Gatekeepers restrict resource access, log actions, and queue side effects for later approval. agent-swarm.dev uses isolated runtimes, scoped connections, lead-gated operations, and review loops. The better fit depends on whether your primary risk boundary is user-built applications or autonomous delivery work. ## Sources - [Cloudflare OS GitHub](https://github.com/cloudflare/cloudflare-os) - [Introducing Cloudflare OS](https://blog.cloudflare.com/cloudflare-os/) - [Cloudflare OS deploy](https://os.cloudflare.app/deploy) - [agent-swarm.dev on GitHub](https://github.com/desplega-ai/agent-swarm) - [agent-swarm.dev docs](https://docs.agent-swarm.dev) --- # QM vs agent-swarm.dev > QM gives every employee and room an isolated agent workspace. Agent Swarm runs specialized agents as one delivery team with shared tasks and review loops. Canonical URL: https://www.agent-swarm.dev/vs/qm Keywords: `QM vs Agent Swarm`, `YC QM alternative`, `quartermaster agent harness`, `multiplayer agent harness`, `open-source company agents`, `Slack AI agent`, `multi-agent orchestration`, `self-hosted agent swarm` ## TL;DR QM and agent-swarm.dev overlap deeply: both are open source, self-hosted, Slack-native, multi-harness systems with durable sandboxes, memory, schedules, and company controls. The difference is coordination. QM gives each person and room its own scoped agent workspace; agent-swarm.dev gives the company a lead and specialized workers that share a task system, chain dependencies, hand work off, and review one another. ## A fleet of scoped agents. Or a coordinated swarm. | Dimension | QM (Scoped) | agent-swarm.dev (Coordinated) | |---|---|---| | Organizational unit | Each employee and each room gets an isolated workspace with its own agent state. | Each worker has a durable specialty and identity inside one coordinated operating team. | | How work moves | People work independently in personal scopes or collaborate with an agent in shared rooms. | A lead decomposes outcomes; dependencies, messages, and parent-child tasks move work between agents. | | Memory boundary | Memory, files, permissions, crons, apps, and sandboxes are scoped to a person or room. | Workers keep distinct identities while searchable institutional memory is reusable across the swarm. | | Governance | One org security posture controls approvals, provenance screening, and command policy. | Lead-gated actions, scoped tools, isolated runtimes, and review agents govern delivery work. | | What it compounds into | A useful company fleet of personal and shared agent workspaces. | A delivery organization whose specialists and operating knowledge improve together. | ## Side-by-side comparison | Dimension | QM | agent-swarm.dev | |---|---|---| | Primary product | A multiplayer agent harness with personal and shared workspaces in Slack and on the web. | A persistent agent organization with lead routing, specialized workers, and review loops. | | Agent topology | An isolated workspace for each employee and room, each with scoped state and permissions. | A lead plus durable specialized workers that cooperate across one task and dependency graph. | | Coordination | Humans collaborate with an agent in channels, group messages, and projects. | Agents delegate, message, resume parent-child tasks, wait on dependencies, and review results. | | Persistent context | Per-person and per-room memory, files, keychain view, permissions, crons, apps, and sandbox. | Per-agent identities plus shared semantic memory, task history, journals, and reusable workflows. | | Background work | Crons and watches run work while nobody is watching. | Schedules, heartbeats, durable workflows, and delegated child tasks run recurring or long work. | | Security posture | Strict, Auto, or Dangerous org posture, with mandatory command policy and provenance screening in Auto. | Scoped capabilities, agent containers, approval walls, and human or agent review around consequential work. | | Harness choice | Pi, OpenCode, Codex, and Claude Code drive the same core. | Claude Code, Codex, opencode, and pi can be assigned by worker or routed per task. | | Deployment | Deploy an organization-owned package to Fly.io or AWS in the operator's cloud account. | Self-host for free under MIT with Docker Compose. Enterprise support is available by agreement. | ## The honest tradeoff QM is one of the closest open-source comparisons to agent-swarm.dev. It already offers durable per-scope computers, Slack and web continuity, memory, crons, shared skills, internal apps, multiple harnesses, and unusually explicit organization-level security postures. Its isolation model is attractive when every employee or project needs an independent agent that cannot disturb another scope. agent-swarm.dev takes on more coordination machinery because it optimizes for a different outcome: durable specialists operating as one delivery organization, with lead routing, cross-agent handoffs, task dependencies, and reviewers built into the work graph. ## Proof by trying ### Try the team you'd actually own agent-swarm.dev is open source and deploys in minutes. Give it a real Slack, GitHub, or repo task for a day. The useful question isn't which model is best — it's what you can hand to a team that keeps the learning. - [Deploy agent-swarm.dev](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is agent-swarm.dev a QM alternative? Yes. They solve much of the same company-agent infrastructure problem and share open-source, self-hosted, Slack-native, multi-harness foundations. Choose between them based on topology: QM centers isolated agents for people and rooms; agent-swarm.dev centers a coordinated lead-and-workers organization. ### What is the main difference between QM and agent-swarm.dev? QM scopes a complete workspace — memory, files, permissions, crons, apps, and sandbox — to each person or room. agent-swarm.dev scopes durable identities to specialized workers, then connects their work through lead routing, dependencies, messages, handoffs, and review. ### Do both support multiple agent harnesses? Yes. QM lists Pi, OpenCode, Codex, and Claude Code over one core. agent-swarm.dev supports Claude Code, Codex, opencode, and pi, with routing that can select a harness or model for a worker or task. Neither requires one model vendor. ## Sources - [QM by Y Combinator](https://qm.ycombinator.com) - [QM GitHub](https://github.com/yc-software/qm) - [QM security model](https://github.com/yc-software/qm/blob/main/SECURITY.md) - [QM deployment guide](https://github.com/yc-software/qm/blob/main/deployment.md) - [agent-swarm.dev on GitHub](https://github.com/desplega-ai/agent-swarm) - [agent-swarm.dev docs](https://docs.agent-swarm.dev) --- # LangGraph vs Agent Swarm > Compare LangGraph, a low-level framework for building stateful agents, with Agent Swarm, an operating system for AI work you self-host under MIT. Canonical URL: https://www.agent-swarm.dev/vs/langgraph Keywords: `LangGraph vs Agent Swarm`, `LangGraph alternative`, `Agent Swarm vs LangGraph`, `stateful agent framework`, `low-level agent orchestration`, `LangSmith Deployment alternative`, `self-hosted agent swarm`, `AI company operating system` ## TL;DR LangGraph is a low-level orchestration framework for building stateful agents in Python or TypeScript. Agent Swarm is an open-source operating system for AI work: a lead agent delegates goals to workers such as Claude Code or Codex, with isolated containers, shared memory, and review gates. The key difference is build versus run: LangGraph gives you primitives to code your own agent system, while Agent Swarm is a running system you hand work to. Choose LangGraph when your product needs bespoke agent logic in code. Choose Agent Swarm when you want a standing AI team that remembers prior work, runs recurring tasks on a schedule, and self-hosts free under MIT. ## What is the category difference? LangGraph is a low-level orchestration framework you build stateful agents with. agent-swarm.dev is an open-source operating system for AI work: a standing team of agents you run on your own infrastructure. The practical difference is build-with framework vs run-the-team operating product. ## When should I choose LangGraph? ### You are building bespoke agent logic into a product LangGraph is a Python and TypeScript library (MIT) that you embed in your own application. It does not abstract prompts or architecture, and you can always understand what your agent will do next by looking at the current node. When the deliverable is code you own, a framework is the right shape. ### You need explicit, code-first control flow LangGraph lets you mix deterministic, hand-coded steps with LLM-driven agentic steps in the same graph. Teams with complex tasks bespoke to their needs get precise control over orchestration that higher-level tools hide. ### You want framework primitives for durability and human-in-the-loop LangGraph ships durable execution for long-running agents, interrupts for human-in-the-loop, and short-term working memory plus long-term persistent memory as library features. If you are prepared to operate the deployment around them, the primitives are strong. ## When should I choose agent-swarm.dev? ### You want a team, not another framework project Agent Swarm is already an operating system for work: a lead agent receives tasks from Slack, repositories, issue trackers, email, or the API, then delegates to workers with priority queues, dependencies, and progress reporting. You assign goals instead of designing graphs. ### Memory and skills should compound across sessions Agent Swarm keeps persistent memory and identity for every agent, with a reusable skill system and a shared searchable filesystem. The swarm recalls prior decisions and failed approaches instead of starting cold on each run. ### Recurring work should run itself on infrastructure you control Schedules, DAG workflows, and human-in-the-loop approval nodes are built in. Agent Swarm self-hosts free under MIT with Docker Compose or Helm, with no license fee and no enforced worker cap, and workers run Claude Code, Codex, opencode, pi-mono, Devin, or ACP-compatible agents. ## Side-by-side comparison | Dimension | LangGraph | agent-swarm.dev | |---|---|---| | Category | Low-level orchestration framework and runtime for building, managing, and deploying long-running, stateful agents. | Open-source operating system for AI work: a lead agent plus coordinated workers with shared memory. | | Primary user | Developers writing agent logic in Python or TypeScript. | Companies that want coding, research, review, and operational work to run continuously. | | Operating model | You design graphs, nodes, edges, and state, wire in persistence, and operate the deployment yourself. | You assign work; the lead routes it to workers with dependencies, review gates, and progress reporting. | | Memory | Framework primitives: short-term working memory and long-term persistent memory that you wire into your graph. | Persistent memory and identity shared across the swarm, compounding over every session. | | Recurring work | Durable execution keeps long-running agents alive; scheduling, follow-ups, and recurring jobs are yours to build. | Scheduled tasks (cron, interval, or delayed) and DAG workflows with triggers and fan-out are first-class features. | | Deployment | The library is MIT; running the Agent Server in production needs a license key, and full self-hosting of production workloads requires an Enterprise license (as of 2026-10-02). | Self-host free under MIT with Docker Compose or Helm on Kubernetes; air-gapped if you need it. | | Pricing (as of 2026-10-02) | LangSmith plans: Developer free (1 seat, no deployment), Plus $39/seat/mo with one serverless deployment included, Enterprise custom with self-hosted and hybrid options. | Free self-hosted software under MIT. Enterprise support is available by conversation, with services and pricing agreed for your needs. | | Adoption (as of 2026-10-02) | 42,630 GitHub stars; its docs name Klarna, Uber, and J.P. Morgan as users. | 881 GitHub stars as of 2026-10-13; Capchase has 80% of its team onboarded and over 800 human-initiated tasks weekly. | | Best short version | Build a stateful agent system in code. | Run a team of agents that does the work. | ## Where agent-swarm.dev is still catching up ### LangGraph is better when the deliverable is code, not operations If you are shipping an agent inside your own product, an MIT library you embed is the right tool. Agent Swarm is an operated system, not an SDK; it does not replace framework code in your application. ### LangGraph's ecosystem and tooling are far more mature As of 2026-10-02, LangGraph has 42,630 GitHub stars against Agent Swarm's 881 as of 2026-10-13, plus LangSmith Studio, a dedicated IDE for visualizing and debugging agents. Agent Swarm is the younger project by a wide margin. ## Proof by trying ### Run the swarm before you commit to building the graph Agent Swarm is open source under MIT and the fastest way to judge it is a real task. The bunx @desplega.ai/agent-swarm onboard wizard collects credentials, generates the compose files, starts the stack, and verifies health. Hand the swarm a job from Slack or GitHub and compare that with scaffolding the same job as a LangGraph graph. - [Deploy Agent Swarm](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is Agent Swarm a LangGraph alternative? LangGraph is a low-level framework for building stateful agents in code; Agent Swarm is an open-source operating system for AI work that you run as a standing team. They answer different needs: pick LangGraph to build an agent system, pick Agent Swarm to have one already running. If your goal is a working AI team rather than an agent codebase, Agent Swarm replaces the build-it-yourself path. ### Is LangGraph free to self-host? The langgraph library is MIT-licensed and free to use. The Agent Server package (langgraph-api) is source-available under Elastic-2.0, not an OSI license: running it in production needs a license key, and LangChain staff state that full self-hosting of production workloads requires an Enterprise license (as of 2026-10-02). Agent Swarm self-hosts free under MIT with no license fee. ### Can LangGraph and Agent Swarm coexist? Yes. A product team can ship agent features built with LangGraph while Agent Swarm runs the company's operations around it: coding, research, review, and recurring reports arriving from Slack, GitHub, Linear, or email. Agent Swarm's workers run Claude Code, Codex, and other harnesses; it does not ask you to rewrite application code. ### When should I choose LangGraph over Agent Swarm? Choose LangGraph when you need to write and own bespoke agent logic in Python or TypeScript, with explicit control over every step. Choose Agent Swarm when you want persistent workers, shared memory, schedules, and review loops already running on infrastructure you control. ## Sources - [LangGraph GitHub (README)](https://github.com/langchain-ai/langgraph) - [LangGraph docs overview](https://docs.langchain.com/oss/python/langgraph/overview) - [LangGraph product page](https://www.langchain.com/langgraph) - [LangSmith Deployment docs](https://docs.langchain.com/langsmith/deployment) - [LangSmith plans and pricing](https://www.langchain.com/pricing) - [langgraph-api on PyPI (Elastic-2.0)](https://pypi.org/project/langgraph-api/) - [Agent Swarm GitHub](https://github.com/desplega-ai/agent-swarm) - [Agent Swarm homepage](https://www.agent-swarm.dev) - [Agent Swarm pricing](https://www.agent-swarm.dev/pricing) - [Agent Swarm docs](https://docs.agent-swarm.dev/docs) --- # Dify vs Agent Swarm > Compare Dify, a platform for building agentic apps on a visual canvas, with Agent Swarm, an operating system for AI work you self-host under MIT. Canonical URL: https://www.agent-swarm.dev/vs/dify Keywords: `Dify vs Agent Swarm`, `Dify alternative`, `Agent Swarm vs Dify`, `agentic workflow platform`, `visual AI app builder alternative`, `self-hosted agent platform`, `open-source RAG platform alternative`, `AI company operating system` ## TL;DR Dify is an open-source platform for building AI applications: agents, agentic workflows, and chatbots that draw on your own data, assembled on a drag-and-drop canvas and published as web apps or APIs. Agent Swarm is an open-source operating system for AI work: a lead agent delegates goals to workers such as Claude Code or Codex, with isolated containers, shared memory, and review gates. The key difference is that Dify helps your team build AI apps, while Agent Swarm is a standing AI team that does work for you. Choose Dify when you want a visual app builder with an LLM backend. Choose Agent Swarm when you want agents that take tasks, remember prior work, and run recurring jobs on infrastructure you control. ## What is the category difference? Dify is an open-source platform you build agent apps, workflows, and RAG chatbots with. agent-swarm.dev is an open-source operating system for AI work: a standing team of agents you run on your own infrastructure. The practical difference is build-with framework vs run-the-team operating product. ## When should I choose Dify? ### Non-developers and mixed teams need to build visually Dify's Studio is a drag-and-drop canvas designed for developers, non-technical personnel, and businesses. Lion Corporation trained 100 business users to build AI agents with it. When the builders are not engineers, Dify is purpose-built for that. ### You are shipping RAG chatbots and knowledge apps Dify covers everything from document ingestion to retrieval out of the box, with text extraction from PDFs, PPTs, and other common formats, plus a Knowledge Pipeline that turns raw data into searchable knowledge bases. ### You want an LLM app backend with APIs per app Everything built in Dify comes with corresponding APIs, so you can integrate it into your own business logic, publish apps as web apps, or expose them as MCP servers. Teams can move from prototype to production without rebuilding the stack. ## When should I choose agent-swarm.dev? ### You want work done, not another app to build Agent Swarm is a standing team: a lead agent receives goals from Slack, repositories, issue trackers, email, or the API, and delegates them to workers in isolated containers with review gates. The output is completed work, not an app you still have to operate. ### Context should accumulate across every session Agent Swarm gives every agent persistent memory and identity, a shared searchable filesystem, and a skill system for reusable procedural knowledge. The swarm gets smarter over time instead of starting cold. ### Recurring operations should run unattended Scheduled tasks, DAG workflows with triggers and fan-out, and human-in-the-loop approval nodes are built in. Agent Swarm self-hosts free under MIT with Docker Compose or Helm, on infrastructure and model keys that you control. ## Side-by-side comparison | Dimension | Dify | agent-swarm.dev | |---|---|---| | Category | Open-source platform for building agentic workflows, RAG pipelines, and chatbots on one collaborative workspace. | Open-source operating system for AI work: a lead agent plus coordinated workers with shared memory. | | Primary user | Developers and non-technical teams assembling AI applications. | Companies that want an agent team to execute coding, research, review, and ops work continuously. | | Operating model | You design workflows, agents, and knowledge pipelines in a visual Studio, then publish and operate the apps. | You assign goals; the lead routes them to workers with dependencies, review gates, and progress reporting. | | Output | Published web apps, APIs, and MCP servers. | Completed tasks: code, research, reviews, reports, and operational actions. | | Models | Hundreds of proprietary and open-source LLMs from dozens of inference providers and self-hosted solutions. | LLM-agnostic workers: Claude (via Anthropic or AWS Bedrock), OpenAI, Gemini, and any OpenRouter-compatible model. | | Self-hosting | Community Edition runs on Docker Compose (minimum 2-core CPU, 4 GiB RAM, as of 2026-10-02) and is limited to a single workspace. | Self-host with Docker Compose or Helm on Kubernetes; air-gapped if you need it, with no enforced worker cap. | | License | Modified Apache-2.0: no operating a multi-tenant service and no removing Dify's frontend logo or copyright without a commercial license. | MIT with no additional conditions; no license fee. | | Pricing (as of 2026-10-02) | Cloud: free Sandbox, Professional $59/mo, Team $159/mo, Enterprise custom. Self-hosted Community Edition is free for a single workspace. | Free self-hosted software under MIT. Enterprise support is available by conversation, with services and pricing agreed for your needs. | | Adoption (as of 2026-10-02) | 157,730 GitHub stars; its homepage names Maersk, Adobe, Panasonic, PayPal, Novartis, and Deloitte. | 881 GitHub stars as of 2026-10-13; Capchase has 80% of its team onboarded and over 800 human-initiated tasks weekly. | | Best short version | Build and publish an AI app. | Run a team of agents that does the work. | ## Where agent-swarm.dev is still catching up ### Dify is better when the builders are not engineers The drag-and-drop Studio, plugin marketplace, and per-app APIs are built for mixed teams that need to ship AI apps without writing orchestration code. Agent Swarm assumes you want agents doing knowledge work, not a visual app builder. ### Dify's RAG tooling is more complete out of the box Document ingestion, text extraction from PDFs and PPTs, and knowledge pipelines are core Dify features. Agent Swarm's strength is coordinated work with compounding memory, not document retrieval pipelines. ## Proof by trying ### Hand work to a swarm before you build another app Agent Swarm is open source under MIT and self-hosts with Docker Compose. The bunx @desplega.ai/agent-swarm onboard wizard collects credentials, generates the compose files, starts the stack, and verifies health. Give the swarm a real task from Slack or GitHub and compare the result with wiring the same job into a Dify workflow. - [Deploy Agent Swarm](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is Agent Swarm a Dify alternative? Dify is an open-source platform for building AI applications on a visual canvas; Agent Swarm is an open-source operating system for AI work, a standing team of agents you assign goals to. Pick Dify to build and publish AI apps; pick Agent Swarm to have agents do ongoing work. If the outcome you want is completed tasks rather than a published app, Agent Swarm is the direct fit. ### Is Dify's self-hosted edition free for commercial use? Yes for a single workspace, but with conditions. Dify's Community Edition is free under a modified Apache-2.0 license that forbids operating a multi-tenant service and forbids removing or modifying the Dify logo and copyright in its frontend without a commercial license from LangGenius (as of 2026-10-02). Agent Swarm is plain MIT with no such conditions. ### Can Dify and Agent Swarm coexist? Yes. Build customer-facing AI apps in Dify while Agent Swarm runs internal operations around them: coding, research, review, and recurring reports, with work arriving from Slack, GitHub, Linear, or email. ### When should I choose Dify over Agent Swarm? Choose Dify when non-developers need to build AI apps visually, when you need RAG over your own documents with per-app APIs, or when you want to expose those apps as MCP servers. Choose Agent Swarm when you want a persistent agent team with shared memory, schedules, and review gates doing the work itself. ## Sources - [Dify GitHub (README)](https://github.com/langgenius/dify) - [Dify homepage](https://dify.ai/) - [Dify docs introduction](https://docs.dify.ai/en/introduction) - [Dify key concepts](https://docs.dify.ai/en/use-dify/getting-started/key-concepts) - [Dify pricing](https://dify.ai/pricing) - [Dify LICENSE](https://github.com/langgenius/dify/blob/main/LICENSE) - [Dify Enterprise](https://dify.ai/dify-enterprise) - [Agent Swarm GitHub](https://github.com/desplega-ai/agent-swarm) - [Agent Swarm homepage](https://www.agent-swarm.dev) - [Agent Swarm pricing](https://www.agent-swarm.dev/pricing) - [Agent Swarm docs](https://docs.agent-swarm.dev/docs) --- # OpenAI Swarm vs Agent Swarm > OpenAI Swarm is an educational library replaced by the Agents SDK. Agent Swarm is Desplega Labs' open-source, self-hosted AI company operating system. Canonical URL: https://www.agent-swarm.dev/vs/openai-swarm Keywords: `OpenAI Swarm vs Agent Swarm`, `OpenAI Swarm replacement`, `is OpenAI Swarm deprecated`, `Swarms vs Agency Swarm`, `agent swarm name confusion`, `self-hosted agent swarm`, `AI company operating system` ## TL;DR OpenAI Swarm is OpenAI's experimental educational library for learning multi-agent orchestration; it has been replaced by the OpenAI Agents SDK, which OpenAI recommends for all production use cases. Agent Swarm is a different product entirely: an open-source, self-hosted AI company operating system built by Desplega Labs, where a lead agent delegates goals to workers such as Claude Code or Codex, with shared memory, tools, schedules, and review gates across sessions. If you want to learn orchestration or embed agents in your own app, start with the Agents SDK. If you want a standing team of agents running your company's work, run Agent Swarm. [OpenAI Agents SDK vs Agent Swarm](https://www.agent-swarm.dev/vs/openai-agents-sdk) — OpenAI's production-ready framework for building agentic apps in Python or TypeScript. ## What is the category difference? OpenAI Swarm is an experimental educational multi-agent library, replaced by the OpenAI Agents SDK. agent-swarm.dev is an open-source, self-hosted AI company operating system. The practical difference is build-with framework vs run-the-team operating product. ## When should I choose OpenAI Swarm? ### You are learning how multi-agent orchestration works OpenAI built Swarm as an educational resource for developers curious about multi-agent orchestration, and pairs it with a cookbook walkthrough of routines and handoffs. For anything beyond learning, OpenAI recommends migrating to the Agents SDK for all production use cases. ### You do not want a server to run Swarm runs almost entirely on the client and does not store state between calls, and the Agents SDK is a pip or npm package. Agent Swarm is a running system: an API plus workers in isolated Docker containers. ### You are embedding agents inside your own application The OpenAI Agents SDK is a lightweight package for building multi-agent workflows inside your Python or JavaScript/TypeScript codebase, with Cloudflare Workers support for serverless and edge deployments. That is framework work, and the SDK is purpose-built for it. ### You need voice, realtime, or OpenAI-native tracing The Agents SDK ships realtime and voice agents, plus built-in tracing connected to OpenAI's evaluation, fine-tuning, and distillation tools. If those are the requirements, OpenAI's own framework is the direct path. ## When should I choose agent-swarm.dev? ### You want a team, not a library Agent Swarm is an operating system for AI work: a lead agent receives work from Slack, repositories, issue trackers, email, or the API, and delegates goals to specialized workers. You assign outcomes, not orchestration code. ### Memory needs to compound Isolated containers, shared memory, tools, schedules, and review gates preserve work across sessions, so the swarm builds on what it has already done instead of starting cold. ### Recurring work should run by itself Schedules are built in, so follow-ups, checks, and reports run on a cadence without someone kicking off each run. ### You want to own the infrastructure Agent Swarm is open source under the MIT License and self-hosted: you pay for the infrastructure and inference providers you choose. Enterprise support is available by conversation, with services and scope agreed separately. ## Side-by-side comparison | Dimension | OpenAI Swarm | agent-swarm.dev | |---|---|---| | Category | Experimental educational library for learning multi-agent orchestration. | Open-source, self-hosted AI company operating system. | | Status | Replaced by the OpenAI Agents SDK; OpenAI recommends migrating for all production use cases. | Actively built by Desplega Labs, S.L.; free self-hosting under MIT, with enterprise support available by conversation. | | What you install | A Python library (3.10+) installed from GitHub; no releases on PyPI. | A running system: an API plus workers in isolated Docker containers, via docker compose or the OCI Helm chart for Kubernetes. | | State and memory | Stateless by design: much like the Chat Completions API, it does not store state between calls. | Shared memory, tools, schedules, and review gates preserve work across sessions. | | Where it runs | Inside your Python process; the Agents SDK successor also runs in JavaScript/TypeScript and on Cloudflare Workers. | On infrastructure you control: free self-hosting under MIT, with enterprise support available by conversation. | | Primary user | Developers learning how routines and handoffs work. | Teams handing real work from Slack, repositories, issue trackers, email, or the API to a standing team of agents. | | Models and runtimes | Built around the Chat Completions API; the Agents SDK is provider-agnostic with 100+ LLMs. | Your choice of harness and models: Claude Code, Codex, pi, opencode, Devin, or ACP agents. | | Best short version | Learn how agent orchestration works. | Run an agent team. | ## Where agent-swarm.dev is still catching up ### OpenAI's tools are better when the agents live inside your code If the outcome you want is agent logic embedded in your own Python or TypeScript application — especially serverless, realtime, or voice — the OpenAI Agents SDK is the production-ready, actively maintained framework OpenAI built for exactly that, and Swarm's cookbook remains a gentle way to learn the concepts. ## Proof by trying ### Try the company operating system before you pick a framework Agent Swarm is open source under MIT and self-hosted: docker compose up, then hand it a real task from Slack, a repository, an issue tracker, email, or the API. Judge it against any framework on the same piece of work. - [Deploy Agent Swarm](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is Agent Swarm the same thing as OpenAI Swarm? No. OpenAI Swarm is an experimental educational library from OpenAI, now replaced by the OpenAI Agents SDK, which OpenAI recommends for all production use cases. Agent Swarm is an open-source, self-hosted AI company operating system built by Desplega Labs: a lead agent delegates goals to workers such as Claude Code or Codex, with shared memory, tools, schedules, and review gates across sessions. The key difference: OpenAI Swarm is a library you learn from; Agent Swarm is a system you run your company's work on. ### Is OpenAI Swarm still maintained? OpenAI's README states that Swarm is now replaced by the OpenAI Agents SDK and recommends migrating for all production use cases. The README's last status update was on March 11, 2025, pointing readers to the Agents SDK; the repository has no releases, and its most recent commit, on April 15, 2026, is tooling-only. ### What replaced OpenAI Swarm? The OpenAI Agents SDK, which OpenAI describes as a production-ready evolution of Swarm. It is available for Python and for JavaScript/TypeScript, is provider-agnostic across OpenAI APIs and 100+ other LLMs, and is MIT-licensed. ### Are Swarms or Agency Swarm related to OpenAI Swarm — or to Agent Swarm? No. Swarms (kyegomez/swarms) is a third-party, Apache-2.0 enterprise multi-agent framework; its README states no relation to OpenAI. Agency Swarm (VRSEN) is a third-party, MIT-licensed framework built on top of the OpenAI Agents SDK. Neither is an OpenAI project, and neither is Agent Swarm. ### Does Agent Swarm work with OpenAI models? Yes. Agent Swarm gives you your choice of harness and models: Claude Code, Codex, pi, opencode, Devin, or ACP agents can run as workers, and the docs describe Codex as OpenAI's coding agent with support for both API keys and ChatGPT OAuth. ## Related comparisons - [OpenAI Agents SDK vs Agent Swarm](https://www.agent-swarm.dev/vs/openai-agents-sdk) ## Sources - [OpenAI Swarm repo](https://github.com/openai/swarm) - [OpenAI cookbook: Orchestrating Agents](https://cookbook.openai.com/examples/orchestrating_agents) - [OpenAI Agents SDK (Python) docs](https://openai.github.io/openai-agents-python/) - [OpenAI Agents SDK (Python) repo](https://github.com/openai/openai-agents-python) - [OpenAI Agents SDK (JS/TS) repo](https://github.com/openai/openai-agents-js) - [Swarms repo (kyegomez)](https://github.com/kyegomez/swarms) - [Agency Swarm repo (VRSEN)](https://github.com/VRSEN/agency-swarm) - [Agency Swarm docs](https://agency-swarm.ai/) - [Agent Swarm repo](https://github.com/desplega-ai/agent-swarm) - [Agent Swarm docs](https://docs.agent-swarm.dev) - [Agent Swarm about page](https://www.agent-swarm.dev/about) --- # Temporal vs Agent Swarm > Compare Temporal, a durable execution platform for deterministic workflow code, with Agent Swarm, an open-source operating system for AI work. Canonical URL: https://www.agent-swarm.dev/vs/temporal Keywords: `Temporal vs Agent Swarm`, `temporal alternative for ai agents`, `temporal vs agent orchestration`, `durable execution vs agent orchestration`, `Temporal alternative`, `agent orchestration platform`, `self-hosted agent swarm`, `durable workflows for AI agents` ## TL;DR Temporal runs deterministic workflow code with replay guarantees: every state change lands in an event history, and the engine rebuilds exact state by replaying it. Agent Swarm orchestrates non-deterministic model and agent work: a lead agent delegates tasks to workers such as Claude Code or Codex in isolated containers, with persistent memory, step checkpoints, and human-in-the-loop approvals. Agent Swarm does not replace Temporal for deterministic transaction workflows such as payments or order sagas. Choose Temporal when correctness depends on deterministic replay. Choose Agent Swarm when the work is judgment-heavy AI work that cannot be replayed, only supervised. Related: [LangGraph vs Agent Swarm](https://www.agent-swarm.dev/vs/langgraph), [All comparisons](https://www.agent-swarm.dev/vs) ## What is the category difference? Temporal is a durable execution platform for deterministic workflow code. agent-swarm.dev is an open-source operating system for AI work: a standing team of agents you run on your own infrastructure. The practical difference is build-with framework vs run-the-team operating product. ## When should I choose Temporal? ### Correctness depends on deterministic replay Payments, order sagas, inventory reservations: if a wrong recovery is a double charge or a lost order, you want Temporal's model. Workflow code must be deterministic, every event is recorded, and the platform rebuilds exact state by replaying the event history after any crash. Note the boundary: Temporal replays Workflow code, but it retries Activities. An Activity that charges a card or calls an external API can run again after a failure, so Temporal expects Activity code to be idempotent. ### You are shipping a product backend, not running an AI team Temporal is an SDK and a service you embed in your own application, with official SDKs for Go, Java, .NET, PHP, Python, Ruby, Rust, and TypeScript (as of 2026-10-06). Your engineers write workflow code in the language they already ship, run workers as their own processes, and keep the orchestration inside the product boundary. ### You want mature operations at scale Temporal is the older, larger project by a wide margin: more than 23,000 GitHub stars against fewer than 1,000 for Agent Swarm (as of 2026-10-06), signals, queries and updates for interacting with live workflows, child workflows for fault isolation, worker versioning for safe deploys, and a managed Temporal Cloud with a 99.9% SLA and a 99.99% high-availability option. ## When should I choose agent-swarm.dev? ### The work is non-deterministic by nature An LLM call can return a different answer on retry, so durability for agent work means checkpointing outcomes, not recomputing them. Agent Swarm writes an atomic checkpoint after every workflow step: completed steps are not re-run. A step interrupted mid-flight has no checkpoint and runs again after resume, including its model call. Temporal's docs agree: LLM invocations belong outside the replay path. ### You want a standing team, not an orchestration project Agent Swarm is a running system you hand work to. A lead agent receives tasks from Slack, GitHub, Linear, email, or the API, breaks goals into tasks, and delegates them to workers with dependencies, priority queues, and review gates. Persistent memory and identity per agent mean the swarm recalls prior decisions instead of starting cold on each run. ### Recurring and supervised work should run itself Schedules, DAG workflows with webhook and manual triggers, and human-in-the-loop approval nodes that pause a run and post an approval card in Slack are built in. A heartbeat sweeps the swarm every 90 seconds, detects stalled tasks, and recovers them. The whole stack self-hosts free under MIT with Docker Compose or Helm. ## Side-by-side comparison | Dimension | Temporal | agent-swarm.dev | |---|---|---| | Category | Durable execution platform for deterministic workflow code. | Open-source operating system for AI work: a lead agent plus coordinated workers with shared memory. | | State persistence | Event-sourced: every command and event is appended to the workflow's event history in the Temporal Service. | An API server holds state in SQLite, and every workflow step ends with an atomic checkpoint write. | | Replay and recovery | Deterministic replay rebuilds exact Workflow state from the event history after any crash. Activities are retried rather than replayed, so Temporal expects idempotent Activity code. | Completed steps resume from their last checkpoint and are not re-run. A step interrupted mid-flight runs again, including its model call. A failed agent-task node is re-dispatched as a fresh task only if the node has a retry policy. A crashed task is pinned back to the same agent and escalated to the Lead after about ten minutes if the agent never returns; otherwise the heartbeat can reassign or fail the task. | | Task decomposition | You decompose work into workflow code, activities, and child workflows. | The lead agent breaks goals into tasks and delegates them to specialized workers. | | Memory | Workflow state is the event history; long-term knowledge across runs is out of scope. | Persistent memory and identity per agent, searchable across the swarm and compounding over sessions. | | Worker isolation | Workers are your processes polling task queues; isolation is yours to design. | Every worker runs in its own Docker container with its own credentials and workspace. | | Approvals / human-in-the-loop | Signals, queries, and updates let your code interact with a running workflow; the approval UX is yours to build. | Human-in-the-loop nodes pause a run in a waiting state and post an approval card in Slack. | | Observability | Web UI with full event history, stack traces, search, and batch resets. | Dashboard with task lineage, session logs, and run history per workflow, plus workflow version history. | | Deployment model | Self-hosted open-source server or Temporal Cloud, with SDKs in eight languages. | Self-host for free under MIT with Docker Compose or Helm on Kubernetes. Enterprise support is available by conversation. | | Operational burden | Self-hosting means operating the Temporal Service and its persistence and visibility stores; Temporal Cloud removes that. | Docker Compose or Helm on your infrastructure; a heartbeat sweeps every 90 seconds and recovers stalled tasks. | | Model and tool flexibility | Model-agnostic by omission: LLM calls live in activities you write and operate. | Workers run Claude Code, Codex, opencode, pi-mono, and other harnesses, chosen per task. | | Pricing (as of 2026-10-06) | The server is open source under MIT; Temporal Cloud pay-as-you-go starts at $50 per million actions with $150 in free credits, plus storage and support tiers. | Free self-hosting under MIT. Enterprise support has services, scope, and pricing agreed by conversation. | | Adoption (as of 2026-10-06) | More than 23,000 GitHub stars and official SDKs in eight languages. | Fewer than 1,000 GitHub stars; Capchase went from a PoC to 44 active users and 10k+ weekly tasks within a quarter (published case study). | | Best short version | Make deterministic code survive anything. | Run a team of agents that does the work. | ## Proof-of-concept checklist 1. Pick one canonical workflow that matters to your business and write down its side effects first: the pull request it opens, the message it sends, the charge it makes. 2. Implement it on Temporal with workflow code and activities, and on Agent Swarm as a delegated task or a DAG workflow. 3. Force-kill a worker mid-step on both systems. 4. Pass/fail, duplicate side effects: after recovery, check for a double pull request, a double message, a double charge. Zero duplicate side effects is the pass bar. 5. Pass/fail, recovery budget: before the test, the team sets a budget for time from the kill to a correct completed run. Measure both systems against that budget. 6. Pass/fail, manual intervention: record every manual action a human took to finish the run or clean up after it. Set the allowance before the run, for example zero or one documented action per run. 7. Migration acceptance: move a step only when it passes all three criteria on repeated runs, not on a single lucky run. 8. Decide per step, not per platform: keep deterministic money and state steps on Temporal and give judgment-heavy steps to agents. ## Where agent-swarm.dev is still catching up ### Temporal's replay guarantees are genuinely stronger for deterministic work Event history replay reconstructs exact workflow state, which is why Temporal is the right answer for payments, order sagas, and any step where a wrong retry is a double charge. The guarantee covers Workflow code: Activities are retried, not replayed, so an Activity that charges a card or calls an external API must be idempotent. Agent Swarm checkpoints after every step: completed steps are not re-run, but a step interrupted mid-flight runs again after resume, including its model call, and can repeat a side effect unless the task is idempotent. For deterministic transaction workflows, keep Temporal. ### Temporal's ecosystem and operational maturity are far ahead As of 2026-10-06, Temporal has more than 23,000 GitHub stars against Agent Swarm's fewer than 1,000, official SDKs in eight languages, and a managed cloud with published SLAs and Business and Enterprise support tiers. Agent Swarm is the younger project. It offers free self-hosting under MIT and enterprise support with services and scope agreed by conversation. ### Long business waits are a solved problem in Temporal Durable timers that sleep for months, Temporal Schedules with backfill, and continue-as-new for unbounded histories are built into the platform. Agent Swarm schedules recurring agent work well, but a deterministic three-month wait inside a transaction flow belongs in Temporal. ### Keep both: Temporal as the deterministic backplane, agents for judgment-heavy steps The strongest architecture keeps both. Temporal stays the deterministic backplane for money, state machines, and sagas. An Activity then hands selected judgment-heavy steps to Agent Swarm through its HTTP API or a webhook trigger, and records the result when the swarm finishes. Because Activities are retried, that hand-off Activity needs an idempotency key or dedup, so a retry does not start a second swarm task for the same step. This is a pattern, not a product: there is no built-in connector today, so you wire the HTTP call yourself. The honest detail is that Temporal's own documentation already tells you to put LLM invocations in Activities, which is exactly where the hand-off lives. ## Proof by trying ### Run the swarm on one real task before you redraw the architecture Agent Swarm is open source under MIT and the fastest way to judge it is a real judgment-heavy task. The bunx @desplega.ai/agent-swarm onboard wizard collects credentials, generates the compose files, starts the stack, and verifies health. Hand the swarm a job from Slack or GitHub, then run the proof-of-concept checklist above beside your Temporal evaluation. - [Deploy Agent Swarm](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is Agent Swarm a Temporal alternative? Not for deterministic transaction workflows. Agent Swarm does not replace Temporal for payments, order sagas, or any flow where correctness depends on replaying an event history to exact state. It is an alternative to building agent orchestration yourself when the work is non-deterministic model and agent work: a lead agent, isolated workers, persistent memory, schedules, and review gates on infrastructure you control. ### Does Agent Swarm replay workflows deterministically? No, and it does not try to. Model calls are non-deterministic, so Agent Swarm writes an atomic checkpoint after every step and resumes from the last checkpoint after a crash. Completed steps are not re-run; a step interrupted mid-flight has no checkpoint and runs again, including its model call, so that step can repeat a side effect unless the task is idempotent. A failed agent-task node is re-dispatched as a fresh task only if the node has a retry policy. A crashed task is pinned back to the same agent, and if the agent never returns, the heartbeat escalates it to the Lead after about ten minutes (HEARTBEAT_RESUME_PIN_GRACE_MIN, default 10); otherwise the heartbeat can reassign or fail the task. Task results themselves are first-call-wins and idempotent on an identical repeat. ### Can Temporal and Agent Swarm coexist? Yes, and for many teams that is the right end state. Temporal keeps the deterministic backplane: transactions, state machines, sagas, long timers. An Activity hands judgment-heavy steps to Agent Swarm over its HTTP API or a webhook trigger and records the outcome. Because Activities are retried, give that hand-off an idempotency key or dedup so a retry cannot start a second swarm task. It is an integration pattern you wire yourself, not a built-in connector. ### When should I keep Temporal? Keep Temporal whenever a wrong retry has a real cost: charging a card twice, double-shipping an order, losing a reservation. Deterministic replay protects Workflow code, and idempotent Activities protect the side effects, which is the strongest correctness model in the category. Also keep it when your team already operates it fluently and the workflow is deterministic business logic. ### Is Agent Swarm free to self-host? Yes. Agent Swarm is open source under MIT and self-hosts with Docker Compose or Helm on Kubernetes, with no license fee and no enforced worker cap. Discuss enterprise support with the team, with services and scope agreed separately. ## Sources - [Temporal Workflow Definition (determinism and constraints)](https://docs.temporal.io/workflow-definition) - [Temporal Workflow Execution (event history and replay)](https://docs.temporal.io/workflow-execution) - [Temporal Activities (retries and timeouts)](https://docs.temporal.io/activities) - [Temporal Activity Definition](https://docs.temporal.io/activity-definition) - [Temporal Retry Policies (Activity retries and idempotency)](https://docs.temporal.io/encyclopedia/retry-policies) - [Temporal Schedules (backfill)](https://docs.temporal.io/schedule) - [Temporal Workers](https://docs.temporal.io/workers) - [Self-hosted Temporal Service guide](https://docs.temporal.io/self-hosted-guide) - [Temporal Cloud pricing docs](https://docs.temporal.io/cloud/pricing) - [Temporal Cloud pricing page](https://temporal.io/pricing) - [Temporal on GitHub (README, license, stars)](https://github.com/temporalio/temporal) - [Agent Swarm Workflows concept (checkpoint durability, Per-Step Retry)](https://docs.agent-swarm.dev/docs/concepts/workflows) - [Agent Swarm Task Lifecycle concept (Crash Recovery and Graceful Resume)](https://docs.agent-swarm.dev/docs/concepts/task-lifecycle) - [Agent Swarm architecture overview](https://docs.agent-swarm.dev/docs/architecture/overview) - [Agent Swarm memory architecture](https://docs.agent-swarm.dev/docs/architecture/memory) - [Agent Swarm deployment guide](https://docs.agent-swarm.dev/docs/guides/deployment) --- # OpenAI Agents SDK vs Agent Swarm > The OpenAI Agents SDK is a library for building agents into your own app. Agent Swarm is a self-hosted operating swarm that runs recurring team work. Canonical URL: https://www.agent-swarm.dev/vs/openai-agents-sdk Keywords: `openai agents sdk alternative`, `openai agents sdk vs agent swarm`, `agents sdk vs multi-agent platform`, `openai agents sdk comparison`, `openai agents framework vs agent swarm`, `build agent app vs run agent team`, `openai agents sdk human in the loop`, `multi-agent orchestration platform`, `self-hosted agent platform`, `ai company operating system` ## TL;DR The OpenAI Agents SDK is a framework for building agent behaviour into your own Python or TypeScript application: agents, handoffs, guardrails, sessions, and tracing inside your codebase. Agent Swarm is a different layer: an open-source, self-hosted operating swarm where a lead agent takes work from Slack, repositories, issue trackers, email, or the API and delegates it to workers in isolated containers, with shared memory and schedules across sessions. Choose the SDK to build an agent app; choose Agent Swarm to run an agent team. Many teams use both. ## What is the category difference? OpenAI Agents SDK is a framework for building agent behaviour into your own application. agent-swarm.dev is a persistent, self-hosted operating swarm for recurring team work. The practical difference is build-with framework vs run-the-team operating product. ## When should I choose Agents SDK? ### You are building agents into your own product The Agents SDK is a pip or npm package with a deliberately small set of primitives — agents, handoffs, and guardrails — plus a built-in loop that runs tools until the task is done. You own the architecture and ship agent features inside your Python or TypeScript codebase. ### You need voice or realtime agents The SDK ships realtime agents built on gpt-realtime, with automatic interruption detection and streaming transport, plus voice pipelines that chain speech-to-text, an agent workflow, and text-to-speech. Guardrails and handoffs work in voice runs too. If spoken interaction is the requirement, OpenAI's own framework is the direct path. ### You want OpenAI-native tracing and evals Built-in tracing lets you visualize, debug, and monitor agent runs step by step, and connects directly to OpenAI's evaluation, fine-tuning, and distillation tools. When your quality loop already lives on OpenAI's platform, the instrumentation comes free with the framework instead of being another system to wire up. ### You do not want a server to run The SDK is a library, not a platform: it runs inside your own process, from a laptop script to a serverless deployment. Agent Swarm is a running system — an API plus workers in isolated Docker containers — which is power you only pay for when you need a standing team. ## When should I choose agent-swarm.dev? ### You want a standing team, not a library Agent Swarm is an operating system for AI work: a lead agent receives goals from Slack, repositories, issue trackers, email, or the API, and delegates them to specialized workers such as Claude Code, Codex, pi, opencode, Devin, or ACP agents. You assign outcomes, not orchestration code. ### Memory needs to compound across sessions Isolated containers, shared memory, tools, schedules, and review gates preserve work across sessions, so the swarm builds on prior decisions, codebase patterns, and failed approaches instead of starting cold on every run. Each new task starts with what the team has already learned. ### Recurring work should run by itself Schedules, heartbeats, and workflows are built in, so follow-ups, checks, reports, and implementation loops run on a cadence while the team is offline, and the results wait in Slack or the dashboard. The SDK has no scheduler: your application triggers every run. ### You want to own the infrastructure Agent Swarm is open source under the MIT License and self-hosted with docker compose or the OCI Helm chart: you pay for the infrastructure and inference providers you choose. Enterprise support is available by conversation, with services and scope agreed separately. ## Side-by-side comparison | Dimension | Agents SDK | agent-swarm.dev | |---|---|---| | Abstraction level | A library of primitives — agents, handoffs, guardrails — that you compose in Python or TypeScript code. | A running system you hand goals to, with the orchestration already built. | | Orchestration | You write the orchestration: an agent loop, agents as tools, and handoffs between agents you define. | A lead agent breaks goals down and delegates them to specialized workers from a shared task pool. | | State and memory | Sessions persist a conversation's history across multiple agent runs, with SQLite, Redis, MongoDB, SQLAlchemy, Dapr, or encrypted backends you wire up. | Shared memory compounds across sessions, so the swarm recalls prior decisions, patterns, and failed approaches. | | Scheduling | There is no built-in scheduler; your application triggers every run. | Schedules, heartbeats, and workflows are built in, so recurring work runs on a cadence. | | Worker isolation | Agents run inside your application process; optional sandbox agents add isolated workspaces with shell and file access. | Every worker runs in its own Docker container with a private workspace. | | Integrations | Tools are your own functions, hosted tools, and any MCP server you connect in code. | Work arrives from Slack, GitHub, GitLab, Linear, Jira, email, WhatsApp, and the API, with MCP servers registered per agent. | | Deployment | A pip or npm package that ships inside your application, from a laptop to serverless. | A free self-hosted stack under MIT via docker compose or the OCI Helm chart. Enterprise support covers services and scope agreed separately. | | Model choice | OpenAI models by default, with non-OpenAI providers through built-in integration points and beta Any-LLM and LiteLLM adapters. | Your choice of harness and models: Claude Code, Codex, pi, opencode, Devin, or ACP agents. | | Approval boundaries | Human-in-the-loop tool approvals you implement: mark the tools that need approval, then pause, approve, and resume runs. | Review gates and human approval requests are built into the task flow. | | Operational ownership | You own the application, its state stores, and its uptime. | You own the infrastructure and provider keys. Enterprise support covers services and scope agreed separately. | ## Where agent-swarm.dev is still catching up ### There is no in-process Agent Swarm library Agent Swarm is not something you import. If the outcome you want is agent logic embedded in your own Python or TypeScript application, the OpenAI Agents SDK is the right tool, and Agent Swarm does not replace it — that is framework work, and the SDK is purpose-built for it. ### A swarm has more moving parts to operate Self-hosting Agent Swarm means running an API, workers, containers, and a database, and owning upgrades and backups. The SDK adds no server footprint beyond the application you already run, so teams that do not need a standing swarm should not operate one. ### The two coexist well An application built on the SDK can sit next to a swarm that maintains it: the swarm handles recurring reviews, issue triage, and release work around the repo, while the SDK powers the agent features inside the product. A swarm worker can also build and ship SDK-based code as one of its tasks. ## Proof by trying ### Run an agent team before you build one Agent Swarm is open source under MIT and self-hosted: docker compose up, then hand it a real task from Slack, a repository, an issue tracker, email, or the API. Judge it against any framework on the same piece of work. - [Deploy Agent Swarm](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is Agent Swarm an OpenAI Agents SDK alternative? Only for some use cases, because the two solve different layers. The Agents SDK is a framework for building agent behaviour into your own application; Agent Swarm is a self-hosted operating swarm that runs recurring team work with a lead agent, workers, shared memory, and schedules. If you are building an app, choose the SDK. If you want a standing agent team, run Agent Swarm. ### Can I use the OpenAI Agents SDK and Agent Swarm together? Yes. An application built on the SDK can sit next to a swarm that maintains it: the swarm runs recurring reviews, triage, and release work around the repository while the SDK powers agent features inside the product. A swarm worker can also write and ship SDK-based code as one of its assigned tasks. ### Does Agent Swarm work with OpenAI models? Yes. Agent Swarm gives you your choice of harness and models: Claude Code, Codex, pi, opencode, Devin, or ACP agents can run as workers, and the docs describe Codex as OpenAI's coding agent with support for both API keys and ChatGPT OAuth. You pick the provider, the model, and the account each worker bills to. ### Is the OpenAI Agents SDK the same as OpenAI Swarm? No. OpenAI Swarm was OpenAI's experimental educational library for learning multi-agent orchestration, and the Agents SDK is its production-ready upgrade — OpenAI recommends the SDK for all production use cases. Agent Swarm is a different product entirely, built by Desplega Labs. For the full distinction, see OpenAI Swarm vs Agent Swarm. ### Does the OpenAI Agents SDK keep memory between sessions? Yes. The SDK's sessions persist a conversation's history across multiple agent runs, so an agent picks up prior turns without you shuttling state between runs by hand, and you choose the backend: SQLite, Redis, MongoDB, SQLAlchemy, Dapr, encrypted sessions, or OpenAI-hosted conversation state via the Conversations API. That history belongs to one conversation, while durable memory that compounds across an entire team's work over weeks is a different layer, and that is the layer Agent Swarm provides with shared memory across sessions. ### Is the OpenAI Agents SDK open source? Yes. The Agents SDK is MIT-licensed, with separate Python and TypeScript repositories, and the TypeScript version documents integrations for serverless and edge environments. Agent Swarm is also MIT-licensed. In both cases you can read the code you depend on and run it on infrastructure you control. ## Related comparisons - [OpenAI Swarm vs Agent Swarm](https://www.agent-swarm.dev/vs/openai-swarm) - [CrewAI vs agent-swarm.dev](https://www.agent-swarm.dev/vs/crewai) - [LangGraph vs Agent Swarm](https://www.agent-swarm.dev/vs/langgraph) ## Sources - [OpenAI Agents SDK Python docs](https://openai.github.io/openai-agents-python/) - [OpenAI Agents SDK Python repo](https://github.com/openai/openai-agents-python) - [OpenAI Agents SDK JS/TS docs](https://openai.github.io/openai-agents-js/) - [OpenAI Agents SDK JS/TS repo](https://github.com/openai/openai-agents-js) - [Agent Swarm repo](https://github.com/desplega-ai/agent-swarm) - [Agent Swarm docs](https://docs.agent-swarm.dev) - [Agent Swarm about page](https://www.agent-swarm.dev/about) --- # n8n vs Agent Swarm > n8n automates the workflows you draw; Agent Swarm hands goals to a persistent team of agents that sits on top of n8n. Compare triggers, memory, approvals, pricing, and license. Canonical URL: https://www.agent-swarm.dev/vs/n8n Keywords: `n8n vs Agent Swarm`, `n8n alternative for AI agents`, `n8n vs multi-agent orchestration`, `Agent Swarm vs n8n`, `workflow automation vs AI agents`, `self-hosted n8n alternative`, `n8n AI Agent node alternative`, `multi-agent orchestration platform` ## TL;DR n8n is workflow automation: you design flows that connect apps through triggers, nodes, and actions, and each run follows the canvas you drew. Agent Swarm is multi-agent orchestration: a lead agent receives a goal, breaks it into tasks, and delegates them to persistent, specialized workers that write code, run research, and review each other's output in isolated containers. n8n's AI Agent node embeds real agent behaviour inside a flow, with dynamic tool selection, delegation to specialized agents, and persistent chat memory; Agent Swarm makes reasoning the whole system. The two are not substitutes: Agent Swarm sits on top of n8n, self-hosted, taking the open-ended steps inside the flows n8n already runs. Keep n8n for the repeatable app-to-app work; add the swarm where the work needs decomposition, judgement, and memory across sessions. ## What is the category difference? n8n is a workflow automation platform you design app-to-app flows in, connecting services through triggers, nodes, and actions on a visual canvas. agent-swarm.dev is an open-source operating system for AI work: a standing team of agents that decomposes goals into tasks and runs them on your own infrastructure. The practical difference is draw-the-flow workflow automation vs run-the-team operating product. ## When should I choose n8n? ### The work is deterministic app-to-app automation n8n flows are built from triggers, nodes, and actions you arrange up front: when a deal closes in the CRM, enrich it, post to Slack, update the warehouse. A deterministic flow runs exactly as drawn every time, and you can inspect each run step by step, re-run single steps, and replay or mock data while you build. When the steps are known and must run the same way every time, that is exactly the right tool. ### Non-engineers need a large connector catalogue and a visual builder n8n's integration directory counts 2,329 connectors, community nodes included, and its template library has passed 13,000 ready-made workflows, all assembled on a drag-and-drop canvas (n8n's own figures, as of 2026-10-08), with JavaScript or Python only where you want it. Ops, sales, and support teams can build and maintain their own automations without writing orchestration code. ### High-volume repeatable runs where predictability beats judgement n8n Cloud prices by workflow executions with unlimited steps per run (as of 2026-10-06), so a daily sync and a 50-step pipeline cost the same single execution. When volume is high and the value is in the flow running exactly as drawn, per-execution pricing and a deterministic canvas win. ## When should I choose agent-swarm.dev? ### The work is open-ended and needs decomposition and judgement Agent Swarm starts from a goal, not a flow. A lead agent breaks it into tasks with dependencies, assigns them to specialized workers, and adapts as results come in: coding, research, review, and ops work that cannot be drawn on a canvas in advance because the steps depend on what the work finds. ### Context should accumulate, and workers should be isolated Every agent keeps persistent memory and identity across sessions, shares a searchable filesystem with the swarm, and loads skills for reusable procedural knowledge. Workers such as Claude Code or Codex run in isolated containers, so each task gets its own environment, credentials, and blast radius. ### Recurring agent-led work with human approval gates, on infrastructure you control Scheduled tasks, DAG workflows with webhook (HMAC-verified), schedule, and manual triggers, and human-in-the-loop approval nodes are built in. Agent Swarm self-hosts free under MIT with Docker Compose or Helm, on your hardware and your model keys, air-gapped if you need it. ## Side-by-side comparison | Dimension | n8n | agent-swarm.dev | |---|---|---| | Category | Visual workflow automation: flows of triggers, nodes, and actions connecting apps, designed on a canvas. | Multi-agent orchestration: a lead agent decomposes goals into tasks for persistent, specialized workers. | | Triggers and integrations | n8n's directory carries 2,329 integrations, community nodes included, and more than 13,000 workflow templates, plus webhook, schedule, and app-event triggers (as of 2026-10-08). | 13 built-in integrations (Slack, GitHub, Linear, Jira, and more) that turn events into agent tasks, plus workflow triggers: webhook (HMAC), schedule, and manual. | | Task decomposition | You decompose the work on the canvas. An AI Agent node can select tools dynamically and delegate work to specialized agents inside the flow, but the overall plan is the one you drew. | The lead agent decomposes the goal into dependent tasks, routes them to workers, and re-plans as results arrive. | | Persistent state and memory | Execution state per run, plus instance-level variables and data tables. AI Agent nodes add persistent chat memory for a conversation, kept in-instance or in an external store such as Postgres or Redis. | Persistent agent memory and identity across every session, plus a shared filesystem the whole swarm can search. | | Recurring work | A schedule trigger re-runs the same flow: deterministic steps repeat exactly as drawn, and any AI Agent steps reason fresh on each run. | Scheduled tasks and cron-scheduled workflows where the agent decides what each run actually needs to do. | | Human approvals | Human approval for tool calls gates what an AI agent does inside a flow (per n8n's pricing page, as of 2026-10-06). | Human-in-the-loop approval nodes pause a run for a named approver, resolved from the dashboard or Slack. | | Worker isolation | Executions share the n8n instance; queue mode adds worker processes for throughput, not per-task sandboxes. | Every worker runs in its own isolated container with its own filesystem and credentials. | | Deployment | Self-host with Docker, air-gapped if needed, or use n8n Cloud hosted by n8n. | Self-host with Docker Compose or Helm on Kubernetes, air-gapped if needed. Discuss enterprise support for your deployment. | | Pricing (as of 2026-10-10) | Cloud Starter costs €/$20 per month on annual billing, or €/$24 month to month, for 2.5K workflow executions; Pro costs €/$50 per month on annual billing, or €/$60 month to month, for 10K. The self-hosted Business plan is €667 ($800) per month on annual billing, or €800 ($960) month to month. Pricing is per execution, with unlimited steps in every run. Self-hosted Community Edition is free. | Free self-hosted software under MIT. Enterprise support is available by conversation, with services and pricing agreed for your needs. | | License | Sustainable Use License (fair-code): free for internal business and non-commercial use; not OSI open source; .ee files require an Enterprise license. | MIT with no additional conditions; no license fee. | | Operational ownership | You own every flow: design it, monitor runs, re-run failures. AI Agent nodes reason inside the flow you drew. | You own the platform; the agents own task-level decisions, with a full audit trail and mid-run steering. | | Best short version | Automate the flow you designed. | Hand the goal to a team of agents. | ## Where agent-swarm.dev is still catching up ### n8n's connector breadth is far ahead n8n's directory carries 2,329 integrations, community nodes included, and its template library holds more than 13,000 workflows (as of 2026-10-08), against the 13 integrations Agent Swarm ships built in. If the job is plumbing between SaaS apps, n8n already has the node; with Agent Swarm you would be building that plumbing yourself. ### n8n is built for people who do not write code The drag-and-drop canvas, per-step previews, and template library let ops and business teams ship and maintain automations without engineering help. Agent Swarm assumes a team that wants agents doing knowledge work and is comfortable owning the infrastructure those agents run on. n8n trades flexibility for predictability: the run follows the flow you drew, with AI reasoning only where you placed it. Agent Swarm trades predictability for judgement: it finds a path to the goal you described, and you approve the steps that matter. In practice the two tradeoffs stack: n8n keeps the predictable plumbing, and the swarm handles the steps where predictability was never available. ## Use n8n with Agent Swarm: the swarm sits on top Agent Swarm is not an n8n replacement; it is the layer on top, and connects to self-hosted instances and n8n Cloud alike. n8n keeps the triggers, the connector catalogue, and the app plumbing. The swarm takes the open-ended step: the judgement call, the research, the code. The connection is plain webhooks, REST, and MCP; no custom node is required. ### An n8n flow hands the hard step to the swarm An app trigger feeds an HTTP Request node that POSTs to the swarm workflow's HMAC-verified webhook, along with the Wait node's resume URL. The swarm acknowledges at once, the agents do the open-ended work, and a script calls the resume URL, so the same n8n execution wakes and routes the result through its own nodes. ### The swarm uses your n8n flows as tools Mark existing n8n workflows as available in MCP and register the instance MCP server on the swarm agents that need it; the bearer token is stored as a swarm config reference, never in agent context. Agents search and run those workflows as tools, and n8n keeps every app credential. This works against n8n Cloud and self-hosted instances alike. ### n8n's AI Agent delegates to the swarm Over REST, the agent's flow POSTs a task to the swarm (POST /api/tasks), a Wait node polls it (GET /api/tasks/{id}), and the flow continues with the output. An MCP path is available by spec: point the AI Agent node's MCP Client Tool at the swarm's MCP server and it hands the job to the swarm lead directly. ## Proof by trying ### Keep n8n. Give the swarm the goals a flow cannot draw Agent Swarm is open source under MIT and self-hosts with Docker Compose, next to a self-hosted n8n or against n8n Cloud. The bunx @desplega.ai/agent-swarm onboard wizard collects credentials, generates the compose files, starts the stack, and verifies health. Point one n8n flow at the swarm's webhook and hand it the step you could never draw: the research, the code, the judgement call. - [Deploy Agent Swarm](https://docs.agent-swarm.dev/docs/getting-started) - [View the repo](https://github.com/desplega-ai/agent-swarm) ## FAQ ### Is Agent Swarm an n8n alternative for AI agents? No, and it does not need to be: Agent Swarm sits on top of n8n rather than replacing it. n8n's AI Agent node embeds a reasoning agent, connected to a chat model, choosing its own tools, holding chat memory, and delegating work to specialized agents, inside a workflow you design; Agent Swarm is a standing team of agents that plans the work itself, with persistent memory, specialized workers, and review gates. Most teams keep n8n for the integrations and let the swarm take the open-ended steps; the two connect over webhooks, REST, and MCP. If you had to pick only one, pick n8n for app-to-app automation and Agent Swarm for agents that own open-ended goals across sessions. ### What is the difference between n8n and multi-agent orchestration? n8n starts from a workflow you design: a trigger fires, and the run follows the nodes and actions on your canvas. AI Agent nodes can reason inside that design, selecting tools at run time, delegating work to specialized agents, and keeping chat memory, but the workflow itself is defined up front. Multi-agent orchestration starts from a goal: a lead agent decomposes it into tasks, delegates them to specialized workers, and adapts the plan as results arrive, with memory that persists across sessions. The first automates a process you design, with reasoning where you place it; the second makes and executes decisions within boundaries you set. ### Can n8n and Agent Swarm work together? Yes, in both directions, on self-hosted n8n and n8n Cloud alike: an n8n flow can start swarm work through the swarm's HMAC-verified webhook endpoint, and the swarm can call back into the same n8n execution or drive n8n flows over MCP. The section above walks through the three patterns. ### When should I choose n8n over Agent Swarm? Choose n8n alone when the work is deterministic app-to-app automation, when non-developers need the connector catalogue and visual builder, or when you run high volumes of repeatable flows and per-execution pricing with unlimited steps matters more than judgement. Add Agent Swarm on top when part of the work is open-ended: coding, research, review, and recurring operations that need decomposition, persistent memory, and approval gates on infrastructure you control. The common setup is both: n8n keeps the flows, the swarm takes the steps a flow cannot draw. ### Is n8n open source? Not under the OSI definition (as of 2026-10-06). n8n's code is available under the Sustainable Use License, a fair-code license that permits use and modification for your own internal business purposes and for non-commercial or personal use; running it as a commercial service for others, or using .ee enterprise files, requires a paid n8n license. Agent Swarm is MIT with no such conditions. ## Sources - [n8n homepage](https://n8n.io/) - [n8n integrations](https://n8n.io/integrations/) - [n8n pricing](https://n8n.io/pricing/) - [n8n workflow template library](https://n8n.io/workflows/) - [n8n LICENSE (Sustainable Use License)](https://github.com/n8n-io/n8n/blob/master/LICENSE.md) - [n8n Community License docs (Sustainable Use License)](https://docs.n8n.io/n8n-community-license/) - [n8n AI Agent node docs](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent/) - [Agent Swarm GitHub](https://github.com/desplega-ai/agent-swarm) - [Agent Swarm homepage](https://www.agent-swarm.dev) - [Agent Swarm pricing](https://www.agent-swarm.dev/pricing) - [Agent Swarm integrations](https://www.agent-swarm.dev/integrations) - [Agent Swarm docs: workflows](https://docs.agent-swarm.dev/docs/concepts/workflows) --- # Blog — agent-swarm.dev > Notes from inside the swarm. Technical deep dives, post-mortems, and architecture notes. Canonical URL: https://www.agent-swarm.dev/blog ## [Two small models triage every PR](https://www.agent-swarm.dev/blog/two-models-triage-every-pr) *October 21, 2026 · 3 min read* Clairic and Jev triage every pull request, and a coding agent reviews only what they flag. About $0.02 and 30 seconds per PR, across 14 real PRs. Tags: `AI code review`, `pull requests`, `Clairic`, `Jev`, `agent workflows`, `open source`, `Agent Swarm` ## [What if Devin is down?](https://www.agent-swarm.dev/blog/what-if-devin-is-down) *October 16, 2026 · 3 min read* Devin Oncall is one AI on-call vendor. Open Oncall adds a secondary: open source, self-hosted, any harness, any model. Tags: `AI on-call`, `open source on-call`, `PagerDuty`, `incident response`, `self-hosted AI agents`, `Agent Swarm`, `Open Oncall` ## [How to Avoid Vendor Lock-In for Coding Agents: A Layer-by-Layer Exit Test](https://www.agent-swarm.dev/blog/avoid-coding-agent-lock-in) *October 10, 2026 · 11 min read* Coding-agent lock-in lives in the context layers, not the model. Audit eight layers, run the exit test, and keep memory and traces exportable. Tags: `coding agent vendor lock-in`, `avoid ai coding agent lock-in`, `coding harness portability`, `multi-harness ai agents`, `agent memory export`, `self-hosted ai agents`, `claude code codex opencode`, `model gateway portability`, `agent exit test`, `portability checklist` ## [Shared-Context AI Agents: Patterns, Risks, and Setup](https://www.agent-swarm.dev/blog/shared-context-ai-agents) *October 7, 2026 · 12 min read* What shared-context AI agents are, how shared context differs from memory and private state, the risks, and how to run governed sharing. Tags: `shared-context ai agents`, `multi-agent context sharing`, `agent memory vs shared state`, `multi-agent orchestration`, `agent context governance`, `shared workspace ai agents`, `self-hosted ai agents`, `prompt injection multi-agent`, `lead and worker agents`, `ai agent human review` ## [We Deleted --resume: A Bounded Preamble Beats Session Resume](https://www.agent-swarm.dev/blog/deep-dive-context-preamble-session-resume) *October 7, 2026 · 10 min read* Why Agent Swarm dropped claude --resume and codex.resumeThread for an approximately 2,000-token context preamble that survives container restarts and harness re-routing. Tags: `session continuity`, `context preamble`, `harness routing`, `deep dive`, `agent-swarm` ## [Your Agents Write the Titles Your Trackers Read](https://www.agent-swarm.dev/blog/deep-dive-agent-artifacts-privacy-leak) *October 5, 2026 · 11 min read* An IMDEA audit of 9 AI chat services found trackers receiving titles, permalinks and screenshots, not just prompts. Agent swarms multiply those artifacts. Tags: `privacy`, `telemetry`, `agent artifacts`, `observability`, `agent-swarm` ## [Self-Hosted AI Agent Platforms: Licenses and Tradeoffs](https://www.agent-swarm.dev/blog/best-open-source-ai-agent-platforms-self-host) *October 2, 2026 · 10 min read* Twelve self-hosted AI agent platforms, including open-source projects and a labeled source-available exception. October 2026 snapshot of licenses, installation, and limitations. Tags: `best open source ai agents`, `open source agent platform`, `self hosted ai agents`, `self hosted agent platform`, `AI agent platforms` ## [A TLA+ Playbook for Your Scheduler, Queue or Retry Loop](https://www.agent-swarm.dev/blog/tla-plus-races-agent-swarm) *September 29, 2026 · 5 min read* Five steps, one prompt each: model a concurrent subsystem in TLA+, calibrate it on bugs you already fixed, turn every counterexample into a failing test, and keep the spec true with a daily swarm workflow. Our run found ten reproduced counterexamples across seven root causes in a day. Tags: `TLA+`, `formal verification`, `concurrency`, `race conditions`, `heartbeat`, `AI agents` ## [We Rebuilt Linear's “Loops updates” Clip as a Swarm Video in Eight Rounds](https://www.agent-swarm.dev/blog/linear-loops-video-replica) *September 25, 2026 · 7 min read* Three video models read Linear's motion-design teaser; the two Gemini models called the 3D scene 2D until 7.5s. A frame-by-frame check caught it. The replica is 858 frames of Remotion and three.js, reviewed eight times. Tags: `motion design`, `video analysis`, `Remotion`, `three.js`, `OpenRouter`, `AI agents` ## [TasteLabs Found Design Drift in Our Own Sites](https://www.agent-swarm.dev/blog/tastelabs-design-drift) *September 16, 2026 · 6 min read* Our landing sites had three amber ramps, 34 untokenized brand-color literals, and no BRAND.md files. One fix PR has merged; one is still open. Tags: `TasteLabs`, `design systems`, `design tokens`, `MCP`, `AI agents` ## [Multi-Agent Orchestration: The Production Architect's Guide](https://www.agent-swarm.dev/blog/multi-agent-orchestration) *August 10, 2026 · 8 min read* Core components of a production AI agent architecture, from orchestrator to human escalation, mapped to Agent Swarm docs and operator responsibilities. Tags: `multi-agent orchestration`, `agent architecture`, `shared memory`, `self-hosted agents` ## [25 MIT-licensed open-source projects worth tracking for agent infrastructure](https://www.agent-swarm.dev/blog/25-foss-repos-agentic-infra) *July 29, 2026 · 9 min read* 25 MIT-licensed agent-infrastructure repos with outsized, rising attention among 655 agent-swarm stargazers. Stars and activity checked 2026-10-10. Tags: `FOSS`, `agent infrastructure`, `MCP`, `agent harnesses`, `observability` ## [26 Tool Calls, One Script, $0.02: Measuring “Code Mode” in Production](https://www.agent-swarm.dev/blog/code-mode-token-savings) *July 8, 2026 · 12 min read* Our session rubric already tells agents: past ten items, write a script instead of N tool calls. We measured what that's worth on one production job, and where the savings stop. Tags: `code mode`, `MCP`, `agent scripts`, `token economics`, `LLM cost optimization` ## [An AI-Native Company OS Is Owned, Not Rented](https://www.agent-swarm.dev/blog/a-frontier-model-is-rented-a-swarm-is-owned) *June 15, 2026 · 10 min read* An AI native company OS is owned, not rented: the durable IP is the learning loop on top of models — memory, skills, workflows, traces, agents. Tags: `AI-native`, `agent-swarm`, `institutional memory`, `self-hosting`, `private evals`, `ai native company os` ## [Is Grep All You Need? What a New Paper Taught Us About Agent Memory](https://www.agent-swarm.dev/blog/is-grep-all-you-need-agent-memory) *June 10, 2026 · 12 min read* A PwC paper benchmarked grep against vector retrieval in agent harnesses. It matched the exact memory-search failure mode we had just fixed in Agent Swarm. Tags: `agent memory`, `agentic search`, `vector search`, `grep`, `agent-swarm` ## [Right-sizing Your Agent Swarm: What Container CPU and RAM Graphs Are Really Telling You](https://www.agent-swarm.dev/blog/right-sizing-agent-swarm-containers) *June 7, 2026 · 11 min read* A straight-line CPU climb and a coder worker stuck near 1.1 GB looked like production problems. They were metric interpretation traps. Here are the sizing numbers we actually run. Tags: `container sizing`, `SigNoz`, `self-hosting`, `AI agents`, `observability` ## [Script Workflows: Durable One-off Runs for Agent Work](https://www.agent-swarm.dev/blog/script-workflows-durable-one-off-runs) *June 4, 2026 · 9 min read* A workflow's power for one ad-hoc job: launch a TypeScript run, journal every step, replay instead of restarting, and compose the reusable swarm scripts every agent gets by default. Tags: `Script Workflows`, `durable replay`, `swarm scripts`, `workflow journal`, `AI agents` ## [Parallel Agents in Production: Pools, Routing, Dependencies](https://www.agent-swarm.dev/blog/task-delegation-architecture) *March 30, 2026 · 7 min read* How we run parallel agents in production: task pools, dependency graphs, and offer/accept routing across 6 agents. Lessons from 3,000+ tasks. Tags: `architecture`, `task delegation`, `AI agents`, `orchestration`, `parallel agents` ## [Openfort Hackathon: Teaching Agents to Pay](https://www.agent-swarm.dev/blog/openfort-hackathon) *February 28, 2026 · 8 min read* We shipped x402 payment capability into Agent Swarm — our AI agents can now autonomously pay for API services using crypto. Here's how we built it in a day. Tags: `x402`, `Openfort`, `crypto`, `hackathon` --- # Case Studies > Customer stories from teams using agent-swarm.dev to build AI-native operations, automate workflows, and contribute back to the open-source core. Canonical URL: https://www.agent-swarm.dev/case-studies ## [Capchase Case Study](https://www.agent-swarm.dev/case-studies/capchase) In a single quarter, agent-swarm.dev went from a PoC to 44 active users, 10k+ tasks weekly and 26 agents. Highlight: ~7,000 tasks/wk in 6 weeks --- # Capchase Case Study > In a single quarter, agent-swarm.dev went from a PoC to 44 active users, 10k+ tasks weekly and 26 agents. Published: 2026-08-03 Read time: 5 min read Tags: `FinTech`, `AI Native`, `Customer story` Canonical URL: https://www.agent-swarm.dev/case-studies/capchase ## Results _Updated October 16, 2026: refreshed active users, agent-hours, human requests, workflows, agents, and contributed PRs._ | Value | Metric | |---:|---| | 46 | active users | | 10k+ | tasks weekly | | 28 | agents | | 21 | workflows | | 30% | non-Tech users | | ~15 | tasks/wk at start | | ~7,000 | tasks/wk at week six | | 6 | weeks to scale | | 76 | merged PRs | Capchase has been one of the most advanced FinTechs for over 6 years now. They started using DevinAI soon after it launched in 2024, adopted Cursor in that same year, and by January 2026 the Tech team was migrating to Claude Code. Despite that, the team of ~30 engineers felt it was falling behind. During April, Tech and Product leadership had a conversation with Desplega Labs aimed to understand what truly meant to become AI Native. Everyone in the org was using Claude, ChatGPT, and multiple other solutions heavily, but the team wasn't upskilling fast enough. How would you continuously upskill a company? It's no secret that we worked together in the past, and that experience made us confident a short in-person 20 hour workshop would yield great results. The workshop had a single objective: develop an organizational blueprint on how to become AI Native. Together with that blueprint, we would define a Tech roadmap meant to sustain that evolution. In a single quarter, agent-swarm.dev went from a PoC to 44 active users, 10k+ tasks weekly and 26 agents. All due to Capchase doing something differently than most. ## Organizational alignment A clear mandate from the CEO resulted in a dedicated Tech Lead, [Daniel Füvesi](https://www.linkedin.com/in/daniel-fuvesi/), and multiple cross-functional leaders across Product, Risk, Operations, Customer Support, Sales, etc, all focused on rapid adoption. The results speak for themselves. In 6 weeks, they rocketed from ~15 tasks/wk to ~7,000 tasks/wk. They integrated with their CRM, gsuite, notion, helpdesk, observability platform, data-warehouse, and more. Daniel reflects on how the tech team stopped investing hours on triaging, data collection and synthesis. In fact, those periodic reports (payment status, customer report, enterprise discovery, etc), and automatic internal support tasks (think of Linear, Pylon and Slack messages) moved entirely to the swarm. That gave Tech a chance to implement key features like Automated security patches with [superagent.sh](https://superagent.sh/), also in the swarm, key in days of escalating cyberattacks. Why? Because 30% of agent-swarm.dev users at Capchase are non-Tech. They are asking the swarm those Data, Tech, Product and IT questions that used to consume the Tech team. They are able to build their own workflows, currently Capchase has 21 automated workflows, with the confidence that the underlying system is at the level Capchase needs. When asked about agent-swarm.dev, Daniel states clearly: ### Why the swarm? > "The swarm gives us three things. It is platform agnostic, so no single vendor can lock us in. It moves workflows (and skills) from individual laptops to the cloud, where they run day and night. It centralizes our company knowledge and skills in one system instead of scattering them across the team. When a provider goes down, we just flip a switch." ### Why not build it yourself? > "Many well-funded teams are out there 100% focused on delivering OSS for the agentic world. Building an agent platform from scratch would have pulled our engineers away from the product, and a closed platform would have put our AI roadmap in someone else's hands. Open source is the third option. We self-host it, we own the infra, we can read every line, and when we need something we build it and contribute it back. We get the velocity of a dedicated team and the ownership of an internal tool." ### How do you see the increasing cost challenge? > "We are in the transformation phase, where adoption has priority over efficiency. The swarm helps us maximize the utilization of our AI investment, and we actively monitor AI cost per employee. Looking ahead, we are experimenting with self-improvement loops that optimize token usage and cost per task." ### What would happen if you turned off the swarm now? > "If we turned off the swarm, all the operational burden it has been taking care of would suddenly land back on people. Months of automated workflows would sit idle while people redo their output by hand. Capchase would not break. It would slow down. Given that we own the memory/historical knowledge, we would adopt a comparable solution." ## From Capchase to all swarmers Capchase contributed more than 76 PRs to the swarm, four of them worth highlighting: Cumulative merged pull requests from the Capchase engineering cohort to [desplega-ai/agent-swarm](https://github.com/desplega-ai/agent-swarm), by month (the HTML page renders this as a weekly bar chart; aggregate only, no per-person figures): | Month | Merged PRs | Cumulative | |---|---:|---:| | 2026-04 | 1 | 1 | | 2026-05 | 10 | 11 | | 2026-06 | 20 | 31 | | 2026-07 | 18 | 49 | From first merged PR to 49 in 14 weeks, at ~3.6 merged PRs per week. - **[DevinAI as a harness #378](https://github.com/desplega-ai/agent-swarm/pull/378)**. Your team can move from Claude Code, Codex, Pi, DevinAI, etc., without even noticing. - **[Helm chart for k8s #434](https://github.com/desplega-ai/agent-swarm/pull/434)**. Thanks to them at least 3 other teams were able to deploy the swarm in GCP and AWS using their template. - **[Salesforce MCP connector guide #660](https://github.com/desplega-ai/agent-swarm/pull/660)**. A read-only OAuth setup walkthrough with a gotchas section distilled from real debugging, now part of the [official docs](https://docs.agent-swarm.dev/docs/integrations/salesforce). - **[Customizable session titles #1000](https://github.com/desplega-ai/agent-swarm/pull/1000)**. Sessions can now carry their own display name instead of echoing the root prompt. Fittingly, the swarm's 1,000th PR. Thank you for your 76 contributions, and counting. We are most proud of having Daniel as a key collaborator in our agent-swarm.dev community. He contributed 47 PRs, out of 76 PRs from Capchase, and we look forward to keep working with Capchase and others to help them reach the provider agnosticism they deserve. --- # Examples — Real agent-swarm.dev Sessions > Real session transcripts showing autonomous AI agent coordination in action. Canonical URL: https://www.agent-swarm.dev/examples ## [AI Agents Pay for Services with Crypto](https://www.agent-swarm.dev/examples/x402) agent-swarm.dev used x402 protocol to autonomously pay $0.05 USDC on Base mainnet and generate an anime-style image — no human wallet interaction. Tags: `x402`, `Crypto Payments`, `Base`, `Image Gen` ## [From Issue to Human-Approved Merge in Four Hours](https://www.agent-swarm.dev/examples/engineering-pr) A real session: a feature request went from pull request open to a human merge in 4 h 8 min — 6 commits, 29 files, 30 green checks. Tags: `Engineering`, `GitHub`, `Delegation`, `Code Review` ## [A Research Brief That Writes Itself Every Morning](https://www.agent-swarm.dev/examples/recurring-research-brief) A real recurring workflow: 150 stories scraped and 20 curated daily, delivered by email and archived — 211 dated briefs, no failed run since 24 August. Tags: `Schedules`, `Research`, `Memory`, `GTM` ## [Thirty-Three Security Alerts to Zero](https://www.agent-swarm.dev/examples/support-triage) A real operations run: 33 Dependabot alerts triaged read-only, one grouped pull request opened only after a human approved the plan, zero left open. Tags: `Support`, `Triage`, `Integrations`, `Approvals` ## [Nine Runs, One Refused Push, Four Merges](https://www.agent-swarm.dev/examples/long-running-orchestration) A real long-running orchestration: one advisor request carried to three live pages over 47 hours — 9 scheduled runs, 23 tasks, $14.14 model cost, and a human behind every merge. Tags: `Workflows`, `Orchestration`, `Recovery`, `Approvals` --- # Agent Swarm integrations Agent Swarm connects to the tools a software team already runs: issue trackers, chat platforms, email, CRM, observability, and search. This page is a discovery layer over the documentation, grouping every supported integration by workflow. Each entry links to its canonical setup guide. ## Integrations for engineering work Tickets, pull requests, and review requests become agent tasks, and the work returns to the same place. ### GitHub **What enters the swarm:** pull request and issue events from a GitHub App webhook: bot assignment, review requests, submitted reviews, @-mentions, or a trigger label. **What agents can do:** work the issue or review, push branches, and open pull requests with the `gh` CLI. **Where results return:** comments on the originating issue or pull request, with reactions confirming acceptance and pickup. [Set up the GitHub integration](https://docs.agent-swarm.dev/docs/integrations/github) **How-to: Connect GitHub to Agent Swarm (swar.am)** · [Watch on YouTube](https://www.youtube.com/watch?v=IldiE5fWRdk) ### GitLab **What enters the swarm:** merge request, issue, and comment events from a token-verified webhook, plus CI notification tasks when a pipeline fails on a tracked merge request. **What agents can do:** work the issue or merge request with the `glab` CLI, create merge requests, and comment on issues. **Where results return:** notes on the merge request or issue in GitLab. [Set up the GitLab integration](https://docs.agent-swarm.dev/docs/integrations/gitlab) ### Linear **What enters the swarm:** assigning the Linear agent to an issue creates a swarm task and a Linear AgentSession. A workflow-state gate skips triage and backlog issues by default, with a label override. **What agents can do:** post thoughts, actions, responses, and errors back to the AgentSession in real time. **Where results return:** activity streams into the AgentSession. Sync is inbound-only: status changes, labels, and comments outside the session go back through the linear-interaction skill, not automatically. [Set up the Linear integration](https://docs.agent-swarm.dev/docs/integrations/linear) ### Jira Cloud **What enters the swarm:** issues assigned to the bot, or comments that @-mention it, through OAuth 3LO and dynamically registered webhooks. **What agents can do:** work the issue with its description and comments read as plain text, and follow up on new mentions. **Where results return:** task lifecycle events post back as comments on the linked Jira issue. [Set up the Jira integration](https://docs.agent-swarm.dev/docs/integrations/jira) ### Azure DevOps **What enters the swarm:** service hooks from Azure Repos. A bot mention in a pull request description or comment creates a task. Azure Repos pull requests only; Azure Boards work items are not supported yet. **What agents can do:** clone, push, and open pull requests with `git` and the `az` CLI, as a dedicated bot user with its own Personal Access Token. **Where results return:** comments on the pull request. As with GitHub and GitLab, anyone who can comment on a connected repository can trigger the swarm. [Set up the Azure DevOps integration](https://docs.agent-swarm.dev/docs/integrations/azure-devops) ### Bitbucket **What enters the swarm:** pull request events from a signed Bitbucket Cloud webhook. A bot @-mention in a description or comment, or the bot listed as a reviewer, creates a task. A merged or declined pull request cancels its active task. Bitbucket Cloud only; Data Center and Server are not supported. **What agents can do:** clone, push, and open pull requests with `git` and `curl` against the Bitbucket REST API, authenticated with one scoped Atlassian API token on a dedicated bot account. **Where results return:** comments on the pull request. As with GitHub and GitLab, anyone who can comment on a connected repository can trigger the swarm. [Set up the Bitbucket integration](https://docs.agent-swarm.dev/docs/integrations/bitbucket) ## Integrations for team communication Agents become reachable where people already talk. These are the human-in-the-loop surfaces: assign work, steer it mid-run, approve a decision, and read the outcome in the thread. ### Slack **What enters the swarm:** @-mentions, slash commands, direct messages, and thread replies, all routed as tasks. A `swarm#` prefix targets a specific agent or broadcasts to all workers. **What agents can do:** run multi-agent workflows across channels and the Slack Assistant sidebar, take steering on running tasks, and route approval requests to a person. **Where results return:** replies in the same thread, with configurable reactions tracking the task to completed or failed. [Set up the Slack integration](https://docs.agent-swarm.dev/docs/integrations/slack) **How-to: Connect Slack to Agent Swarm (swar.am)** · [Watch on YouTube](https://www.youtube.com/watch?v=FV1_NnEclu4) ### AgentMail **What enters the swarm:** email sent to a registered agent inbox. Mail to a worker becomes a task, mail to the lead becomes an inbox message, and thread follow-ups route to the same agent. **What agents can do:** read, send, reply to, and forward email through AgentMail's MCP tools, with optional domain filters. **Where results return:** email replies in the original thread, from one consistent address. [Set up the AgentMail integration](https://docs.agent-swarm.dev/docs/integrations/agentmail) ### Kapso (WhatsApp) **What enters the swarm:** inbound WhatsApp messages on a provisioned number, delivered through a signed and deduplicated webhook. Each number maps to an agent or a workflow. **What agents can do:** reply in-thread over WhatsApp, with the kapso-whatsapp skill for templates, media, reactions, and history. **Where results return:** WhatsApp messages to the sender, inside the same conversation. [Set up the Kapso WhatsApp integration](https://docs.agent-swarm.dev/docs/integrations/kapso) ### Chat SDK (Telegram, Discord, Teams) **What enters the swarm:** bot mentions and direct messages on Telegram, Slack, Discord, and Microsoft Teams, through Vercel's Chat SDK. Each becomes a task for the Lead by default, and a reply in the same thread steers the running task. The channel is off by default; Slack and Teams support is experimental. **What agents can do:** reply, read the thread, and send files with the `chat-*` MCP tools and the built-in chat-sdk skill. The Lead can also route a channel to a fixed agent or workflow. **Where results return:** the task output posts to the thread it came from, along with any files the agent attached. [Set up the Chat SDK channel](https://docs.agent-swarm.dev/docs/integrations/chat-sdk) ### Composio **What enters the swarm:** nothing. Composio is a routed tool layer, not an event source, and the current integration is a prototype and admin surface. **What agents can do:** open Tool Router sessions for connected apps such as Gmail, GitHub, Slack, Notion, and HubSpot, generate Connect Links when a user must authorize an app, and execute app tools in the session. **Where results return:** tool output goes back to the calling agent or CLI. [Set up Composio tool routing](https://docs.agent-swarm.dev/docs/integrations/composio) ## Integrations for operations and customer systems CRM data, Microsoft 365, error monitoring, and web search, inside an agent's reach while it works a task. ### Salesforce **What enters the swarm:** nothing inbound. Salesforce connects as an MCP server over HTTP, authenticated with OAuth through an External Client App. **What agents can do:** call Salesforce's hosted MCP endpoints, such as sObject reads, without managing tokens directly. **Where results return:** query results come back to the agent inside the task it is working on. [Set up the Salesforce MCP connection](https://docs.agent-swarm.dev/docs/integrations/salesforce) ### Microsoft Graph **What enters the swarm:** nothing inbound. Microsoft Graph is a reviewed OpenAPI connection using delegated OAuth: a signed-in user authorizes the swarm to act on their behalf. **What agents can do:** read and send Teams channel and chat messages, read and send Outlook mail, list OneDrive folders, and read user profiles. **Where results return:** data comes back to the agent, and sent messages go out as the authorizing user. [Set up the Microsoft Graph connection](https://docs.agent-swarm.dev/docs/integrations/microsoft-graph) ### Sentry **What enters the swarm:** nothing automatically. Workers ship with `sentry-cli` pre-installed, and an agent investigates an issue when a task asks it to. **What agents can do:** pull issue details, stacktraces, and breadcrumbs with the /investigate-sentry-issue command, then resolve, mute, or unresolve the issue. **Where results return:** the issue's status changes in Sentry, and the analysis lands in the task output. [Set up Sentry error triage](https://docs.agent-swarm.dev/docs/integrations/sentry) ### Serply **What enters the swarm:** nothing. Serply supplies search access for agent tasks and does not create tasks from incoming events. **What agents can do:** request Google web, news, and scholar results through the serply-search skill, using the API key stored in the dashboard. **Where results return:** search references come back to the agent, which fetches the linked pages before citing them. [Set up Serply search](https://docs.agent-swarm.dev/docs/integrations/serply) ## Native integrations vs routed tools Two kinds of connection matter here. Native event sources create tasks: GitHub, GitLab, Linear, Jira, Azure DevOps, Bitbucket, Slack, AgentMail, Kapso, and Chat SDK turn webhooks, mentions, assignments, or messages into work. Tool-access surfaces never create tasks: Composio, Salesforce, Microsoft Graph, Sentry, and Serply answer an agent's calls for data or actions while a task runs. Several native sources also emit to the internal event bus, so an event can start an automated workflow instead of an agent task. ## How to choose and what you need Start from where work enters your team. If tickets drive your process, connect an issue tracker first. If conversations drive it, start with Slack, email, or WhatsApp. Then add tool-access surfaces for the systems agents need while they work. Credentials follow the same split. Native sources need a webhook or app registration: a GitHub App, a GitLab token, OAuth apps for Linear and Jira, a bot PAT for Azure DevOps, a webhook secret and Atlassian API token for Bitbucket, Slack Socket Mode tokens, signing secrets for AgentMail and Kapso, and a bot token per platform for Chat SDK. Routed tools need credentials an agent can call with: OAuth for Salesforce and Microsoft Graph, an auth token for Sentry, an API key for Serply, and a project key for Composio. Every permission scope and env var lives in the linked setup guide, and the [MCP tools reference](https://docs.agent-swarm.dev/docs/reference/mcp-tools) lists what agents call once connected. For worked examples see [examples](/examples), for head-to-head positioning see [comparisons](/vs), and for plans see [pricing](/pricing). For enterprise support with integrations, [book a conversation](https://calendar.app.google/49DmjEXTPAv5NsRq6). Agree the services and scope with the team. The full inventory, with setup, behavior, and operational notes for each integration, lives in the [integrations documentation](https://docs.agent-swarm.dev/docs/integrations). --- # About Agent Swarm Agent Swarm is the open-source, self-hosted AI company operating system built by Desplega Labs. It is not OpenAI Swarm, OpenAI's experimental educational library, replaced by the OpenAI Agents SDK. Agent Swarm is an open-source operating system for AI work. A lead agent breaks goals into tasks, routes those tasks to specialized workers such as Claude Code or Codex, and keeps shared memory, tools, schedules, and review gates available across sessions. Teams can self-host the MIT-licensed project for free. Enterprise support covers services and scope agreed [by conversation](https://calendar.app.google/49DmjEXTPAv5NsRq6). ## Built by Desplega Labs Agent Swarm is built by **Desplega Labs, S.L.** The company also operates the agent-swarm.dev website, publishes the open-source repository, and maintains the product documentation. The project is designed around inspectable infrastructure: its source, deployment examples, release history, and issue tracker are public on GitHub. Desplega Labs, S.L. is located at Tuset 3, planta 5, 08006 Barcelona, Spain. ## Where to explore - Read the [developer documentation](https://docs.agent-swarm.dev) for architecture, installation, integrations, workflows, memory, and MCP tools. - Inspect the [source code and releases](https://github.com/desplega-ai/agent-swarm) on GitHub. - See [free MIT self-hosting and enterprise support](/pricing). - Follow practical implementation notes on the [Agent Swarm blog](/blog). ## Public channels Desplega Labs publishes Agent Swarm updates through [GitHub](https://github.com/desplega-ai), [X](https://x.com/agent__swarm), and [LinkedIn](https://www.linkedin.com/company/desplega-labs). The Agent Swarm community is also available on [Discord](https://discord.gg/KZgfyyDVZa). For a direct conversation, use the [contact page](/contact). --- # Contact Desplega Labs Contact **Desplega Labs, S.L.** at [contact@desplega.sh](mailto:contact@desplega.sh) for product questions, technical support, account questions, partnerships, and general inquiries. Agent Swarm is a free self-hosted project under MIT. You can also contact us about enterprise support. This is the authoritative public contact address for agent-swarm.dev and Desplega Labs, S.L. ## Choose the fastest path When contacting us about a technical problem, include the workspace or deployment involved, the Agent Swarm version, the deployment method you used, the affected command or route, what you were trying to do, what happened instead, and a minimal error message with secrets removed. For account questions, include the account email relevant to the request. Never send model-provider keys, API keys, access tokens, passwords, private keys, or other credentials by email. For an Enterprise evaluation, [book a conversation with the team](https://calendar.app.google/49DmjEXTPAv5NsRq6). Describe your deployment, including single-tenant deployment, VPC or on-premises requirements, and SSO or SAML. We can discuss support, an SLA, custom models, onboarding, and integrations. Services, scope, and pricing depend on your agreement. ## Privacy, security, and legal requests Use the public contact address above for privacy rights, GDPR or LOPDGDD questions, security reports, data-processing requests, and legal notices sent by email. Identify the nature of the request in the subject line so it reaches the right person. Privacy requests may require identity verification before Desplega Labs can disclose or change personal data. Standard email support does not carry a guaranteed response time unless a signed Enterprise order form says otherwise. Read the [Privacy Policy](/privacy) for site data handling and the policy for the former Cloud service. The applicable service terms are on the [Terms and Conditions](/terms) page. ## Registered office Formal notices sent by post should be addressed to: **Desplega Labs, S.L.** - Tuset 3, planta 5 - 08006 Barcelona - Spain Desplega Labs, S.L. is registered at the Registro Mercantil de Barcelona with CIF B27645381. The postal address is for legal and company correspondence; product support is fastest through the contact channel above. ## Self-service and community resources Before writing, agents and developers can inspect the [developer documentation](https://docs.agent-swarm.dev), [official CLI reference](https://docs.agent-swarm.dev/docs/reference/cli), [pricing](/pricing), and [llms.txt](/llms.txt). Source-level questions, reproducible bugs, and release history belong with the [open-source repository](https://github.com/desplega-ai/agent-swarm), where the implementation and issue tracker are public. These sources cover installation, configuration, architecture, integrations, MCP tools, workflows, and common operational questions. For community discussion, join the [Agent Swarm Discord](https://discord.gg/KZgfyyDVZa). You can also follow Desplega Labs on [X](https://x.com/agent__swarm) and [LinkedIn](https://www.linkedin.com/company/desplega-labs). --- # Agent Swarm security and trust Agent Swarm is open source and self-hostable. In a self-hosted deployment, your own infrastructure holds the context, memory, logs, files, secrets, and model-provider keys that the system uses. This page separates the controls documented in the Agent Swarm repository from the configuration that remains the operator's responsibility, so that you can evaluate each claim against the source it comes from. ## Deployment and data control The recommended self-hosted deployment runs on Docker Compose, with a Kubernetes and Helm path documented separately. In this mode, the SQLite database that holds tasks, agent memory, and configuration lives on a volume you own, inside your environment. The same is true for logs and files produced by your agents. Model traffic follows the same boundary. Workers connect directly to the model provider you configure, using your provider keys. Agent Swarm does not impose a model vendor: you choose the provider, the model, and the account under which requests are billed and logged. Agent Swarm is free software under MIT. For enterprise support, [book a conversation](https://calendar.app.google/49DmjEXTPAv5NsRq6). We can discuss support, an SLA, SSO, custom models, and integrations. Agree the services and security requirements for your deployment with the team. For setup detail, see the [deployment guide](https://docs.agent-swarm.dev/docs/guides/deployment) and the [Kubernetes guide](https://docs.agent-swarm.dev/docs/guides/kubernetes). ## Runtime isolation Each worker runs in its own container, and each agent gets a private `/workspace/personal` workspace. One agent's running processes and personal files are not shared with another agent's. The shared volume is the deliberate exception: `/workspace/shared` is one volume mounted into every agent and readable across agents, so that agents can exchange research, plans, and context. Treat anything written there as visible to every agent in the swarm, and keep agent-specific files in the personal workspace. What happens outside those containers belongs to you. Network exposure, HTTPS termination, and firewalling are operator-owned decisions. Whether you terminate TLS with a reverse proxy you already run, and which ports reach the public internet, are your choices to make and to audit. Version pinning is also your decision, and the default deserves attention. Leaving `AGENT_SWARM_VERSION` blank tracks the `:latest` image tag, which is rebuilt and moved on every commit to `main` — it is not a release. Pin a specific release version in anything you depend on. Upgrades deserve the same care. Database migrations are forward-only: re-pinning to an older tag does not roll back a schema change, but a database backup taken before the upgrade does. Back up first, upgrade, then verify with the `/health` endpoint and one completed task rather than `/health` alone. ## Secrets and access Secrets stored in the Agent Swarm config store — API tokens, OAuth credentials, credential pools, and anything else marked secret — are encrypted at rest with AES-256-GCM. The encryption key is resolved in a documented order: the `SECRETS_ENCRYPTION_KEY` environment variable, then `SECRETS_ENCRYPTION_KEY_FILE` pointing to a key file, then an `.encryption-key` file on the data volume, which the system generates on first boot if neither variable is set. That design puts one obligation squarely on the operator: back up the key material alongside the database. A lost key means the encrypted secrets are unrecoverable — there is no recovery path, and key rotation is not yet supported. Two values are never accepted into the config store at all: `API_KEY` and `SECRETS_ENCRYPTION_KEY` are rejected from the store, so the master credentials cannot be written into the store they protect. The [secrets encryption guide](https://docs.agent-swarm.dev/docs/guides/secrets-encryption) documents what key material to back up and which keys are reserved. Access to the API itself uses one shared operator `API_KEY` across all services. Every service that can reach the API with that key has operator-level access; treat the key accordingly. Single sign-on is handled outside the application, by oauth2-proxy in front of the dashboard. Mode 1 is a gate only: users authenticate with your identity provider, and the swarm still sees the one shared `API_KEY`, with no per-user attribution at the API layer. Mode 2, trusted-header mode, additionally forwards `X-Forwarded-User`, `X-Forwarded-Email`, and `X-Forwarded-Groups` headers to the API, establishing the identity pipeline for per-user attribution as the application layer evolves. In both modes the security property is the same: only the proxy may set those headers, so the API must never be reachable except through the proxy. The [SSO guide](https://docs.agent-swarm.dev/docs/guides/self-hosted-sso) walks through both configurations. Role-based access control is on by default: `RBAC_ENABLED` defaults to `true`. RBAC gates REST requests authenticated with `aswt_` user tokens. Requests authenticated with the operator API key, and calls made by agents themselves, are not gated by it. There are two built-in roles, `admin` and `requester`, and every user currently receives `admin` by default — there is no API or UI to assign roles yet. If role assignment matters to your deployment, track and upvote it on the [public feedback board](https://feedback.agent-swarm.dev/p/user-rbac). The full flag list lives in the [environment variables reference](https://docs.agent-swarm.dev/docs/reference/environment-variables). ## Operational evidence Agent Swarm can emit OpenTelemetry traces and OTLP metrics from the API server and the worker runners. OpenTelemetry export is off by default and turns on when `OTEL_EXPORTER_OTLP_ENDPOINT` is set; the data goes to the OTLP-compatible backend you choose, under your account and your retention policy. The [observability guide](https://docs.agent-swarm.dev/docs/guides/observability-opentelemetry) describes the spans and metrics emitted. Separately, Agent Swarm sends usage telemetry to the maintainers to help them understand how the product is used. That telemetry is on by default, and it never sends task content, prompts, outputs, full email addresses, user names, agent names, or raw user IDs: a person appears only as a hashed reference that stays stable inside your install and cannot be reversed. It is not anonymous at the organization level. Each event carries an organization ID (`SWARM_ORG_ID` when set to a valid ID, otherwise one generated once and stored as `telemetry_org_id`), the organization name when you set `SWARM_ORG_NAME`, and the email domain of your admin, such as `example.com`, never the full address. Events can therefore be attributed to your organization. To opt out, set `ANONYMIZED_TELEMETRY=false` on the API server and on every worker; each process checks the flag independently. The [telemetry reference](https://docs.agent-swarm.dev/docs/reference/telemetry) lists exactly what each event contains, and its [identity-context section](https://docs.agent-swarm.dev/docs/reference/telemetry#identity-context) defines every field in that envelope. The table below restates the boundary this whole page is about. | Documented control | Customer-owned configuration | | --- | --- | | Config-store secrets encrypted at rest with AES-256-GCM | Choosing the key source, backing up the key with the database | | Workers in separate containers, each with a private `/workspace/personal` workspace | Host hardening, HTTPS termination, network exposure, firewall rules | | SSO via oauth2-proxy in gate-only or trusted-header mode | Running the proxy; keeping the API reachable only through it | | `AGENT_SWARM_VERSION` pinning support and published release tags | Pinning a release in production, backups before upgrades | | RBAC on by default for `aswt_` user tokens | Who receives user tokens, and which roles they hold | | OpenTelemetry export from API and workers, off by default | The telemetry backend, its access controls, and retention | | Usage telemetry to the maintainers, on by default, with organization-level attribution | Keeping it on, or opting out on the API server and every worker | A control appearing in the left column means it is implemented and documented in the repository. It does not mean the corresponding operational duty on the right is done for you. ## Limits and contact This page claims no certifications — not SOC 2, not ISO 27001, not any other. It claims no regulatory compliance, including GDPR and HIPAA, and no specific data-retention periods, and it does not describe a penetration test. Where a compliance question depends on how you configure your own deployment, the sections above describe which parts of that configuration are yours. Before you rely on a self-hosted deployment, validate it against this checklist: - A specific release is pinned in `AGENT_SWARM_VERSION`, not blank. - The encryption key is set explicitly through `SECRETS_ENCRYPTION_KEY` or `SECRETS_ENCRYPTION_KEY_FILE`, and the key material is backed up with the database. - The API is reachable only over HTTPS, through your proxy. - SSO via oauth2-proxy sits in front of the dashboard, and the API is not reachable except through the proxy. - `/health` returns successfully and at least one task has completed end to end. Send security questions to contact@desplega.sh, including questions about services proposed in an enterprise agreement. You can also reach the team through the [contact page](/contact). Agent Swarm is developed in the open at [github.com/desplega-ai/agent-swarm](https://github.com/desplega-ai/agent-swarm), where the code behind every control named here can be read and audited. For background on the team, see [about](/about); for how this website itself handles data, see the [privacy policy](/privacy). For a longer treatment of the self-hosted security model, in Spanish, read Seguridad en IA autohospedada. --- # Agent Swarm developer resources Agent Swarm is open source and self-hosted. Each deployment runs its own REST API and MCP server, so there is no shared production endpoint to call. This page lists where each Agent Swarm developer resource lives, at stable URLs, for developers and for coding agents. ## Agent Swarm API documentation - [Agent Swarm REST API reference](https://docs.agent-swarm.dev/docs/api-reference) covers the endpoints of a deployment: tasks, agents, workflows, memory, schedules, and webhooks. - [Agent Swarm OpenAPI specification](https://github.com/desplega-ai/agent-swarm/blob/main/openapi.json) is the machine-readable contract for the runtime API, kept in the open-source repository. A running deployment serves the same document from its own API host. - [Typed TypeScript client](https://docs.agent-swarm.dev/docs/api-reference/typescript) shows how to generate request and response types from that specification. ## Agent Swarm API authentication - [API keys](https://docs.agent-swarm.dev/docs/api-reference/api-keys) explains how a deployment issues the bearer keys that authenticate REST and MCP requests. - [Self-hosted SSO](https://docs.agent-swarm.dev/docs/guides/self-hosted-sso) protects the dashboard and API with your identity provider through oauth2-proxy or trusted headers. - [OAuth for connections](https://docs.agent-swarm.dev/docs/api-reference/oauth) covers the OAuth flows a deployment uses to connect to third-party APIs and MCP servers. ## Agent Swarm webhooks - [Webhooks API](https://docs.agent-swarm.dev/docs/api-reference/webhooks) documents inbound webhooks that turn external events into tasks and workflow runs. - [GitHub](https://docs.agent-swarm.dev/docs/integrations/github), [GitLab](https://docs.agent-swarm.dev/docs/integrations/gitlab) and [Linear](https://docs.agent-swarm.dev/docs/integrations/linear) integrations show the webhook setup for each provider. ## Agent Swarm MCP server - [MCP tools reference](https://docs.agent-swarm.dev/docs/reference/mcp-tools) lists the tools a deployment exposes over Streamable HTTP at `https:///mcp`. - [Harness configuration](https://docs.agent-swarm.dev/docs/guides/harness-configuration) shows the headers an MCP client sends: a bearer API key, an agent ID, and a task ID. - [MCP server descriptor](/.well-known/mcp.json) is the machine-readable server metadata for that deployment-specific endpoint. ## Agent Swarm CLI The official CLI is published on npm as [`@desplega.ai/agent-swarm`](https://www.npmjs.com/package/@desplega.ai/agent-swarm). It installs the `agent-swarm` command. Run it without a global install with `npx @desplega.ai/agent-swarm onboard`, or `bunx @desplega.ai/agent-swarm onboard` with Bun. The [CLI reference](https://docs.agent-swarm.dev/docs/reference/cli) lists every command. ## Agent Swarm resources for coding agents - [Operator skill](/skill.md) teaches a coding agent to install, deploy, operate, and use a self-hosted swarm. Install it with `npx skills add desplega-ai/agent-swarm`. - [Agent Skills index](/.well-known/agent-skills/index.json) lists the operator skill and the [when-to-use guide](/.well-known/agent-skills/agent-swarm-when-to-use/SKILL.md), with SHA-256 digests. - [llms.txt](/llms.txt) is the navigation index for this site, and [AI catalog](/.well-known/ai-catalog.json) lists every agent-facing resource on this domain. ## Website utility API This marketing site also serves a small unauthenticated API: a JSON index at [/api](/api), a consent-region lookup, the Open Graph image renderer, and read-only public content endpoints under `/api/v1` that mirror the public MCP server at `/mcp`. Its [OpenAPI description](/openapi.json) and [versioning policy](/api-versioning.md) are separate from the runtime API above. --- # Agent Swarm install ranking Opted-in Agent Swarm installs, ranked by tokens. Updated every minute. The page follows OpenRouter's app rankings: the most popular installs over the last 30 days, the fastest growing over the last 7 days, and the top installs per category (engineering, product, marketing, support, operations). Each category page charts tokens by install over the last year and lists every install, filterable by subcategory and by today, the last 7 days or the last 30 days (UTC days, today included). Each install's page shows its total tokens, daily global rank, active-since month, models used, usage stacked by model, and its top models over the last 30 days. Installs that joined in the last 7 days carry a New badge. Coming soon. Ranking is opt-in: an admin of an [agent-swarm](https://github.com/desplega-ai/agent-swarm) install with telemetry on clicks Get ranked, and the install shows within about two minutes once its finished worker sessions count tokens in the period. We rank by tokens only. The live list is served as JSON at [proxy.desplega.sh/v1/ranking](https://proxy.desplega.sh/v1/ranking), in OpenRouter's app-ranking schema. ## Get your swarm ranked Ranking is opt-in and needs telemetry on. [Read how to opt in](https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking), or copy this prompt and send it to your swarm lead. It asks you for the listing details, then sets up the opt-in. ```text Opt our Agent Swarm install into the public ranking at agent-swarm.dev/ranking. Docs: https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking 1. Use request-human-input to ask me for: organization name (60 characters max), company website as a bare hostname (example.com), ranking category (engineering, product, marketing, support, operations or other), and optionally a subcategory, a one-line description (160 characters max) and an https source code URL. Ask me to confirm that our token totals will be public. Without a yes, stop. 2. Set SWARM_ORG_NAME and SWARM_ORG_WEBSITE with set-config, and check ANONYMIZED_TELEMETRY is not false. 3. As the lead, call POST /api/ranking/opt-in with { category, subcategory, description, sourceCodeUrl }. Do not set PUBLIC_RANKING_ENABLED or telemetry_ranking yourself. If you cannot call it, ask me to click Get ranked in Settings → Configuration → Branding. 4. Reply with the listing you sent. ``` --- # All installs, ranked by tokens Every opted-in Agent Swarm install, ranked by tokens. Updated every minute. Back to the [install ranking](/ranking). The page charts weekly tokens by install over the last year and lists every install, filterable by today, the last 7 days or the last 30 days (UTC days, today included). Each install links to its own page. Coming soon. Ranking is opt-in: an admin of an [agent-swarm](https://github.com/desplega-ai/agent-swarm) install with telemetry on clicks Get ranked, and the install shows within about two minutes once its finished worker sessions count tokens in the period. We rank by tokens only. The live list is served as JSON at [proxy.desplega.sh/v1/ranking](https://proxy.desplega.sh/v1/ranking), in OpenRouter's app-ranking schema. ## Get your swarm ranked Ranking is opt-in and needs telemetry on. [Read how to opt in](https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking), or copy this prompt and send it to your swarm lead. It asks you for the listing details, then sets up the opt-in. ```text Opt our Agent Swarm install into the public ranking at agent-swarm.dev/ranking. Docs: https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking 1. Use request-human-input to ask me for: organization name (60 characters max), company website as a bare hostname (example.com), ranking category (engineering, product, marketing, support, operations or other), and optionally a subcategory, a one-line description (160 characters max) and an https source code URL. Ask me to confirm that our token totals will be public. Without a yes, stop. 2. Set SWARM_ORG_NAME and SWARM_ORG_WEBSITE with set-config, and check ANONYMIZED_TELEMETRY is not false. 3. As the lead, call POST /api/ranking/opt-in with { category, subcategory, description, sourceCodeUrl }. Do not set PUBLIC_RANKING_ENABLED or telemetry_ranking yourself. If you cannot call it, ask me to click Get ranked in Settings → Configuration → Branding. 4. Reply with the listing you sent. ``` --- # Engineering, ranked by tokens Opted-in Agent Swarm installs in the Engineering category, ranked by tokens. Updated every minute. Back to the [install ranking](/ranking). The page charts weekly tokens by install over the last year and lists every install, filterable by subcategory (Coding agents, QA and testing, DevOps, Code review) and by today, the last 7 days or the last 30 days (UTC days, today included). Each install links to its own page. Coming soon. Ranking is opt-in: an admin of an [agent-swarm](https://github.com/desplega-ai/agent-swarm) install with telemetry on clicks Get ranked, and the install shows within about two minutes once its finished worker sessions count tokens in the period. We rank by tokens only. The live list is served as JSON at [proxy.desplega.sh/v1/ranking?group=engineering](https://proxy.desplega.sh/v1/ranking?group=engineering), in OpenRouter's app-ranking schema. ## Get your swarm ranked Ranking is opt-in and needs telemetry on. [Read how to opt in](https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking), or copy this prompt and send it to your swarm lead. It asks you for the listing details, then sets up the opt-in. ```text Opt our Agent Swarm install into the public ranking at agent-swarm.dev/ranking. Docs: https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking 1. Use request-human-input to ask me for: organization name (60 characters max), company website as a bare hostname (example.com), ranking category (engineering, product, marketing, support, operations or other), and optionally a subcategory, a one-line description (160 characters max) and an https source code URL. Ask me to confirm that our token totals will be public. Without a yes, stop. 2. Set SWARM_ORG_NAME and SWARM_ORG_WEBSITE with set-config, and check ANONYMIZED_TELEMETRY is not false. 3. As the lead, call POST /api/ranking/opt-in with { category, subcategory, description, sourceCodeUrl }. Do not set PUBLIC_RANKING_ENABLED or telemetry_ranking yourself. If you cannot call it, ask me to click Get ranked in Settings → Configuration → Branding. 4. Reply with the listing you sent. ``` --- # Product, ranked by tokens Opted-in Agent Swarm installs in the Product category, ranked by tokens. Updated every minute. Back to the [install ranking](/ranking). The page charts weekly tokens by install over the last year and lists every install, filterable by subcategory (Research, Design, Analytics) and by today, the last 7 days or the last 30 days (UTC days, today included). Each install links to its own page. Coming soon. Ranking is opt-in: an admin of an [agent-swarm](https://github.com/desplega-ai/agent-swarm) install with telemetry on clicks Get ranked, and the install shows within about two minutes once its finished worker sessions count tokens in the period. We rank by tokens only. The live list is served as JSON at [proxy.desplega.sh/v1/ranking?group=product](https://proxy.desplega.sh/v1/ranking?group=product), in OpenRouter's app-ranking schema. ## Get your swarm ranked Ranking is opt-in and needs telemetry on. [Read how to opt in](https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking), or copy this prompt and send it to your swarm lead. It asks you for the listing details, then sets up the opt-in. ```text Opt our Agent Swarm install into the public ranking at agent-swarm.dev/ranking. Docs: https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking 1. Use request-human-input to ask me for: organization name (60 characters max), company website as a bare hostname (example.com), ranking category (engineering, product, marketing, support, operations or other), and optionally a subcategory, a one-line description (160 characters max) and an https source code URL. Ask me to confirm that our token totals will be public. Without a yes, stop. 2. Set SWARM_ORG_NAME and SWARM_ORG_WEBSITE with set-config, and check ANONYMIZED_TELEMETRY is not false. 3. As the lead, call POST /api/ranking/opt-in with { category, subcategory, description, sourceCodeUrl }. Do not set PUBLIC_RANKING_ENABLED or telemetry_ranking yourself. If you cannot call it, ask me to click Get ranked in Settings → Configuration → Branding. 4. Reply with the listing you sent. ``` --- # Marketing, ranked by tokens Opted-in Agent Swarm installs in the Marketing category, ranked by tokens. Updated every minute. Back to the [install ranking](/ranking). The page charts weekly tokens by install over the last year and lists every install, filterable by subcategory (Content, SEO, Social) and by today, the last 7 days or the last 30 days (UTC days, today included). Each install links to its own page. Coming soon. Ranking is opt-in: an admin of an [agent-swarm](https://github.com/desplega-ai/agent-swarm) install with telemetry on clicks Get ranked, and the install shows within about two minutes once its finished worker sessions count tokens in the period. We rank by tokens only. The live list is served as JSON at [proxy.desplega.sh/v1/ranking?group=marketing](https://proxy.desplega.sh/v1/ranking?group=marketing), in OpenRouter's app-ranking schema. ## Get your swarm ranked Ranking is opt-in and needs telemetry on. [Read how to opt in](https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking), or copy this prompt and send it to your swarm lead. It asks you for the listing details, then sets up the opt-in. ```text Opt our Agent Swarm install into the public ranking at agent-swarm.dev/ranking. Docs: https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking 1. Use request-human-input to ask me for: organization name (60 characters max), company website as a bare hostname (example.com), ranking category (engineering, product, marketing, support, operations or other), and optionally a subcategory, a one-line description (160 characters max) and an https source code URL. Ask me to confirm that our token totals will be public. Without a yes, stop. 2. Set SWARM_ORG_NAME and SWARM_ORG_WEBSITE with set-config, and check ANONYMIZED_TELEMETRY is not false. 3. As the lead, call POST /api/ranking/opt-in with { category, subcategory, description, sourceCodeUrl }. Do not set PUBLIC_RANKING_ENABLED or telemetry_ranking yourself. If you cannot call it, ask me to click Get ranked in Settings → Configuration → Branding. 4. Reply with the listing you sent. ``` --- # Support, ranked by tokens Opted-in Agent Swarm installs in the Support category, ranked by tokens. Updated every minute. Back to the [install ranking](/ranking). The page charts weekly tokens by install over the last year and lists every install, filterable by subcategory (Customer support, Docs) and by today, the last 7 days or the last 30 days (UTC days, today included). Each install links to its own page. Coming soon. Ranking is opt-in: an admin of an [agent-swarm](https://github.com/desplega-ai/agent-swarm) install with telemetry on clicks Get ranked, and the install shows within about two minutes once its finished worker sessions count tokens in the period. We rank by tokens only. The live list is served as JSON at [proxy.desplega.sh/v1/ranking?group=support](https://proxy.desplega.sh/v1/ranking?group=support), in OpenRouter's app-ranking schema. ## Get your swarm ranked Ranking is opt-in and needs telemetry on. [Read how to opt in](https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking), or copy this prompt and send it to your swarm lead. It asks you for the listing details, then sets up the opt-in. ```text Opt our Agent Swarm install into the public ranking at agent-swarm.dev/ranking. Docs: https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking 1. Use request-human-input to ask me for: organization name (60 characters max), company website as a bare hostname (example.com), ranking category (engineering, product, marketing, support, operations or other), and optionally a subcategory, a one-line description (160 characters max) and an https source code URL. Ask me to confirm that our token totals will be public. Without a yes, stop. 2. Set SWARM_ORG_NAME and SWARM_ORG_WEBSITE with set-config, and check ANONYMIZED_TELEMETRY is not false. 3. As the lead, call POST /api/ranking/opt-in with { category, subcategory, description, sourceCodeUrl }. Do not set PUBLIC_RANKING_ENABLED or telemetry_ranking yourself. If you cannot call it, ask me to click Get ranked in Settings → Configuration → Branding. 4. Reply with the listing you sent. ``` --- # Operations, ranked by tokens Opted-in Agent Swarm installs in the Operations category, ranked by tokens. Updated every minute. Back to the [install ranking](/ranking). The page charts weekly tokens by install over the last year and lists every install, filterable by subcategory (Back office, Sales ops, Finance) and by today, the last 7 days or the last 30 days (UTC days, today included). Each install links to its own page. Coming soon. Ranking is opt-in: an admin of an [agent-swarm](https://github.com/desplega-ai/agent-swarm) install with telemetry on clicks Get ranked, and the install shows within about two minutes once its finished worker sessions count tokens in the period. We rank by tokens only. The live list is served as JSON at [proxy.desplega.sh/v1/ranking?group=operations](https://proxy.desplega.sh/v1/ranking?group=operations), in OpenRouter's app-ranking schema. ## Get your swarm ranked Ranking is opt-in and needs telemetry on. [Read how to opt in](https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking), or copy this prompt and send it to your swarm lead. It asks you for the listing details, then sets up the opt-in. ```text Opt our Agent Swarm install into the public ranking at agent-swarm.dev/ranking. Docs: https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking 1. Use request-human-input to ask me for: organization name (60 characters max), company website as a bare hostname (example.com), ranking category (engineering, product, marketing, support, operations or other), and optionally a subcategory, a one-line description (160 characters max) and an https source code URL. Ask me to confirm that our token totals will be public. Without a yes, stop. 2. Set SWARM_ORG_NAME and SWARM_ORG_WEBSITE with set-config, and check ANONYMIZED_TELEMETRY is not false. 3. As the lead, call POST /api/ranking/opt-in with { category, subcategory, description, sourceCodeUrl }. Do not set PUBLIC_RANKING_ENABLED or telemetry_ranking yourself. If you cannot call it, ask me to click Get ranked in Settings → Configuration → Branding. 4. Reply with the listing you sent. ``` --- # Other, ranked by tokens Opted-in Agent Swarm installs in the Other category, ranked by tokens. Updated every minute. Back to the [install ranking](/ranking). The page charts weekly tokens by install over the last year and lists every install, filterable by today, the last 7 days or the last 30 days (UTC days, today included). Each install links to its own page. Coming soon. Ranking is opt-in: an admin of an [agent-swarm](https://github.com/desplega-ai/agent-swarm) install with telemetry on clicks Get ranked, and the install shows within about two minutes once its finished worker sessions count tokens in the period. We rank by tokens only. The live list is served as JSON at [proxy.desplega.sh/v1/ranking?group=other](https://proxy.desplega.sh/v1/ranking?group=other), in OpenRouter's app-ranking schema. ## Get your swarm ranked Ranking is opt-in and needs telemetry on. [Read how to opt in](https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking), or copy this prompt and send it to your swarm lead. It asks you for the listing details, then sets up the opt-in. ```text Opt our Agent Swarm install into the public ranking at agent-swarm.dev/ranking. Docs: https://docs.agent-swarm.dev/docs/reference/telemetry#public-ranking 1. Use request-human-input to ask me for: organization name (60 characters max), company website as a bare hostname (example.com), ranking category (engineering, product, marketing, support, operations or other), and optionally a subcategory, a one-line description (160 characters max) and an https source code URL. Ask me to confirm that our token totals will be public. Without a yes, stop. 2. Set SWARM_ORG_NAME and SWARM_ORG_WEBSITE with set-config, and check ANONYMIZED_TELEMETRY is not false. 3. As the lead, call POST /api/ranking/opt-in with { category, subcategory, description, sourceCodeUrl }. Do not set PUBLIC_RANKING_ENABLED or telemetry_ranking yourself. If you cannot call it, ask me to click Get ranked in Settings → Configuration → Branding. 4. Reply with the listing you sent. ``` --- # Privacy Policy **Version:** v3.4 **Effective date:** 2026-05-07 **Last updated:** 2026-08-18 > **Offering update (2026-10-12).** Agent Swarm Cloud is no longer offered. Agent Swarm is free software under MIT. Enterprise support is available [by conversation](https://calendar.app.google/49DmjEXTPAv5NsRq6), with services and scope agreed separately. Cloud references below describe the former service. This notice does not change existing contractual obligations or data-protection commitments. > **Scope.** This Privacy Policy covers the marketing and documentation website at [agent-swarm.dev](https://www.agent-swarm.dev) (the "Site") and the Agent Swarm Cloud platform at `cloud.agent-swarm.dev` (the "Cloud Service"). Together, the Site and the Cloud Service are the "Service." This Privacy Policy explains how Desplega Labs, S.L. ("we," "us," "our," "Desplega Labs," or the "Company") collects, uses, and protects information when you use the Service. The Company acts in different roles depending on the data: - **Data Controller** for account, billing, security, marketing, and analytics data we collect about you as a customer or visitor. - **Data Processor** for the data your agents ingest, generate, and store inside the Cloud Service on your instruction (your "Customer Data"). You are the controller of that data. See Section 5 and Section 6. --- ## 1. Data Controller and Contact **Desplega Labs, S.L.**, a Spanish private limited company (*sociedad de responsabilidad limitada*) with registered office at Tuset 3, planta 5, 08006 Barcelona, Spain, registered at the Registro Mercantil de Barcelona, CIF B27645381 (the "Company", "Desplega Labs", "we", "us", "our"). - **Contact for privacy questions, GDPR rights, complaints, and all other inquiries:** `contact@desplega.sh` - **Postal address for legal notices:** Desplega Labs, S.L., Tuset 3, planta 5, 08006 Barcelona, Spain. A Data Protection Officer has not been appointed; if Spanish counsel determines one is required under LOPDGDD/GDPR, the contact will be added here. --- ## 2. Information We Collect ### 2.1 Account Information When you sign up through Clerk (our authentication provider), we receive and store: - Your name and email address - Clerk user ID and organization ID - Organization name and membership details - Authentication metadata (login timestamps, IP addresses of authentication events) ### 2.2 Billing Information When you subscribe through Stripe (our payment processor), we store: - Stripe customer ID and subscription ID - Subscription status, plan, and billing-cycle metadata - Billing address and tax identifiers if you provide them - Invoices and payment-history references We do **not** store your card number, bank account, or other payment instruments. These are handled directly by Stripe under its own privacy policy. ### 2.3 Agent Configuration and Activity Data (Customer Data) When you operate swarms through the Cloud Service, we host and process on your behalf: - Swarm and agent configuration (roles, names, system prompts, tools, schedules) - Agent activity (task logs, messages, memory entries, file events, hook events) - Files and content generated by your agents and stored on the Service's shared and personal disks - Usage and resource-consumption metrics (machine uptime, token counts, request counts, billing-relevant events) This data lives in per-tenant databases on the virtual machines and servers we provision for you. With respect to this category, **we act as a data processor** on your behalf — see Section 5. ### 2.4 Integration Data If you connect third-party services to your swarm (Slack, GitHub, GitLab, Linear, AgentMail, custom MCP servers, etc.), we store on your behalf: - OAuth credentials and refresh tokens, encrypted at rest using AES-256-GCM - The minimum installation metadata required to operate each integration (workspace name, organization name, channel/repo identifiers, account email) - Messages, events, files, and other payloads delivered to your swarm by those services on your instruction (e.g., a Slack message that triggers a task, a GitHub webhook that opens an issue, an email received by an AgentMail inbox) We process integration data solely to operate the Service on your behalf. **The third-party services themselves are not Desplega sub-processors** — they are services *you* connect under *your* contracts and credentials. See Section 6, Group C. ### 2.5 Model and AI Provider Data When your agents call AI providers (Anthropic / Claude API, OpenAI, OpenRouter, Codex, OpenCode, or any other provider you configure), the prompts and outputs of those calls travel to that provider under that provider's terms, using **your** API keys. We act only as a passthrough for the credentials you provide. We do not retain a separate copy beyond what your swarm stores in its own logs and memory. **Those AI providers are not Desplega sub-processors.** See Section 6, Group C. ### 2.6 Technical Data We collect minimal technical data to operate the Service: - IP addresses (logged by our infrastructure providers) - Browser type, version, and standard HTTP headers - Error logs, traces, and crash reports ### 2.7 Analytics and Cookies - The **Site** uses **Plausible** (privacy-friendly, cookieless) for basic analytics, and — only if you accept non-essential cookies — **Google Analytics 4** and **PostHog** (self-hosted at `tt.desplega.sh`) for site and product/visitor analytics and the **X (Twitter) Ads conversion pixel** for advertising measurement. See Section 4.2. - The **Cloud Service dashboard** uses **PostHog** to capture product-analytics events (page views, feature usage, sign-up funnel events) so we can measure reliability and usability. - **Sentry** captures error and crash reports across the Service. - Authentication uses Clerk session cookies; the dashboard sets a small number of functional cookies (e.g., `sidebar_state`). The Site uses Google Analytics 4 for consent-gated site analytics and the X (Twitter) conversion pixel for consent-gated advertising measurement (Section 4.2). It runs no other advertising or social-media trackers, we do not use ad-network retargeting, and we do not build our own cross-site advertising profiles. See the cookie tables in Section 4. ### 2.8 Communications If you contact us by email, fill out a form, or reply through Slack/email integrations operated by us, we retain the content of those communications and the email addresses involved for support and recordkeeping. --- ## 3. How We Use Your Information We use the information we collect to: - **Operate the Service** — provision infrastructure, run your agent swarms, deliver integration events, and display data in the dashboard. - **Process billing** — manage subscriptions, charge invoices, handle taxes, and send receipts through Stripe. - **Authenticate users** — verify identity and protect accounts via Clerk. - **Provide support** — respond to questions, troubleshoot incidents, and communicate maintenance. - **Maintain security** — detect and prevent unauthorized access, fraud, abuse, and platform abuse. - **Improve the Service** — understand usage patterns and reliability through analytics. - **Comply with law** — meet our legal, accounting, tax, and commercial-registry obligations under Spanish and EU law. We do **not**: - Use your data or your Customer Data to train AI models (ours or anyone else's). - Serve third-party advertising on the Service. - Set advertising, analytics, or social-media cookies without your consent — Google Analytics 4, PostHog, and the X (Twitter) conversion pixel load only if you accept (see Section 4.2). - Sell your personal information. With your consent, the X advertising pixel shares limited conversion signals with X Corp.; you can decline this or withdraw at any time (see Section 4.2). --- ## 4. Legal Basis for Processing (GDPR / LOPDGDD) We are subject to the EU General Data Protection Regulation 2016/679 ("GDPR") and the Spanish Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de los derechos digitales ("LOPDGDD"). Our legal bases: | Activity | Legal basis | |---|---| | Operating the Cloud Service for paying customers | **Contract performance** (Art. 6(1)(b)) | | Operating the Site (marketing pages, docs) | **Legitimate interest** in running our business (Art. 6(1)(f)) | | Billing, accounting, tax records | **Legal obligation** (Art. 6(1)(c)) — Spanish Commercial Code, General Tax Law, VAT regulations | | Security, fraud prevention, abuse detection | **Legitimate interest** (Art. 6(1)(f)) | | Cookieless analytics (Plausible) on the Site, and product analytics on the dashboard | **Legitimate interest** (Art. 6(1)(f)) — opt-out available; see Section 8 | | Google Analytics 4, PostHog analytics, and the X (Twitter) advertising pixel on the Site | **Consent** (Art. 6(1)(a)) — via the cookie banner; withdraw any time (see Section 4.2) | | Marketing emails to existing customers about similar services | **Legitimate interest** with opt-out | | Marketing emails to non-customers | **Consent** (Art. 6(1)(a)) | You can object to processing based on legitimate interest at any time at `contact@desplega.sh`. ### 4.1 Cookies and Similar Technologies | Cookie / token | Purpose | Set by | Type | |---|---|---|---| | Clerk session cookies (`__session`, etc.) | Authentication | Clerk | Strictly necessary | | `sidebar_state` | Remembers sidebar open/closed | Cloud Service | Functional | | Plausible (no cookie) | Cookieless analytics | Plausible | Analytics (no personal data) | | `_ga`, `_ga_*` | Site analytics and visitor/session measurement | [Google](https://policies.google.com/privacy) | Analytics — consent required on the Site | | `ph_*` (PostHog, self-hosted at `tt.desplega.sh`) | Product and visitor analytics | PostHog | Analytics — consent required on the Site | | X conversion pixel (`uwt.js`, pixel `qqtw4`) | Advertising / conversion measurement | X Corp. (Twitter) | Advertising — consent required | | Stripe cookies (during checkout/portal) | Fraud prevention and payment processing | Stripe | Strictly necessary | Google Analytics 4 and the X (Twitter) conversion pixel above load only if you accept non-essential cookies. We do not use other advertising or retargeting cookies, cross-site tracking cookies, or third-party social-media trackers. See Section 4.2 for what each Site tool does and how to withdraw consent. Visitors will see a cookie banner on first visit allowing you to accept all cookies or keep only essential, cookieless analytics, in line with the Spanish Ley 34/2002 de Servicios de la Sociedad de la Información (LSSI) and the ePrivacy Directive. You can change or withdraw your choice at any time via **Cookie settings** in the site footer. ### 4.2 Site Analytics, Advertising Measurement, and Cookie Consent The website at [agent-swarm.dev](https://www.agent-swarm.dev) uses four measurement tools. Only one — cookieless Plausible — runs regardless. In the EU, EEA, and UK, **Google Analytics 4, PostHog, and the X (Twitter) conversion pixel run only after you opt in through the cookie banner**; elsewhere, where a consent banner is not legally required, they load by default. Either way you can change or withdraw your choice at any time (see below). **Plausible — essential, always on.** Privacy-friendly, **cookieless** web analytics. Plausible counts page views and referrers using aggregated, anonymized data. It sets no cookies, stores nothing in your browser, collects no personal data, and performs no cross-site or cross-device tracking. Because it cannot identify you, it runs without consent. Privacy policy: [plausible.io/privacy](https://plausible.io/privacy). **Google Analytics 4 — requires consent.** Site analytics provided by **Google** using measurement ID `G-CYQBQKLK0X`. When enabled, Google Analytics measures page views, sessions, referrers, and browser/device information and sets `_ga` and `_ga_*` cookies to distinguish visitors and sessions. It loads only if you accept non-essential cookies. Privacy policy: [policies.google.com/privacy](https://policies.google.com/privacy). **PostHog — requires consent.** Product analytics, **self-hosted by us at `tt.desplega.sh`**. When enabled, PostHog captures product-usage events (page views, clicks, outbound navigation) and may set cookies and use browser local storage to recognize a returning session. We use it only to understand how the Site is used; we do not use it to build cross-site advertising profiles. PostHog loads only if you accept non-essential cookies. Privacy policy: [posthog.com/privacy](https://posthog.com/privacy). **X (Twitter) Ads conversion pixel — requires consent.** Advertising and conversion measurement. We load the X advertising tag (`uwt.js`, pixel ID `qqtw4`) to measure the effectiveness of campaigns we run on X. When active, it sets cookies and shares conversion signals (such as page visits and outbound product clicks) with **X Corp.**, which acts as an independent controller for that data and may use it for conversion measurement and audience building under its own policies. This is the only third-party advertising / social-media tracker on the Site, and it loads only if you accept non-essential cookies. Privacy policy: [x.com/en/privacy](https://x.com/en/privacy). **Cookie consent banner.** On your first visit from the EU, EEA, or UK you will see a cookie banner with two choices: - **OK** (accept all) — enables cookieless Plausible **plus** Google Analytics 4, PostHog, and the X conversion pixel. - **Opt out (essential)** — keeps only the cookieless Plausible analytics; Google Analytics 4, PostHog, and the X pixel stay off and set no cookies. Outside the EU/EEA/UK the banner is not shown and these tools load by default; you can still opt out at any time. Your choice is remembered for future visits. **You can change or withdraw your consent at any time** using the **Cookie settings** link in the site footer, which reopens the banner. Choosing *Opt out (essential)* stops Google Analytics 4, PostHog, and the X pixel going forward — Google Analytics disables collection and removes its `_ga` and `_ga_*` cookies, PostHog stops capturing and opts you out, and the X pixel is not loaded on future visits. Withdrawing consent does not affect data lawfully collected beforehand. Cookieless Plausible is consent-exempt — it sets no cookies, stores no personal data, and provides only aggregated, privacy-preserving traffic measurement — so it is not affected by your choice. | Cookie / tag | Purpose | Set by | Consent | Privacy policy | |---|---|---|---|---| | Plausible (no cookie) | Cookieless, aggregated site analytics | Plausible | Not required (essential) | [plausible.io/privacy](https://plausible.io/privacy) | | `_ga`, `_ga_*` | Site analytics and visitor/session measurement | Google | Required (non-essential) | [policies.google.com/privacy](https://policies.google.com/privacy) | | `ph_*` + local storage | Product-usage analytics | PostHog (self-hosted, `tt.desplega.sh`) | Required (non-essential) | [posthog.com/privacy](https://posthog.com/privacy) | | X conversion pixel (`uwt.js`, pixel `qqtw4`) | Advertising / conversion measurement | X Corp. (Twitter) | Required (non-essential) | [x.com/en/privacy](https://x.com/en/privacy) | --- ## 5. Our Role: Controller vs. Processor We act in **two different capacities**, and the GDPR rules differ between them. Spanish counsel should validate this split. - **Controller — for data we collect about you as a customer or visitor.** This includes account information (Section 2.1), billing information (Section 2.2), technical data (Section 2.6), analytics (Section 2.7), and communications with us (Section 2.8). For this data, this Privacy Policy governs. - **Processor — for the Customer Data your agents ingest, generate, and store on the Cloud Service** (Sections 2.3, 2.4, and 2.5). Here, **you** are the controller and we process on your documented instructions for the sole purpose of operating the Service. A separate **Data Processing Addendum (DPA)**, including the EU Standard Contractual Clauses where applicable, is available on request at `contact@desplega.sh`. --- ## 6. Sub-Processors We engage two groups of sub-processors who process personal data on our behalf, under our instructions, and pursuant to a written data-processing agreement (Art. 28 GDPR). A third group consists of *user-configured integrations*, which are NOT Desplega sub-processors. The distinction is legally significant — see Group C below. ### 6.1 Group A — First-party infrastructure & service providers (Desplega-controlled) These are the processors **we** use to run the platform. They are required for the Service to function. | Provider | Role | Data processed | Region | Transfer mechanism | |---|---|---|---|---| | **Clerk** | Authentication / identity | Account profiles, session metadata | United States | SCCs and EU–US Data Privacy Framework (verify DPF certification at publication) | | **Stripe** | Billing and payments | Customer profile, payment metadata, invoices | United States / Ireland | SCCs / DPF (verify) | | **Convex** | Application database / backend platform | Account, swarm, billing, integration metadata | United States | SCCs (verify hosting region and DPA) | | **Vercel** | Web hosting and edge runtime | Web requests for the dashboard and Site | United States (with global edge) | SCCs / DPF (verify DPF certification) | | **Hetzner** | Server hosting and compute infrastructure for swarms | Customer swarm runtime data | Germany (EU) | EU-EU; no cross-border transfer mechanism required | ### 6.2 Group B — Analytics & error tracking (Desplega-controlled, telemetry) | Provider | Role | Data processed | Region | Transfer mechanism | |---|---|---|---|---| | **Plausible** | Privacy-friendly product analytics | Anonymized, cookieless event data | Germany / Estonia (EU) | EU-EU; GDPR-aligned | | **Google** | Google Analytics 4 (`G-CYQBQKLK0X`) | Site analytics, pseudonymous visitor and session data | United States | SCCs / EU–US Data Privacy Framework | | **Sentry** | Error monitoring and crash reporting | Stack traces, sanitized request metadata | United States (EU region available — verify which deployment is in use) | SCCs / DPF (verify) | | **PostHog** | Product analytics / session intelligence | Pseudonymized usage events | Self-hosted by Desplega at `tt.desplega.sh` (verify host region) | Desplega-controlled deployment | Group A and Group B together form Desplega's controlled sub-processor stack. Per GDPR Art. 28(2)–(4), we will publish updates to the sub-processor list and give Customers reasonable advance notice of material additions or replacements in Group A or Group B. The current list will be maintained at `cloud.agent-swarm.dev/legal/subprocessors` (to be published). The **X (Twitter) advertising conversion pixel** used on the Site (Section 4.2) is **not** a sub-processor. X Corp. acts as an **independent controller** (and, for conversion measurement, potentially a joint controller) for the data it collects through the pixel, under its own privacy policy. It loads only with your consent and can be disabled at any time via **Cookie settings**. ### 6.3 Group C — User-configured integrations (NOT Desplega sub-processors) The third-party services your swarm interacts with — including but not limited to **Anthropic / Claude API, OpenAI, OpenRouter, Slack, GitHub, GitLab, Linear, AgentMail, and any other LLM, model provider, MCP server, or tool you connect** — are services **you** select and connect using **your own** accounts, contracts, and API credentials. For those services: - **Desplega does not have a controller/processor relationship with you** in respect of those services. - **Desplega does not execute DPAs with those vendors on your behalf.** You are responsible for entering into any required data-processing terms directly with them. - **Desplega acts only as a passthrough** for the API keys, OAuth tokens, and content the customer instructs the Service to send to those vendors. - **You are solely responsible** for compliance, billing, acceptable use, intellectual-property clearances, and any data-protection consequences of using those services. Use of those services is governed by their own terms and privacy policies. We are not liable for their availability, behavior, output, or policy changes (see the Terms and Conditions). --- ## 7. Data Retention ### 7.1 Active Accounts We retain account, configuration, and billing data for as long as your subscription is active. Agent runtime data persists on your provisioned infrastructure (VMs, storage) as long as those resources exist. ### 7.2 After Cancellation or Suspension When a subscription ends: - Swarm machines are stopped at the end of the billing period (or, where partial-period cancellation triggers a pro-rata refund, immediately upon refund processing). - Runtime data remains for a grace period of **up to 28 days** to allow re-subscription, export, or migration to self-hosting. - After the grace period, we may tear down the infrastructure and delete associated agent data. We will attempt to send a reminder email before deletion. ### 7.3 Account Metadata, Billing Records, and Statutory Retention Account metadata (org IDs, user IDs, subscription history, integration metadata, audit logs) is retained for up to **24 months** after account closure to handle disputes, comply with accounting/tax obligations, and prevent fraud. Mandatory retention periods under Spanish law apply notwithstanding deletion requests: - **Commercial books, accounts, supporting documents, invoices:** 6 years (Art. 30 Spanish Commercial Code / Código de Comercio). - **Tax records (VAT, corporate income tax):** 4 years from accrual (Art. 66 General Tax Law / Ley General Tributaria), extendable per anti-fraud rules. - Stripe invoices and underlying payment records are retained for the period required by applicable Spanish and EU tax law. Spanish counsel must validate the exact retention periods and any LOPDGDD-specific obligations. ### 7.4 Backups Infrastructure backups follow our underlying providers' schedules. We do not currently maintain independent application-level backups of customer agent runtime data beyond what exists on the live infrastructure. Where providers retain residual copies in backups beyond deletion, those copies expire on the provider's schedule. ### 7.5 Logs Operational logs (application errors, infrastructure logs, security events) are retained for **up to 90 days** and then deleted or anonymized. --- ## 8. Your Rights (GDPR / LOPDGDD) Subject to applicable law, you have the rights to: - **Access** — receive a copy of the personal data we hold about you. - **Rectification** — correct inaccurate personal data. - **Erasure / Deletion** — request deletion of your personal data, subject to limited exceptions (e.g., billing and tax records we must keep by law — see Section 7.3). - **Portability** — receive your data in a structured, machine-readable format. The agent-swarm.dev runtime is open-source under the MIT License; you may self-host and we will assist with export of your runtime data. - **Restriction** — restrict our processing while a request is pending. - **Objection** — object to processing based on legitimate interest, including direct marketing. - **Withdraw consent** — where processing is based on consent. - **Not be subject to automated individual decision-making** producing legal or similarly significant effects (Art. 22 GDPR). - **Lodge a complaint** with the Spanish supervisory authority (Agencia Española de Protección de Datos, [www.aepd.es](https://www.aepd.es)) or your local EU data-protection authority. ### 8.1 Digital Rights Under LOPDGDD In addition, Spanish residents enjoy the digital rights recognized in Title X of the LOPDGDD, including the right to digital disconnection in the labour environment, the right to digital education, and rights connected to the use of the Internet. ### 8.2 How to Exercise Your Rights Email `contact@desplega.sh`. We will respond within 30 days (extendable in accordance with Art. 12(3) GDPR). We may need to verify your identity before fulfilling a request. ### 8.3 International Transfers Several Group A and Group B sub-processors process data in the United States. International transfers from the EEA, United Kingdom, or Switzerland are protected by: - **Standard Contractual Clauses (SCCs)** — incorporated into our agreements with non-adequate-country sub-processors. - **EU–US Data Privacy Framework (DPF)** — relied on for sub-processors that are certified, where applicable. - Supplemental measures (encryption in transit, encryption at rest for sensitive secrets) where appropriate. Spanish law does not change the GDPR transfer regime — these are EU-wide rules. Separately, where you consent to the X (Twitter) conversion pixel (Section 4.2), conversion data is transferred to X Corp. in the United States as an independent controller under its own privacy policy and transfer mechanisms — outside Desplega's sub-processor SCC/DPF framework. You can disable this at any time via **Cookie settings**. ### 8.4 California (CCPA / CPRA) and Other US States If you are a California resident, you have the rights to know, delete, correct, and opt out of "sale" or "sharing" of personal information. With your consent, the X (Twitter) conversion pixel shares limited conversion data with X Corp. for conversion measurement and audience building, which may constitute "sharing" for cross-context behavioral advertising under the CPRA; you can opt out at any time by choosing "Opt out (essential)" in the cookie banner or via **Cookie settings** in the footer. We otherwise **do not sell or share personal information** as defined by the CCPA/CPRA. If you reside in another US state with a comprehensive privacy law (Colorado, Connecticut, Virginia, Utah, Oregon, Texas, etc.), submit requests to `contact@desplega.sh` and identify your state. --- ## 9. Data Residency Your data may be stored in multiple locations depending on the service: - **Agent infrastructure (Hetzner):** Germany (EU). Region selection at swarm creation may be available in the future; today, EU-only. - **Account, billing, and configuration metadata (Convex):** United States. - **Authentication (Clerk):** United States. - **Billing (Stripe):** United States and EU (Ireland) regional infrastructure. - **Web hosting (Vercel):** United States with global edge. - **Analytics (Plausible, Google Analytics 4, PostHog, Sentry):** see Section 6. If you require strictly EU-only processing, contact us at `contact@desplega.sh` before subscribing so we can confirm whether the current configuration meets your requirements. --- ## 10. Data Security We apply commercially reasonable technical and organizational measures, including: - **Encryption in transit:** TLS for all communications between users, the dashboard, and provisioned infrastructure. - **Encryption at rest:** sensitive secrets (API tokens, OAuth credentials, integration keys) are encrypted using AES-256-GCM before storage. Underlying provider storage is encrypted at rest by default. - **Tenant isolation:** each swarm runs on dedicated virtual machines or servers, with separate databases and storage paths per tenant. - **Access controls:** infrastructure access is restricted to authorized personnel under role-based access controls. Production access is logged. - **Least privilege:** sub-processors receive only the data necessary to perform their function. - **Secret rotation:** OAuth tokens and webhook signing keys are rotated on a regular schedule. - **Vulnerability management:** dependencies are monitored for known CVEs. No system is perfectly secure. While we use commercially reasonable measures, we cannot guarantee absolute security. If we become aware of a personal-data breach affecting you, we will notify you and the Agencia Española de Protección de Datos (or other competent supervisory authority) as required by applicable law (within 72 hours of awareness where required by GDPR Art. 33). --- ## 11. Children's Privacy The Service is not intended for children under 16. We do not knowingly collect personal information from children. If you believe a child has provided us with personal data, contact us at `contact@desplega.sh` and we will delete it. --- ## 12. Automated Decision-Making We do not make automated decisions producing legal or similarly significant effects on you without human involvement (Art. 22 GDPR). Your AI agents may produce outputs that affect downstream systems you control; you remain responsible for reviewing those outputs. --- ## 13. Changes to This Policy We may update this Privacy Policy. For material changes, we will: - Post the updated policy on the Service and update the "Last updated" date. - Notify you by email at the address associated with your account at least **30 days** before changes take effect. Continued use of the Service after the effective date constitutes acceptance of the updated policy. --- ## 14. Contact Us For privacy questions, GDPR-rights requests, complaints, or any other inquiry: - **Email:** `contact@desplega.sh` - **Postal:** Desplega Labs, S.L., Tuset 3, planta 5, 08006 Barcelona, Spain. - **Spanish supervisory authority:** Agencia Española de Protección de Datos — [www.aepd.es](https://www.aepd.es). --- --- # Terms and Conditions **Version:** v3.2 **Effective date:** 2026-05-07 **Last updated:** 2026-05-26 > **Offering update (2026-10-12).** Agent Swarm Cloud is no longer offered. Agent Swarm is free software under MIT. Enterprise support is available [by conversation](https://calendar.app.google/49DmjEXTPAv5NsRq6), with services and scope agreed separately. Cloud references below describe the former service. This notice does not change existing contractual obligations or data-protection commitments. > **Scope.** These Terms cover the marketing and documentation website at [agent-swarm.dev](https://www.agent-swarm.dev) (the "Site") and the Agent Swarm Cloud platform at `cloud.agent-swarm.dev` (the "Cloud Service"). Together, the Site and the Cloud Service are the "Service." ## 0. Parties These Terms and Conditions ("Terms") are entered into between: - **Desplega Labs, S.L.**, a Spanish private limited company (*sociedad de responsabilidad limitada*) with registered office at Tuset 3, planta 5, 08006 Barcelona, Spain, registered at the Registro Mercantil de Barcelona, CIF B27645381 (the "Company", "Desplega Labs", "we", "us", "our"); and - **You** ("Customer", "you"), as an individual (when acting as a consumer) or as the entity on whose behalf an authorized representative accepts these Terms (when acting as a business). By creating an account, accessing the Service, or clicking "I agree," you agree to these Terms. If you are entering into these Terms on behalf of an organization, you represent that you have authority to bind that organization, and "you" refers to that organization. If you do not agree to these Terms, do not use the Service. > **Information notice (Spanish LSSI Art. 10).** The information about the Company in this Section satisfies the disclosures required of an information-society service provider established in Spain, including legal name, registered office, Registro Mercantil identification, CIF, and contact email (`contact@desplega.sh`). --- ## 1. Service Description The former Agent Swarm Cloud platform let you deploy and operate "swarms" of AI agents. Those agents used Claude Code and other supported runtimes. The Cloud Service provisioned virtual machines, databases, and object storage on your behalf. It provided a management interface (the "Dashboard") at `cloud.agent-swarm.dev`. The underlying agent-swarm.dev runtime is open-source software released under the **MIT License** at [github.com/desplega-ai/agent-swarm](https://github.com/desplega-ai/agent-swarm). The cloud management layer — provisioning, billing, monitoring, integrations, and the Dashboard — is proprietary to Desplega Labs. These Terms cover the Service. Your use of the open-source runtime under the MIT License is governed by that license and is unaffected by these Terms. --- ## 2. Account Terms ### 2.1 Eligibility You must be at least **18 years old** (or the age of majority in your jurisdiction) and able to form a binding contract under Spanish law to use the Service. The Service is not available to individuals or entities subject to comprehensive trade sanctions administered by the EU, Spain, the United Nations, the United States, or the United Kingdom. ### 2.2 Registration You create an account through Clerk (our authentication provider). Accounts are organized around **organizations**; an organization may have multiple members. You agree to: - Provide accurate, current, and complete information during registration. - Keep your credentials confidential and not share them. - Notify us promptly at `contact@desplega.sh` if you suspect unauthorized access to your account. - Take responsibility for all activity under your account or organization, including activity by your members and agents. ### 2.3 One Subscription Per Organization Each billing relationship corresponds to one organization. You may create multiple organizations, but each is billed independently. --- ## 3. Pricing, Plans, and Payments ### 3.1 Pricing The former Service offered three plans. The rates as of the effective date of these Terms are preserved below for reference. These plans and rates are not current offers. See [pricing](/pricing) for free self-hosting and enterprise support by conversation. | Plan | Price | |---|---| | **Self-Hosted** | €0 forever — open-source under the MIT License. You provide your own infrastructure and your own model API keys. Not governed by these Terms; governed by the MIT License. | | **Cloud** | **Graduated worker-based pricing in EUR, billed monthly through Stripe.** Volume tiers are cumulative across the workers you provision in a billing period (see the tier table below). There is no separate platform/seat fee — pricing scales solely with worker count. | | **Enterprise** | Custom pricing (single-tenant deployment, SSO/SAML, dedicated support). Contact sales. Governed by a separate signed order form that incorporates these Terms by reference. | #### 3.1.1 Cloud — Graduated Worker Tiers Cloud subscriptions use a **graduated** (i.e., cumulative, "Stripe-style") tier model: the unit price for each worker is €0.00, and a flat amount is added to your monthly bill once your worker count enters the corresponding tier. The first time you provision a worker triggers the Tier 1 flat fee; each subsequent tier adds its incremental flat amount on top of all prior tiers. | Tier | Worker count entering the tier | Unit price per worker | Incremental flat amount added | Cumulative monthly subscription | |---|---|---|---|---| | 1 | First 1 to 4 workers | €0.00 | €30.00 | **€30 / month** for 1–4 workers | | 2 | Next 5 to 6 workers (i.e., the 5th and 6th worker) | €0.00 | €15.00 | **€45 / month** for 5–6 workers | | 3 | Next 7 to 8 workers | €0.00 | €15.00 | **€60 / month** for 7–8 workers | | 4 | Next 9 to 10 workers | €0.00 | €10.00 | **€70 / month** for 9–10 workers | | 5 | Next 11 to 12 workers | €0.00 | €10.00 | **€80 / month** for 11–12 workers | | 6 | Next 13 to 14 workers | €0.00 | €10.00 | **€90 / month** for 13–14 workers | | 7 | Next 15 to 16 workers | €0.00 | €10.00 | **€100 / month** for 15–16 workers | The former plan required a custom quote beyond 16 workers. Cloud pricing scales with worker count, not user seats. Workers run in isolated containers; you bring your own LLM/model API keys (see Section 5.4). We may change prices on **30 days' advance notice** by email or in-product notification. Price changes take effect at the start of your next billing cycle after notice expires; if you do not accept the change, you may cancel before that date and receive a partial pro-rata refund per Section 3.4. ### 3.2 Cloud Waitlist The former Cloud waitlist is closed. The following provisions describe that waitlist. Joining the waitlist did not create a subscription, guarantee access, or authorize a charge. - We may invite waitlisted Customers to subscribe as capacity becomes available. - Pricing and plan details shown when access is offered apply only after the Customer accepts them and starts a subscription. - We may modify or discontinue the waitlist at any time. ### 3.3 Payment - Subscriptions are billed **monthly** in EUR through Stripe, in advance, on the calendar day corresponding to the start of your subscription. - By subscribing, you authorize us (via Stripe) to charge your payment method on a recurring basis. - Failed payments are retried per Stripe's standard retry schedule. Continued failure may result in suspension under Section 3.5. - You are responsible for all taxes, levies, and similar charges (including, where applicable, Spanish or EU VAT and any equivalent indirect taxes in your country) except for taxes on our income. - Invoices are sent through Stripe to the billing email on file and are issued in compliance with Spanish invoicing rules (Real Decreto 1619/2012). ### 3.4 Cancellation and Refunds - You may cancel your subscription **at any time** from the Dashboard or by contacting `contact@desplega.sh`. Cancellation is effective immediately for the purposes of subscription renewal. - **Partial pro-rata refund on cancellation.** When you cancel mid-period, we will refund the unused portion of the current billing period on a pro-rata daily basis. We do not retain the unused portion of a paid period. Refunds are processed to the original payment method via Stripe within a reasonable time after cancellation; bank-side processing times may apply. - Refunds may be reduced by amounts representing usage already incurred, third-party costs already passed through, or any outstanding balances. - Statutory consumer rights — including the EU 14-day right of withdrawal under Directive 2011/83/EU and the Spanish Real Decreto Legislativo 1/2007 (texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios, "TRLGDCU") — apply where they apply by law and cannot be waived. Where the Service has begun to be performed during the withdrawal period at your express request, we may charge for the value of the service supplied up to the time of withdrawal. ### 3.5 Suspension and Tear-Down for Non-Payment If a payment fails and is not resolved: - **14 days past due:** swarm machines may be stopped. Customer Data remains intact. - **28 days past due:** we reserve the right to tear down the infrastructure and delete associated Customer Data. We will attempt to notify you by email at the address on file before doing so. --- ## 4. Acceptable Use You agree not to use the Service, and not to permit your members, agents, or end users to: - Violate any applicable law, regulation, or order, including export controls and sanctions, Spanish and EU consumer-protection law, the LOPDGDD, the LSSI, or the GDPR. - Infringe any third party's intellectual-property, privacy, publicity, or other rights. - Distribute malware, ransomware, viruses, or other malicious code. - Send spam, unsolicited messages, or messages that violate anti-spam laws (Spanish LSSI Art. 21, GDPR/ePrivacy, CAN-SPAM, CASL, etc.). - Attempt to gain unauthorized access to other customers' data, accounts, or infrastructure, or to our systems. - Interfere with, disrupt, or place an unreasonable load on the Service or its underlying infrastructure (including denial-of-service attempts, scraping that exceeds documented rate limits, or container-escape attempts). - Mine cryptocurrency or use the Service for compute-resource arbitrage unrelated to the Service's intended purpose. - Generate, distribute, or store content that is illegal under Spanish law or in the jurisdiction where the Service is delivered, including child sexual abuse material, content that incites violence, or content that violates applicable hate-speech, terrorism, or defamation laws. - Use AI agents in a manner that violates the acceptable-use or terms-of-service policy of any third-party model provider, integration, or other service you have connected (Anthropic, OpenAI, Slack, GitHub, GitLab, Linear, AgentMail, or any other Group C integration as defined in the Privacy Policy). Compliance with those third-party policies is your responsibility. - Resell, sublicense, or white-label the Service without our prior written consent. - Reverse-engineer, decompile, or attempt to derive the source code of the proprietary cloud management layer (the open-source runtime is exempt — you may study and modify it under the MIT License). - Bypass technical limitations, security features, or rate limits. - Use the Service to make automated decisions producing legal or similarly significant effects on individuals without disclosing and complying with applicable law (Art. 22 GDPR). We reserve the right to investigate suspected violations and to suspend or terminate accounts that breach this Section. --- ## 5. Customer Data and Intellectual Property ### 5.1 Customer Data "Customer Data" means data you submit to the Service or that your agents generate and store while running on the Service, including swarm configurations, prompts, outputs, files, integration payloads, and memory entries. As between you and us, you retain all rights, title, and interest in Customer Data. ### 5.2 License You Grant Us You grant us a worldwide, non-exclusive, royalty-free license to host, store, transmit, process, display, and otherwise use Customer Data solely as necessary to provide and improve the Service, comply with law, and enforce these Terms. This license ends when the relevant Customer Data is deleted in accordance with the Privacy Policy retention schedule. ### 5.3 Our Role: Controller / Processor Split Consistent with the Privacy Policy: - We act as **data controller** for account, billing, technical, security, and analytics data we collect about you. - We act as **data processor** on your behalf for Customer Data containing personal data, processing it solely on your documented instructions for the purpose of operating the Service. A separate **Data Processing Addendum (DPA)**, including the EU Standard Contractual Clauses where applicable, is **available on request** at `contact@desplega.sh`. The DPA, once executed, supersedes any conflicting provisions in these Terms with respect to processing of Customer Data containing personal data. ### 5.4 Sub-Processors and User-Configured Integrations The Service uses the sub-processors listed in the Privacy Policy (Group A — infrastructure; Group B — analytics/error tracking). Those are the only sub-processors Desplega Labs engages directly. Third-party services and AI providers that you connect to your swarm — including but not limited to **Anthropic / Claude API, OpenAI, OpenRouter, Slack, GitHub, GitLab, Linear, AgentMail, custom MCP servers, and any other LLM, model provider, or tool you configure** — are **NOT Desplega sub-processors**. They are services you select and connect under **your own** accounts, contracts, and API credentials. Desplega Labs: - Has no controller/processor relationship with you in respect of those services. - Does not execute DPAs or other agreements with those vendors on your behalf. - Acts solely as a passthrough for the API keys, OAuth tokens, and content you instruct the Service to send to them. You are responsible for compliance, billing, acceptable use, IP clearances, and any data-protection obligations associated with those services. Their availability, behavior, output, accuracy, policy changes, or service interruptions are outside our control, and we are not liable for them. ### 5.5 Aggregated and De-Identified Data We may generate aggregated, anonymized, or de-identified statistics from operation of the Service (e.g., total request volume, error rates, resource-usage trends). Such data does not identify you or any individual. We may use it to operate, improve, and promote the Service. ### 5.6 No Training We do **not** use Customer Data to train AI models (ours or any third party's), and we do not authorize sub-processors to do so. ### 5.7 Service IP The Service, the Dashboard, our trademarks, logos, documentation, and the proprietary management layer are owned by Desplega Labs, S.L. (or our licensors). These Terms grant you a limited, non-exclusive, non-transferable, revocable right to access and use the Service for your internal business purposes during your subscription. Nothing in these Terms transfers any IP rights in the Service to you. ### 5.8 Open-Source Runtime The agent-swarm.dev runtime is licensed under the MIT License. Your rights under that license are not affected by these Terms. The MIT License governs use of the runtime, including for self-hosting. ### 5.9 Feedback If you submit feedback, suggestions, or feature requests, you grant us a perpetual, irrevocable, royalty-free license to use them for any purpose without obligation to you. --- ## 6. Service Availability and Support ### 6.1 No SLA During Initial Launch The Service is currently provided on a **best-effort basis** and "tal cual" / "as is". We do not guarantee uptime, latency, or any specific performance level unless we have agreed to a written Service Level Agreement (SLA) with you in a signed order form. We aim for high availability but cannot guarantee uninterrupted service. ### 6.2 Maintenance We may perform scheduled or emergency maintenance. We will provide reasonable advance notice for planned maintenance where practical. ### 6.3 Third-Party Dependencies The Service depends on the third-party providers listed in Group A and Group B of the Privacy Policy (e.g., Vercel, Convex, Clerk, Stripe, Hetzner, Plausible, Sentry, PostHog), and on the user-configured Group C integrations you connect (e.g., Anthropic, OpenAI, Slack, GitHub, GitLab, Linear, AgentMail). Outages, errors, or policy changes at those providers may degrade or interrupt the Service. To the maximum extent permitted by Spanish and EU law, we are not liable for issues caused by third-party providers, and especially not for issues caused by Group C integrations you have configured. ### 6.4 Support Standard support is provided by email at `contact@desplega.sh`. Community support is available through our public Discord. Response times are not guaranteed unless covered by a paid Enterprise support plan documented in a signed order form. --- ## 7. Beta Features We may offer features labeled "beta," "preview," "experimental," or similar. Beta features are provided **as is** ("tal cual"), may be unstable, and may be modified or discontinued at any time. SLAs and warranties (express or implied) do not apply to beta features. --- ## 8. Confidentiality Each party may receive non-public information from the other ("Confidential Information"). The receiving party will use Confidential Information only as needed to perform under these Terms, will protect it with the same care it uses for its own confidential information (and no less than reasonable care), and will not disclose it to third parties except to its personnel and contractors with a need to know who are bound by similar obligations. Confidential Information does not include information that is or becomes public without breach, was already known, was independently developed, or is rightfully received from a third party. Disclosures required by law are permitted with prompt notice (where lawful). --- ## 9. Warranty Disclaimer TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, AND EXCEPT AS EXPRESSLY STATED IN THESE TERMS, THE SERVICE IS PROVIDED **"AS IS" / "TAL CUAL" AND "AS AVAILABLE"** WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, ACCURACY, AND ANY WARRANTIES ARISING FROM COURSE OF DEALING OR USAGE OF TRADE. WE DO NOT WARRANT THAT THE SERVICE WILL BE UNINTERRUPTED, ERROR-FREE, OR FREE FROM HARMFUL COMPONENTS, OR THAT AGENT OUTPUTS WILL BE ACCURATE, COMPLETE, OR FIT FOR YOUR PURPOSE. This Section does not exclude or limit any non-waivable rights you may have as an EU/Spanish consumer under Directive 2011/83/EU, Directive 2019/770/EU (digital content and digital services), the TRLGDCU, or other mandatory consumer-protection law. --- ## 10. Limitation of Liability ### 10.1 Excluded Damages TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, NEITHER PARTY WILL BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY, OR PUNITIVE DAMAGES, OR ANY LOSS OF PROFITS, REVENUE, DATA, GOODWILL, OR BUSINESS INTERRUPTION, ARISING OUT OF OR RELATED TO THESE TERMS OR THE SERVICE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND WHETHER BASED IN CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY, OR ANY OTHER LEGAL THEORY. ### 10.2 Aggregate Cap EACH PARTY'S AGGREGATE LIABILITY ARISING OUT OF OR RELATED TO THESE TERMS WILL NOT EXCEED **THE LESSER OF:** - **(a)** the total fees paid by Customer to Desplega Labs under these Terms in the **six (6) months immediately preceding the event giving rise to the claim**, or - **(b) one hundred euros (EUR 100).** ### 10.3 Time Limitation on Claims Any claim arising out of or related to these Terms must be brought within **one (1) year** from the date the claimant knew or, exercising reasonable diligence, should have known of the cause of action, **subject to** the minimum statutory limitation periods under the Spanish Civil Code (Arts. 1968–1971) and other mandatory law, which prevail where shorter contractual limitations would otherwise be invalid. ### 10.4 Mandatory Carve-Outs The exclusions and cap in Sections 10.1, 10.2, and 10.3 do **not** apply to: - A party's **fraud or willful misconduct (dolo)**. - **Gross negligence (culpa grave)** to the extent Spanish case law prohibits its waiver; otherwise, liability for gross negligence is also subject to Sections 10.1 and 10.2. - **Death or personal injury** caused by negligence (mandatory under Spanish consumer law). - Mandatory rights of EU consumers under Directive 2011/83/EU, Directive 2019/770/EU, and the Spanish TRLGDCU, which are **non-waivable**. - Customer's obligation to pay fees due under these Terms. - Customer's indemnification obligations under Section 11. - Any liability that cannot be excluded or limited under applicable mandatory law. ### 10.5 Consumers If you are a consumer (i.e., a natural person acting outside your trade, business, craft, or profession), you may have statutory rights that cannot be limited by contract. Nothing in these Terms limits or excludes those rights, and the most-favourable-to-the-consumer interpretation of any ambiguous clause shall prevail (Art. 80.2 TRLGDCU). ### 10.6 Allocation of Risk The parties acknowledge that the allocation of risk in this Section 10 — including the cap, the time limitation, and the disclaimers — is a fundamental basis of the bargain and reflects the pricing of the Service. Without these limitations, the Company would not be able to offer the Service at the rates published. --- ## 11. Indemnification ### 11.1 By You You will defend, indemnify, and hold us harmless from and against any third-party claim, demand, or proceeding (and resulting losses, damages, fines, and reasonable attorneys' fees) arising from or related to: - (a) your or your agents' use of the Service in breach of these Terms or applicable law; - (b) Customer Data, including any claim that Customer Data infringes a third party's intellectual-property, privacy, publicity, or other rights, or that it violates applicable law; - (c) your breach of Section 4 (Acceptable Use); - (d) **your use of, or your agents' interaction with, any third-party service, AI provider, integration, model, or tool you have connected to the Service** (i.e., Group C integrations as defined in Section 5.4 and the Privacy Policy), including but not limited to claims based on your alleged violation of those vendors' terms of service or acceptable-use policies, billing disputes with those vendors, exposure of data to those vendors, or output produced by their models; and - (e) any allegation that data you instructed us to transmit to a Group C integration was unlawful for that integration to receive. ### 11.2 By Us We will defend you against any third-party claim alleging that the Service, when used as authorized by these Terms, infringes a third party's intellectual-property right enforceable in Spain or the European Union, and we will pay damages and costs finally awarded against you (or agreed in settlement). We have no obligation under this Section for claims arising from: (i) Customer Data; (ii) modifications not made by us; (iii) combination of the Service with anything not provided by us; (iv) use after we notify you to stop; or (v) third-party services, models, integrations, or open-source components (including the MIT-licensed runtime and any Group C integration). Our obligations under this Section 11.2 are subject to the cap in Section 10.2. If the Service becomes, or in our opinion is likely to become, the subject of an infringement claim, we may, at our option: (1) procure for you the right to continue using it; (2) modify it to be non-infringing; or (3) terminate the affected portion of the Service and refund any prepaid, unused fees for that portion on a pro-rata basis. ### 11.3 Procedure The indemnified party will (a) promptly notify the indemnifying party of the claim, (b) give the indemnifying party sole control of the defense and settlement (settlements that admit liability or impose obligations on the indemnified party require the indemnified party's consent, not unreasonably withheld), and (c) provide reasonable cooperation at the indemnifying party's expense. --- ## 12. Term and Termination ### 12.1 Term These Terms apply from the date you first accept them and continue until terminated. ### 12.2 Termination by You You may terminate at any time by canceling your subscription and (if desired) deleting your account. On cancellation, the partial pro-rata refund mechanism in Section 3.4 applies. ### 12.3 Termination by Us We may suspend or terminate your access to the Service immediately if: - You materially breach these Terms (including non-payment under Section 3.5 or violations of Section 4) and, where the breach is curable, do not cure within 14 days of written notice. - Required by law or by a regulator, court, or law-enforcement authority. - Continuing to provide the Service to you would create an undue risk to us or other customers. We may discontinue the Service (in whole or in part) on at least **30 days' notice**, with a partial pro-rata refund of any unused prepaid fees. ### 12.4 Effect of Termination On termination: - Your access to the Service ends. - Your swarm machines are stopped and infrastructure is torn down per the Privacy Policy retention schedule (Section 7). - Outstanding fees become immediately due. - Sections that by their nature should survive (Sections 5, 8, 9, 10, 11, 13, 14, and any accrued payment obligations) survive termination. You may request export of Customer Data during the wind-down period; see the Privacy Policy. --- ## 13. Governing Law and Disputes ### 13.1 Governing Law These Terms are governed by **Spanish law (Derecho español)**, without regard to its conflict-of-laws rules. The UN Convention on Contracts for the International Sale of Goods does not apply. ### 13.2 Jurisdiction Subject to Section 13.3 and any mandatory consumer-protection rules, the **Courts and Tribunals of the City of Barcelona, Spain** will have **exclusive jurisdiction** over any disputes arising out of or relating to these Terms or the Service. ### 13.3 EU and Spanish Consumers If you are an EU consumer (i.e., a natural person acting outside your trade, business, craft, or profession), the mandatory consumer-protection rules of your country of habitual residence apply notwithstanding the choice of law in Section 13.1, and you may bring proceedings against us in the courts of your country of residence (Art. 18(1), Brussels I bis Regulation 1215/2012). Nothing in these Terms deprives you of the protection afforded by mandatory provisions of the law of your habitual residence. EU consumers may also use the European Commission's Online Dispute Resolution platform at [https://ec.europa.eu/consumers/odr](https://ec.europa.eu/consumers/odr). ### 13.4 No Class Actions Where permitted by law, the parties waive any right to participate in a class, collective, or representative action arising out of these Terms. This waiver does not apply where prohibited by Spanish or EU mandatory law (including consumer-collective-action rights). --- ## 14. Compliance and Export Controls You represent that you are not located in, under the control of, or a resident of any country or on any list subject to comprehensive trade sanctions administered by the EU, Spain, the UN, the US, or the UK, and that your use of the Service does not violate applicable export-control or sanctions laws. --- ## 15. Changes to These Terms We may update these Terms from time to time. For material changes, we will notify you by email or through the Service at least **30 days** before they take effect. Continued use after the effective date constitutes acceptance. If you do not agree, you may terminate before the effective date and receive a partial pro-rata refund per Section 3.4. --- ## 16. Miscellaneous - **Entire Agreement.** These Terms, the Privacy Policy, any executed DPA, and any order form or written addendum signed by both parties form the entire agreement between you and us regarding the Service and supersede prior agreements on the same subject matter. - **Order of Precedence.** In case of conflict: (1) a signed order form or addendum, (2) the executed DPA, (3) these Terms, (4) the Privacy Policy. - **No Waiver.** A failure to enforce any right or provision is not a waiver. - **Severability.** If a provision is held unenforceable, the rest remains in effect, and the unenforceable provision will be construed to give it the maximum effect permitted by law. - **Assignment.** You may not assign these Terms without our prior written consent (which we will not unreasonably withhold). We may assign these Terms in connection with a merger, acquisition, reorganization, or sale of assets. - **Notices.** Notices to you may be sent to your account email. Notices to us must be sent to `contact@desplega.sh`; for service of formal legal notices by registered mail, send to Desplega Labs, S.L., Tuset 3, planta 5, 08006 Barcelona, Spain. - **Force Majeure.** Neither party is liable for delays or failure caused by events beyond its reasonable control (e.g., natural disasters, war, internet outages, regulatory action, third-party-provider outages, public-health emergencies). - **Independent Contractors.** The parties are independent contractors. These Terms do not create a partnership, joint venture, agency, or employment relationship. - **Third-Party Beneficiaries.** None, except as expressly stated. - **Language.** The English version of these Terms controls. Spanish or other-language translations may be provided for convenience; in case of discrepancy, the English version prevails, except where Spanish/EU consumer law mandates otherwise. --- ## 17. Contact For legal notices and questions about these Terms: - **Email:** `contact@desplega.sh` - **Postal:** Desplega Labs, S.L., Tuset 3, planta 5, 08006 Barcelona, Spain - **Registro Mercantil de Barcelona** - **CIF:** B27645381 --- --- # Two small models triage every PR > Clairic and Jev triage every pull request, and a coding agent reviews only what they flag. About $0.02 and 30 seconds per PR, across 14 real PRs. Published: 2026-10-21T00:00:00Z Read time: 3 min read Tags: `AI code review`, `pull requests`, `Clairic`, `Jev`, `agent workflows`, `open source`, `Agent Swarm` Canonical URL: https://www.agent-swarm.dev/blog/two-models-triage-every-pr --- Most AI code review sends every pull request to a large model and hopes the bill stays small. We flipped it. Two small models triage every PR first, and a coding agent reads only the parts they flag. A clean PR never reaches the agent at all. We built it in an afternoon, from stock workflow nodes and scripts. ## What it does Seven nodes. Three of them run at the same time. A script fetches the diff for a whole PR or a commit range, and splits it into hunks. Clairic reads the PR description and returns its claims: intent, stated risk, breaking changes, touched areas. Jev ranks the context: CI on the head commit, the repo rules, files that reference the changed modules, and recent PRs on the same paths. It also weighs files that usually change alongside the changed modules. Jev then tags every hunk with a category: tests, api, db, auth, ui, logic, docs. Hunks group into batches by category, as many as the PR needs, and Jev judges every batch in parallel against the claims and the rules. Only the top flagged batches go to a coding agent (codex on gpt-5.6-luna), at most two per PR. It returns at most three concrete findings, each with a minimal patch. A final script writes the verdict: Looks fine, Worth a comment, or Request changes. ## The numbers We ran it over the 14 open PRs in `desplega-ai/agent-swarm` on 2026-10-21. Median run: 30 seconds per PR. Total cost: $0.26, about $0.02 per PR. The split is the point. Jev made 495 decide calls for $0.024. The 24 agent tasks cost $0.24, about 16 seconds each, and they only run on what Jev flags. Verdicts: 2 clean, 4 where Jev flagged and the agent cleared it, 4 worth a comment, 4 request changes. ## What a review looks like PR #2117 touches 24 files: 45 hunks, 9 batches. The top two went to the agent, verdict Worth a comment, $0.037 in 35 seconds. The agent spotted a new uid bound that let the shared workflow uid land at 999, inside the system uid range. It wrote a two-line patch. ![The finding and its patch, ready to apply.](/images/two-models-triage-every-pr/final-real-patch.png) PR #2315 is a one-file commit. One batch, the agent found nothing, verdict Looks fine, under $0.01 in 16 seconds. ![A clean PR, cleared for under a cent.](/images/two-models-triage-every-pr/bee-1440.png) Push a fix and review again: the diff starts at the last reviewed commit, so a new push costs only its own size. ![Jev's score for every batch, before any agent runs.](/images/two-models-triage-every-pr/load-triage-1440.png) ## Run it yourself The workflow ships in the repo, and both executors are open source. The [PR review playbook](https://docs.agent-swarm.dev/docs/playbooks/pr-review) walks through the setup and the node configuration. The honest limits: findings are unverified model output, the agent sees only its batch, and nothing is posted back to GitHub. ## Triage first Cheap models should read everything. Your coding agent should read what matters. Star [agent-swarm](https://github.com/desplega-ai/agent-swarm), run the workflow on your own repo, and tell us what it misses. --- # What if Devin is down? > Devin Oncall is one AI on-call vendor. Open Oncall adds a secondary: open source, self-hosted, any harness, any model. Published: 2026-10-16T00:00:00Z Read time: 3 min read Tags: `AI on-call`, `open source on-call`, `PagerDuty`, `incident response`, `self-hosted AI agents`, `Agent Swarm`, `Open Oncall` Canonical URL: https://www.agent-swarm.dev/blog/what-if-devin-is-down --- Every serious on-call rotation has a primary, a secondary and an escalation chain. Nobody trusts one person to be awake for everything. So why would your AI on-call run on one provider? That is the idea behind Open Oncall, launching today. It is our open answer to Devin Oncall, and we think AI on-call needs a secondary. ## A scenario for 3:14 am This is a scenario, not an incident report. It is 3:14 am, and PagerDuty fires an alert. Open Oncall opens a thread in Slack and starts the investigation with traces, logs and recent deploys. Then the primary agent times out. The swarm does not wait for a human to notice. It moves the same investigation to the next harness, on its own. The investigation finishes in the same thread: root cause, evidence and a proposed fix. Maya, an on-call engineer in this scenario, opens the approval link. The fix PR opens, the checks go green, and Maya goes back to sleep. ## Why one provider is a single point of failure Devin Oncall is generally available now. It takes alerts from Slack, Teams and PagerDuty, and it uses your telemetry, code, deployments, runbooks and past incidents. It runs on Cognition's hosted platform, and we found no self-hosted option. Its launch post says the architecture lets Cognition choose the best model for each on-call task. That is a sensible design. It is still one vendor, on infrastructure you do not run, making the call at 3 am. A single-vendor AI on-call is also a new lock-in. The context it builds up, your runbooks and incident history, is the part you need when you move. Keep that context somewhere you control. ## Open Oncall: primary, secondary, then the chain Open Oncall is part of Agent Swarm. It is MIT licensed and self-hosted. You choose the harness (Claude Code, Codex or OpenCode) and the model. Alerts can come from PagerDuty, Datadog, Grafana, Opsgenie, Sentry, SigNoz or any webhook. If the provider running a step fails, the same step re-runs on the next harness. A person still approves before any fix PR opens, through a link in the Slack thread. ## Run it yourself The replication guide walks through the whole setup. You import the workflow and its failover sub-workflow, add the script and the app, then point PagerDuty at your workflow webhook. It also covers a failover drill, so you can test the secondary before you need it: [Open Oncall replication guide](https://docs.agent-swarm.dev/docs/playbooks/open-oncall). ## Sleep better Sleep better without relying on a single provider. Set up Open Oncall with a secondary, run the drill, and tell us where it breaks. Related reading: [How to avoid vendor lock-in for coding agents](https://www.agent-swarm.dev/blog/avoid-coding-agent-lock-in). --- # How to Avoid Vendor Lock-In for Coding Agents: A Layer-by-Layer Exit Test > Coding-agent lock-in lives in the context layers, not the model. Audit eight layers, run the exit test, and keep memory and traces exportable. Published: 2026-10-10T00:00:00Z Read time: 11 min read Tags: `coding agent vendor lock-in`, `avoid ai coding agent lock-in`, `coding harness portability`, `multi-harness ai agents`, `agent memory export`, `self-hosted ai agents`, `claude code codex opencode`, `model gateway portability`, `agent exit test`, `portability checklist` Canonical URL: https://www.agent-swarm.dev/blog/avoid-coding-agent-lock-in --- You avoid vendor lock-in for coding harnesses by keeping the layers that build up context in storage you own and by testing, on a schedule, that you can actually move them. For coding agents, lock-in sits in the layers that build up context, not in the model alone. Swapping models is the easy part: most harnesses let you repoint to a different model or gateway with a config change. The accumulated context, meaning your agent definitions, skills, memory, and run history, is the asset that is hard to move, and it is exactly what makes your agents effective at your work. *** > **TL;DR:** > > - Lock-in for coding agents lives in the context layers (agent definitions, skills, memory, run history), not in the model itself. > - Audit eight layers, from agent definitions down to deployment, and score each one with a yes/no exit question. > - A paid API or managed host is a normal vendor relationship; the dangerous case is context you cannot export. > - Self-hosting and multi-harness workers make the exit real, but prompt retuning, capability gaps, and eval re-validation still cost time. > - Portability means leaving is possible and cheap enough to threaten, not that it is free. *** ## Table of Contents - [What lock-in means for coding agents](#what-lock-in-means-for-coding-agents) - [The eight layers where lock-in actually lives](#the-eight-layers-where-lock-in-actually-lives) - [The exit test: seven questions to run this week](#the-exit-test-seven-questions-to-run-this-week) - [Operational dependency vs context loss](#operational-dependency-vs-context-loss) - [How self-hosting and multi-harness workers change the trade-off](#how-self-hosting-and-multi-harness-workers-change-the-trade-off) - [The migration costs portability does not remove](#the-migration-costs-portability-does-not-remove) - [When a managed or single-provider setup is the better choice](#when-a-managed-or-single-provider-setup-is-the-better-choice) - [Portability checklist](#portability-checklist) - [FAQ](#faq) ## What lock-in means for coding agents Lock-in is the gap between what it costs to stay and what it costs to leave. With a classic SaaS tool, the asset is the data: CRM records, support tickets, documents. If the vendor offers a full export and the schema is documented, leaving is painful but bounded. You re-import, retrain the team on a new interface, and move on. The data walks out with you, and the tool you left behind held no compounding value of its own. Coding agents break that pattern, and teams misjudge it because the visible layer looks portable. The model is rented compute. You pay per token, the unit prices are public, and a competing model is one config change away, so the procurement review concludes the stack is fungible. But the asset that makes coding agents effective is the accumulated context layered on top of the model: - **Agent definitions**: the roles, instructions, and constraints that shape behavior. - **Skills**: the reusable procedures agents invoke against your codebase and workflows. - **Memory**: what the system has learned across runs about your repos, conventions, and past decisions. - **Run history**: the prompts, traces, and task outcomes you use to debug, evaluate, and improve. These layers compound. Runs can add memory and trace data. Reviewed skill refinements can reduce repeated work. Model migration costs depend on the workload and capabilities. Two years of tuned definitions, skills, and memory sitting in a proprietary store with no export path is a factory you would have to rebuild from zero. The strategic case for owning this learning loop is in [A Frontier Model Is Rented, a Swarm Is Owned](/blog/a-frontier-model-is-rented-a-swarm-is-owned); this post is the practical audit that tells you whether the factory is actually yours. ## The eight layers where lock-in actually lives A coding-agent stack is a stack of layers, and each layer carries its own exit cost. Teams often check only the model layer, conclude they are portable because they can change an API key, and stop there. The audit below runs from the asset layer at the top, the context you accumulate, down to deployment at the bottom, which is whether you can rebuild the system at all. For each layer, the exit question is the one to ask your vendor or your own platform team. | Layer | What locks you in | Exit question | What portability looks like | |---|---|---|---| | Agent definitions and skills | Proprietary formats stored in the vendor's cloud | Can you export every agent and skill as files? | Plain files in your repo, importable elsewhere | | Prompts and traces (run history) | Logs trapped in a dashboard, retention caps | Can you export full prompts, traces, and task history? | Bulk export in an open format, no retention ceiling | | Memory | Opaque store, no dump, no re-import path | Can you export memory in a format you control? | A database file or structured export you can re-import | | Model and inference choice | Hard-coded endpoints, model-specific assumptions | Can you switch model or gateway with config only? | An env var or gateway change, zero code edits | | Harness | The agent loop runs only in one vendor's CLI | Can the same task run on a different harness? | Tasks defined as data, executable on another harness | | Worker runtime | Execution happens only on vendor machines | Can workers run on hardware you control? | Self-hosted workers from images you build and pin | | Credentials | Secrets pasted into prompts or a vendor vault | Are secrets bound per host and injected server-side? | Host-bound bindings; secrets never enter context | | Deployment | No restore path from your own backup | Can you rebuild from your backup on a fresh host? | A documented restore drill you have actually run | ## The exit test: seven questions to run this week Each question is yes/no. A "no" is not a reason to panic; it is a line item with a price you can now see. Answer them as a team, in writing. 1. **Can you point the same agents at a different model or gateway with a config change?** A no here means model choice is welded into code or prompt assumptions. When the vendor changes pricing or deprecates a model, you are negotiating with no alternative. 2. **Can the same task run on a different coding harness?** If a task only executes inside one vendor's agent loop, your workflows are hostage to that vendor's roadmap. A no means the harness's feature set, not your definitions, decides what your agents can do. 3. **Can you export agent memory in a format you control?** Memory is the compounding layer. A no means every run makes the agent better and the exit worse at the same time. 4. **Can you export prompts, traces, and task history?** Run history is how you debug failures and re-validate after any move. A no means you cannot prove the new stack works as well as the old one, because you no longer hold the old one's record. 5. **Are your agents, skills, workflows, and schedules stored as data you hold, in files or a database you can back up?** This is the factory definition. A no means the specification of how your work gets done exists only inside someone else's product. 6. **Are secrets bound per host and injected server-side rather than pasted into prompts?** A no means credentials are leaking into context windows and logs. That is a security problem and a portability problem at once. 7. **Can you restore the whole system from your own backup onto a fresh host?** This is the only question you cannot answer on paper. If you have not run the restore, the honest answer is no. Score it plainly. Six yeses and one no is a strong position with a known weakness. Three yeses is a dependency you are choosing not to look at. ## Operational dependency vs context loss Not every dependency is lock-in, and treating them the same wastes political capital. Paying a model vendor per token is an operational dependency. The bill is visible, the unit price is public, and substitutes exist. Paying for a managed host is the same shape of relationship: you are renting capacity, and if the asset walks out with you when you leave, the dependency is just procurement. Context loss is different in kind. Memory, skills, and run history are the compounding part of the system: they grow more valuable with every run, and they are exactly the parts a vendor has the most incentive to make sticky. If you cannot export them, each month of use raises the exit cost while the monthly bill stays flat. The asymmetry is the trap. A monthly bill is visible on day one; context loss is invisible until the day you try to leave. Procurement sees the first and optimizes it. Nobody owns the second until a migration is on the table and someone asks where the memory export button is. Treat exportability as a property you verify, not a promise you were given. A useful forcing question: if this vendor shut off your account tomorrow, what would you lose? If the answer is "an API key and a billing relationship," you have an operational dependency. If the answer is "two years of tuned prompts, agent memory, and trace history," you have lock-in, and the time to fix it is before you need to leave. ## How self-hosting and multi-harness workers change the trade-off It helps to walk through a concrete system built to pass this test. [Agent Swarm](https://www.agent-swarm.dev/) is open source under the MIT license and self-hosted with Docker Compose, so the custody questions have structural answers rather than policy promises. At the harness layer, a worker picks its harness at boot with `HARNESS_PROVIDER`. Harnesses supported today: Claude Code, Codex, pi (pi-mono), OpenCode (experimental), Devin, Claude Managed Agents, and ACP agents, where an ACP agent is an OpenCode or GitHub Copilot CLI preset or a custom command; the README also lists Cursor, Amp, and Grok. Every harness plugs in behind one ProviderAdapter interface, so tasks and agent definitions keep the same shape across harnesses. The details are in the [harness configuration guide](https://docs.agent-swarm.dev/docs/guides/harness-configuration). At the model layer, routing goes through gateways rather than hard-coded endpoints. OpenRouter works with Claude Code, OpenCode, and pi through environment variables. OpenCode and pi also work with OrcaRouter and any OpenAI-compatible gateway, and Bedrock via pi is alpha. Not every gateway works with every harness, so check the [provider capability matrix](https://docs.agent-swarm.dev/docs/guides/provider-capability-matrix) before planning a move; gateway authentication is covered in the [model gateways guide](https://docs.agent-swarm.dev/docs/guides/provider-auth/model-gateways). Memory is stored in SQLite, with sqlite-vec for vectors. The embedding endpoint can be any OpenAI-compatible URL (Azure, Together, vLLM, Ollama), and keyword search still works with no embedding key at all, so the memory layer never depends on a single embedding vendor. All swarm state (tasks, agents, schedules, config) lives in one SQLite database on the `swarm_api_data` volume, and the [deployment docs](https://docs.agent-swarm.dev/docs/guides/deployment) give a copy-the-volume backup and restore procedure. The secrets encryption key must be backed up alongside the database, because without it the stored credentials are unreadable. That database-and-key backup does not cover what lives outside the database: workspace files on the shared and per-agent volumes, custom skill files agents keep on disk, and the file logs on the log volume. Inventory those assets, decide per volume what you would actually miss, and verify with a real restore drill that you can get them back, not just the database. Script credentials use host-bound bindings and server-side injection. This keeps broker-managed request credentials out of agent prompts. Provider responses and arbitrary tool output still need review. The Agent Swarm skills plugin installs into Claude Code and Codex, and into OpenCode, pi, and others via `npx skills add desplega-ai/agent-swarm`, so skills follow the harness instead of being rebuilt per vendor. Session continuity uses a bounded context preamble rather than harness-native resume, which is what lets a task move to a different harness; the mechanism is covered in the [context preamble deep dive](/blog/deep-dive-context-preamble-session-resume), and the broader case for this architecture is in [deployment guide](https://docs.agent-swarm.dev/docs/guides/deployment). None of this makes migration free, and there is no one-click export UI. It changes the shape of the exit, from "rebuild the factory" to "retune and re-validate." ## The migration costs portability does not remove Portability removes custody problems. It does not remove engineering work. Four costs survive every exit, and planning for them is what makes the exit cheap enough to threaten: - **Prompt and skill tuning per model.** Prompts that sing on one model can go flat on another, and skills need re-testing against the target model. Budget days, not minutes, per critical workflow. - **Capability gaps between harnesses.** Steering, skills paths, and spend tracking differ by provider. A workflow that leans on mid-run steering on one harness may need restructuring on another, and spend reporting you relied on may not exist in the same form. - **Re-validating evals.** Your eval suite was calibrated against the old stack. Expect to re-baseline scores and re-check regressions on the new model and harness before you trust the move for production work. - **The ops burden of self-hosting.** If you self-host to gain portability, upgrades, backups, and monitoring become your job. That is a staffing cost, and pretending it is zero is how backup drills quietly stop happening. Portability means the exit is possible and cheap enough to threaten, not that it is free. A credible threat is usually enough. Vendors negotiate differently with customers who can leave within a quarter. ## When a managed or single-provider setup is the better choice The exit test is a tool for seeing your dependency clearly, not a command to eliminate it at any cost. Accepting the dependency is often the rational move: - Your team is small and all of your context fits in one harness. Portability insurance costs more than the risk it covers. - You are a one-harness shop with no second runtime planned. If nothing in your roadmap points at a move, optimize for depth on one stack. - You have no ops capacity. A self-hosted control plane with neglected backups is worse than a vendor with good ones. - Your compliance regime is one the vendor already handles. Rebuilding that evidence chain yourself is real work with no product payoff. Agent Swarm is free self-hosted software under MIT. Discuss enterprise support with the team for services, scope, and data-handling requirements agreed separately. If you are comparing self-hosted options more broadly, the roundup of [open-source, self-hostable agent platforms](/blog/best-open-source-ai-agent-platforms-self-host) covers the field. The decision rule is not "dependencies are bad." It is: know which dependencies you hold, price the exit honestly, and re-check after each growth step, because the setup that fits a three-person team rarely fits a thirty-person one. ## Portability checklist - [ ] Agent definitions and skills live in files or a database you can back up - [ ] You can switch model or gateway with a config change, no code edits - [ ] You can export full prompts, traces, and task history on demand - [ ] Agent memory exports to a format you control and can re-import - [ ] The same task runs on at least one other harness - [ ] Secrets are bound per host and injected server-side, never pasted into prompts - [ ] You have restored the full system from your own backup onto a fresh host in the last quarter - [ ] The backup includes the secrets encryption key alongside the database - [ ] You know which provider capabilities (steering, skills paths, spend tracking) your workflows depend on - [ ] The exit test has a named owner and a recurring schedule ## FAQ ### Is using a paid API already lock-in? No. Paying per token is an operational dependency: visible, priced, and substitutable. Lock-in starts when the asset that makes your agents effective, your definitions, skills, memory, and run history, cannot leave with you. A paid API sitting under context you own is a normal vendor relationship. ### How is coding-agent lock-in different from SaaS lock-in? With classic SaaS, the export is the asset: records out, records in, and you are done. With coding agents, the asset is the accumulated context, and it compounds with use. The model is rented compute; the context layers are the factory, and factories do not fit in a CSV export. ### What should we export first if we can only do one thing? Export the factory definitions: agents, skills, workflows, and schedules. They are small, they change slowly, and they regenerate value fastest on a new stack because they encode how your work gets done. Memory and run history come next, and both should be on the roadmap within a quarter. ### Does self-hosting remove lock-in completely? No. Self-hosting removes vendor custody, but you can still lock yourself into your own conventions, and the migration costs above (retuning, capability gaps, eval re-validation, ops burden) still apply. It converts lock-in from a custody problem into a portability discipline you have to maintain. ### How often should we run the exit test? Quarterly is a good default, plus any time a vendor changes pricing, deprecates something you use, or a renewal comes up. Give the restore question special treatment: a backup you have never restored from is a hypothesis, so run the actual restore drill at least once per cycle. --- # Shared-Context AI Agents: Patterns, Risks, and Setup > What shared-context AI agents are, how shared context differs from memory and private state, the risks, and how to run governed sharing. Published: 2026-10-07T00:00:00Z Read time: 12 min read Tags: `shared-context ai agents`, `multi-agent context sharing`, `agent memory vs shared state`, `multi-agent orchestration`, `agent context governance`, `shared workspace ai agents`, `self-hosted ai agents`, `prompt injection multi-agent`, `lead and worker agents`, `ai agent human review` Canonical URL: https://www.agent-swarm.dev/blog/shared-context-ai-agents --- Shared-context AI agents are several agents working toward one team objective that read from and write to a common, governed context, meaning definitions, decisions, findings, and task history, instead of each agent starting from a blank prompt. Teams use them when the work is too broad for a single agent session and when the cost of every agent re-learning the same facts exceeds the cost of governing a shared store. An illustrative example: a lead agent splits a release-readiness check across three workers. One reviews the pull request, one checks the incident log, one drafts the changelog. Each worker writes its findings to a shared record that the other agents and the humans on the team can read, so the changelog writer sees the reviewer's risk notes without a separate handoff. An approval request then pauses the workflow until a human reviewer signs off on the readiness call, and only the approved result is kept as the durable record. *** > **TL;DR:** > > - Shared-context AI agents coordinate through a common, governed store of definitions, decisions, and findings, not through bigger prompts or copied chat history. > - Shared context is one layer among five: it differs from private agent state, the session context window, long-term memory, and operational workflow state, and each layer fails differently. > - The patterns that work in practice are a shared workspace, scoped retrieval, lead-and-worker coordination, durable records, and human review. > - The real risks are context contamination, permission leakage, stale facts, conflicting writes, and prompt-injection propagation. Each has a concrete mitigation, and none of them disappear on their own. > - Agent Swarm implements shared context through two memory scopes, isolated worker containers with one shared volume, lead-and-worker delegation, encrypted secrets with egress injection, and human steering and approvals. *** ## Table of Contents - [Shared context vs memory vs private state](#shared-context-vs-memory-vs-private-state) - [Patterns teams use](#patterns-teams-use) - [Risks and how to contain them](#risks-and-how-to-contain-them) - [How Agent Swarm implements shared context](#how-agent-swarm-implements-shared-context) - [Getting started](#getting-started) - [Sources](#sources) - [FAQ](#faq) ## Shared context vs memory vs private state The phrase "shared context" gets used for at least five different things, and teams design badly when they collapse them. A context window is not memory, memory is not a shared workspace, and a task queue is not any of those. Before choosing tools, decide which layer each piece of information belongs to. | Layer | What it holds | Who can read it | How long it lives | Typical failure | |---|---|---|---|---| | Shared context | Team definitions, decisions, findings, task history | Every agent on the team, plus the humans | Across sessions, until curated | Contamination: one bad fact spreads to every agent | | Private agent state | One agent's working notes, preferences, scratch state | That agent, plus documented lead access | Across that agent's sessions | Siloed knowledge nobody else can reuse | | Session context (context window) | The tokens a model can attend to in one request | The model, for that request only | One session | Eviction: critical facts fall out of the window | | Long-term memory | Curated, durable facts retrieved on demand | Whoever the memory scope allows | Months or indefinitely | Poisoning: a bad write is trusted as fact later | | Operational workflow state | Queues, locks, run status, schedules | The orchestrator and its agents | Until the run completes | Lost runs and duplicate work after a restart | Two clarifications prevent most confusion. First, the context window is volatile working memory that resets every session, while long-term memory is a durable store that feeds relevant facts back into that window through retrieval. Our [memory architecture documentation](https://docs.agent-swarm.dev/docs/architecture/memory) covers that distinction in depth, including why raw token capacity does not behave like memory. Second, "shared" is a property of the scope, not of the storage. Two agents can sit on the same database and still have fully private memories if the scope rules say so. When people say shared-context AI agents, they mean agents whose governance layer deliberately makes some context common and keeps the rest private. The design question is never "should agents share context" but "which layer should hold this fact, and who is allowed to read it." Answer that per fact type and the architecture follows. ## Patterns teams use Five patterns show up in nearly every working multi-agent setup. Most teams combine several of them. ### Shared workspace Agents read and write common artifacts: a findings record, a draft document, a decision log. The workspace is the blackboard the team gathers around. **When to use it:** when a deliverable or an intermediate finding must be visible to several agents and to humans, and when "who saw what" needs to be obvious rather than reconstructed from logs. ### Scoped retrieval The team stores far more than any prompt can hold, and each agent retrieves a narrow, relevance-ranked slice instead of reading everything. Scopes decide what is even eligible for retrieval. **When to use it:** the moment accumulated memory outgrows what fits in a context window, which happens within weeks on any active team. Retrieval without scopes eventually leaks; scopes without retrieval eventually flood. ### Lead-and-worker coordination A lead agent breaks an objective into tasks, delegates them to workers, monitors progress, and gives feedback. Workers report results back to shared records instead of negotiating peer to peer. **When to use it:** whenever tasks have dependencies, quality gates, or different required expertise. Hub-and-spoke coordination keeps write conflicts low because the lead arbitrates, at the price of making the lead a component you have to monitor. ### Durable records Task history, decisions, and findings persist as append-only records that survive restarts and redeploys. **When to use it:** when you will later ask "why did we decide this," when new agents must onboard onto existing team knowledge, and when an audit trail matters. Microsoft's [shared agent context writeup](https://techcommunity.microsoft.com/blog/appsonazureblog/shared-agent-context-how-we-are-tackling-partner-agent-collaboration/4505714) describes the same operational shape: agents investigate in real time, then persist findings where humans already work. ### Human review People steer running tasks and approve sensitive or irreversible actions before they execute. **When to use it:** for anything customer-facing, anything that spends money, and anything that cannot be undone. Asana's [work on agents built for teams](https://asana.com/inside-asana/ai-agents-built-for-teams-context-transparency) makes the broader point well: shared work needs transparency about what the agent did and why, or humans stop trusting the system and route around it. ## Risks and how to contain them Shared context multiplies both the value and the blast radius of what agents write. This section is the part most vendor pages skip, and it is the part that decides whether your setup survives contact with production. **Context contamination.** One agent writes a wrong or outdated fact to shared context, and every other agent retrieves it later as trusted input. Because retrieval feels authoritative, the error compounds across sessions instead of staying local to one run. Mitigation: validate on write, keep the shared scope curated rather than a free-text dump, and expire unverified facts instead of letting them live forever. **Permission leakage.** A single shared store flattens access: anything written to it becomes visible to every agent, including agents that have no business seeing it. The failure is quiet, because nothing errors. Mitigation: decide per fact type what is shared versus private, keep sensitive material out of the shared scope entirely, and never let credentials live in any context an agent can read. **Stale facts.** A fact that was true when written gets retrieved months later as if it were current. Statuses, counts, and decisions age badly. Mitigation: timestamp everything, set time-to-live on categories that decay, and re-read the live state of ongoing work at the moment you act on it rather than trusting the stored version. The mechanics of how memory degrades, and how poisoning compounds across repeated writes, are covered in our [memory retrieval case study](/blog/is-grep-all-you-need-agent-memory). **Conflicting writes.** Two agents write different versions of the same fact, and the next reader gets whichever one retrieval happens to rank higher. There is no magic merge: unless the platform explicitly offers compare-and-set semantics, assume last-writer-wins and design around it. Mitigation: assign a single writer per record where you can, route contested facts through the lead for arbitration, and surface conflicts to a human instead of silently picking one. Our [delegation architecture article](/blog/task-delegation-architecture) walks through the failure shapes this produces. **Prompt-injection propagation.** One agent reads hostile content from a web page, ticket, or message and writes a summary of it into shared context. A later agent retrieves that summary, and the embedded instruction fires in a new context with new permissions. Shared context turns a one-agent injection into a team-wide one. Mitigation: preserve source provenance, treat retrieved content as data, and prevent it from granting authority. Require human approval for sensitive actions. Wording filters cannot establish trust. None of these risks is a reason to avoid shared context. They are the reason the word "governed" belongs in the definition. ## How Agent Swarm implements shared context [Agent Swarm](https://www.agent-swarm.dev) is an open-source operating system for multi-agent work, and its shared-context model maps directly onto the patterns above. This section sticks to documented behavior; for anything beyond it, the [Agent Swarm documentation](https://docs.agent-swarm.dev/docs), starting with the [architecture overview](https://docs.agent-swarm.dev/docs/architecture/overview) and [memory documentation](https://docs.agent-swarm.dev/docs/architecture/memory), is the source of truth. **Two memory scopes, deliberately simple.** Every memory in Agent Swarm is either agent-scoped, private to the agent that owns it, or swarm-scoped, readable by all agents. One deliberate exception: the lead's memory searches span every agent's private scope, because the lead curates the shared layer and needs to see what workers accumulate to do it. The lead can push a learning into a worker's memory with `inject-learning`, which creates a swarm-scoped memory by default, so a lesson learned in one task becomes available to the whole team. Only the lead can delete swarm-scoped memories, and editing another agent's memory requires the lead, which keeps the shared layer curated instead of crowdsourced. Memory search respects scope at retrieval time, and the graph expansion that follows links between memories can never widen what a search is allowed to see. **Retrieval is automatic, and failures are remembered.** Before each task starts, the runner searches for memories relevant to the task description and injects the top matches into the agent's context. Completed and failed task outputs are indexed. Failure notes let agents retrieve earlier problems. Retrieval alone does not guarantee that agents avoid the same mistake. This is the scoped-retrieval pattern running by default rather than as a plugin. **Isolated workers, one shared volume.** Each worker runs in its own container with a private `/workspace/personal` directory. There is also a single `/workspace/shared` volume mounted into every agent. It is shared by design: there are no per-agent permissions on that volume, so treat it as a team blackboard and keep anything sensitive out of it. The lead-and-worker structure is hub-and-spoke: the lead breaks work down, delegates, monitors, and gives feedback, as described in the [delegation architecture article](/blog/task-delegation-architecture). **Credentials stay out of agent context.** Secrets in the config store are encrypted at rest with AES-256-GCM. Calls through registered connections receive broker-managed credentials at egress. Those request credentials stay outside agent context. Responses and arbitrary tool output still require review. This is the containment for the permission-leakage risk above, and the [credential broker guide](https://docs.agent-swarm.dev/docs/guides/scripts-credential-broker) explains the mechanics. The [Security and Trust page](https://www.agent-swarm.dev/security) and the [integrations catalog](https://www.agent-swarm.dev/integrations) cover the surrounding posture. One precision worth stating: role-based access control in Agent Swarm governs REST API calls made with user tokens; it does not gate agent-to-agent calls inside the swarm. Governance between agents comes from memory scopes and lead privileges, not from per-user ACLs on agents. Our [security page](/security) goes deeper on that boundary. **Self-hosted by default.** The SQLite database holding tasks, memory, and config lives on a volume you own, and workers call your chosen model provider with your keys. For enterprise support, agree data-handling requirements with the team through the [Security page](https://www.agent-swarm.dev/security). **Humans stay in the loop.** Task steering lets a person redirect a running task, and approval requests pause work until a human signs off, which is the containment for irreversible actions. The [architecture overview](https://docs.agent-swarm.dev/docs/architecture/overview) covers the pattern. You can see all of this operating in real sessions in the [examples collection](https://www.agent-swarm.dev/examples). The [memory architecture documentation](https://docs.agent-swarm.dev/docs/architecture/memory) describes memory scope and persistence. ## Getting started You do not need the full architecture on day one. Four steps get a team to governed shared context without overbuilding. 1. **Decide what is shared versus private before you write anything.** List your fact types: team definitions, decisions, findings, credentials, personal working notes. Assign each a layer from the table above. Credentials get the shortest answer: never in any context, shared or private, that an agent can read. 2. **Start with swarm-scoped memory for agreed definitions only.** Seed the shared scope with the facts the whole team has already agreed on, and let everything else accumulate in private scopes until it earns promotion. A small, trusted shared scope beats a large, noisy one every time. 3. **Keep credentials in registered connections.** Store API keys in the encrypted config store and route external calls through connections so secrets are injected at egress. This removes the single most damaging leak path before it exists. 4. **Add human approval on irreversible actions.** Identify the actions you cannot undo, production deploys, customer messages, deletions, and gate them behind approval requests from the start. Retrofitting review after an incident costs far more than the friction it saves. ## Sources Two external articles informed this guide. - [AI agents built for teams: context, transparency, and accountability (Asana)](https://asana.com/inside-asana/ai-agents-built-for-teams-context-transparency), on why shared agent work needs inspectable context and action-level accountability to earn team trust. - [Shared agent context: tackling partner agent collaboration (Microsoft)](https://techcommunity.microsoft.com/blog/appsonazureblog/shared-agent-context-how-we-are-tackling-partner-agent-collaboration/4505714), on the operational pattern of agents investigating in real time and persisting findings where humans already work. ## FAQ ### What are shared-context AI agents? Shared-context AI agents are several agents working toward one team objective that read from and write to a common, governed context instead of each starting from a blank prompt. The shared context holds definitions, decisions, findings, and task history. Teams use them when work spans more than one agent session and re-learning the same facts per agent costs more than governing a shared store. ### What is the difference between shared context and memory? Long-term memory is a durable store of curated facts that gets retrieved into a model's context window on demand. Shared context is the subset of that stored context, plus shared artifacts and records, that is deliberately made visible to every agent on the team. Memory answers "what persists," while shared context answers "who is allowed to see it." ### How do teams keep agents from seeing everything? By scoping. Each piece of stored context carries a scope that decides which agents may retrieve it, and retrieval respects those scopes automatically. A private scope is readable only by the agent that owns it, with one exception: the lead's memory searches span every agent's private scope, because the lead curates the shared layer. So a private scope is working room, not a vault. Sensitive material belongs out of agent context entirely, and credentials should live in an encrypted store that injects them at egress rather than into anything an agent can read. ### Can shared context be self-hosted? Yes. Agent Swarm, for example, stores tasks, memory, and config in a SQLite database on a volume you own, and workers call your chosen model provider with your own keys. Self-hosting gives you direct control over where the shared context physically lives and who can reach the machine that holds it. ### What happens when two agents write conflicting facts? Unless the platform offers explicit compare-and-set semantics, assume last-writer-wins and design around it. Practical teams assign a single writer per record where possible, route contested facts through a lead agent for arbitration, and surface unresolved conflicts to a human reviewer instead of silently picking one version. ### How do humans review what agents share? Through steering and approval gates. Task steering lets a person redirect running work, and approval requests pause sensitive or irreversible actions until a human signs off. Durable task records and inspectable memory make the review possible, because a human can see what was written, by whom, and why. --- # We Deleted --resume: A Bounded Preamble Beats Session Resume > Why Agent Swarm dropped claude --resume and codex.resumeThread for an approximately 2,000-token context preamble that survives container restarts and harness re-routing. Published: 2026-10-07T00:00:00Z Read time: 10 min read Tags: `session continuity`, `context preamble`, `harness routing`, `deep dive`, `agent-swarm` Keywords: `agent-swarm`, `AI agents`, `orchestration`, `session resume`, `context preamble`, `Claude Code`, `Codex`, `OpenCode`, `coding agents`, `session continuity` Canonical URL: https://www.agent-swarm.dev/blog/deep-dive-context-preamble-session-resume --- This post is rendered as React components on the canonical URL. For the full content with code blocks, diagrams, and inline links, fetch the HTML at [https://www.agent-swarm.dev/blog/deep-dive-context-preamble-session-resume](https://www.agent-swarm.dev/blog/deep-dive-context-preamble-session-resume) (send `Accept: text/html`). A short summary, plus the listed metadata above, is provided here so AI agents performing content negotiation can index the article without parsing the React tree. --- # Your Agents Write the Titles Your Trackers Read > An IMDEA audit of 9 AI chat services found trackers receiving titles, permalinks and screenshots, not just prompts. Agent swarms multiply those artifacts. Published: 2026-10-05T00:00:00Z Read time: 11 min read Tags: `privacy`, `telemetry`, `agent artifacts`, `observability`, `agent-swarm` Keywords: `agent-swarm`, `AI agents`, `orchestration`, `privacy`, `IMDEA audit`, `LLM privacy`, `auto-titles`, `permalinks`, `telemetry`, `agent artifacts` Canonical URL: https://www.agent-swarm.dev/blog/deep-dive-agent-artifacts-privacy-leak --- This post is rendered as React components on the canonical URL. For the full content with code blocks, diagrams, and inline links, fetch the HTML at [https://www.agent-swarm.dev/blog/deep-dive-agent-artifacts-privacy-leak](https://www.agent-swarm.dev/blog/deep-dive-agent-artifacts-privacy-leak) (send `Accept: text/html`). A short summary, plus the listed metadata above, is provided here so AI agents performing content negotiation can index the article without parsing the React tree. --- # 12 Self-Hosted AI Agent Platforms: Open-Source and Source-Available Options > Twelve self-hosted AI agent platforms, including open-source projects and a labeled source-available exception. October 2026 snapshot of licenses, installation, and limitations. Published: 2026-10-02T00:00:00Z Read time: 10 min read Tags: `best open source ai agents`, `open source agent platform`, `self hosted ai agents`, `self hosted agent platform`, `AI agent platforms` Canonical URL: https://www.agent-swarm.dev/blog/best-open-source-ai-agent-platforms-self-host --- For visual agent and workflow building, start with Dify or Langflow. For a standing team of agents with shared memory that takes work from Slack, Linear and GitHub, look at Paperclip or Agent Swarm; for coding agents and automations on your own backends, Agent Canvas. If what you want is a personal assistant across messaging apps, OpenClaw or Hermes Agent are the strongest picks — and every platform below is open-source, self-hostable from its public repo today, and a platform you run rather than a library you import. ## How We Chose Every platform on this list passes three criteria: 1. **An open-source license, with one labeled exception.** MIT and Apache-2.0 projects qualify, including open-core repositories with separate enterprise licenses. Dify is a source-available exception. Its modified Apache-2.0 license adds restrictions, so we do not describe it as OSI-approved. Licenses that restrict what you may use the software for, n8n's Sustainable Use License, AutoGPT Platform's PolyForm Shield, do not qualify. 2. **Self-hostable today.** You can deploy it from the public repository right now, without buying a license. 3. **A platform, not a library.** A server or application you run, with a UI or API, to build or operate agents. Frameworks and SDKs you import into your own code are out of scope. Project status, installation paths, and stars below describe the October 2, 2026 snapshot. Entries are numbered by GitHub stars as of October 2, 2026, an objective popularity ordering, not an editorial ranking. The direct answer above is the editorial part: the best platform depends on your use case, and the biggest projects are personal assistants, not team platforms. ## 1. OpenClaw — 391,191 stars **What it is:** An open-source AI assistant that runs on your own computer, reachable across more than 20 chat channels. **License:** MIT license text (GitHub shows NOASSERTION, likely because the file adds a pointer to THIRD_PARTY_NOTICES.md). **How to self-host:** An install script, `npm i -g openclaw`, Docker or Docker Compose, or Nix. **Best for:** A personal assistant living across your messaging apps. **One real limitation:** OpenClaw's own security docs state it is "not a hostile multi-tenant security boundary" — plan one gateway per trust boundary. ## 2. Hermes Agent — 250,755 stars **What it is:** "The self-improving AI agent built by Nous Research" — a personal agent with scheduled jobs. **License:** MIT. **How to self-host:** An install script, Docker, a desktop app, or Termux on Android. **Best for:** A personal agent across Telegram, Slack and Discord, with cron jobs for recurring work. **One real limitation:** The default `local` backend has no isolation — Hermes' security docs rate it "None — runs on host", so the agent executes directly on your machine. ## 3. Dify — 157,730 stars **What it is:** A collaborative workspace to build agentic workflows and RAG pipelines, with broad model and tool support. **License:** The "Dify Open Source License" — Apache 2.0 with added conditions and no SPDX identifier. Two conditions matter: you may not use the Dify source code to operate a multi-tenant environment without written authorization, and you may not remove or modify the logo or copyright information in the frontend. **How to self-host:** Docker Compose, with a documented minimum of 2 CPU and 4 GiB RAM. Note that the README no longer documents an official Helm chart; Helm charts for Dify are community-made. **Best for:** Teams building RAG and agent workflow apps in one visual workspace. **One real limitation:** Multi-tenant operation requires written authorization under the quoted license. SSO and RBAC are Dify Enterprise features. Read the license for your deployment. ## 4. Langflow — 155,451 stars **What it is:** A platform for building and deploying AI-powered agents and workflows, with a visual builder plus built-in API and MCP servers. **License:** MIT. **How to self-host:** `uv pip install langflow`, the `langflowai/langflow` Docker image, Docker Compose with Postgres, or Langflow Desktop. **Best for:** Python developers who want visual flows they can expose as APIs or MCP tools. **One real limitation:** A shared Langflow server needs hardening before you expose it: code-execution components are allowed by default, and on non-Docker installs `AUTO_LOGIN=True` signs everyone in as the superuser. ## 5. Paperclip — 96,265 stars **What it is:** A Node.js server and React UI that orchestrates a team of AI agents. **License:** MIT. **How to self-host:** `npx paperclipai@latest onboard` (requires Node 24.11 or newer, with an embedded Postgres) or Docker Compose. **Best for:** Running many agents — Claude, Codex, OpenClaw and others — like a company, with an org chart, budgets and approvals. **One real limitation:** Paperclip describes itself as "not an agent framework": your agents bring their own prompts, models and runtimes, and several features are labelled Experimental. ## 6. Agent Canvas (formerly OpenHands) — 89,818 stars **What it is:** Since July 2026 the OpenHands repo is Agent Canvas, "the self-hosted developer control center for coding agents and automations". The pre-rename code lives on under OpenHands/legacy. **License:** MIT. **How to self-host:** `npm i -g @openhands/agent-canvas`, the `ghcr.io/openhands/agent-canvas` Docker image, or the Helm chart in the repo. **Best for:** Running coding agents and automations — with Slack, GitHub and Linear triggers — on your own backends. It works with OpenHands, Claude Code, Codex and ACP-compatible agents. **One real limitation:** Access control is a single shared `LOCAL_BACKEND_API_KEY`; there are no per-user accounts, and anyone who reaches the server gets filesystem and shell access. ## 7. AnythingLLM — 66,670 stars **What it is:** An all-in-one AI application — a private ChatGPT with built-in agents. **License:** MIT. **How to self-host:** Docker, or the desktop application. **Best for:** Chatting with your documents (RAG) plus no-code agent flows. **One real limitation:** Multi-user permissions and the embeddable chat widget are available in the Docker version only; the desktop app is single-user. ## 8. LibreChat — 45,204 stars **What it is:** An enhanced ChatGPT clone featuring agents, MCP and skills, for many model providers. **License:** MIT. **How to self-host:** Docker Compose, a Helm chart, or npm. **Best for:** Multi-user, multi-provider chat with an agent builder on top. **One real limitation:** The Agent Management API is beta, and attached workspaces are flagged "highly experimental" in the current release notes — the agent layer is newer than the chat layer. ## 9. Sim — 29,762 stars **What it is:** A collaborative workspace to build, deploy and monitor AI agents and workflows. **License:** Apache-2.0 for the core; enterprise code under `apps/sim/ee/` sits under a separate license. **How to self-host:** `npx sim-setup`, Docker Compose, or Kubernetes with Helm. **Best for:** Mixed technical and non-technical teams who want a visual, chat-driven workspace for agent workflows, with knowledge bases, MCP and local models via Ollama. **One real limitation:** SSO, access-control groups, SCIM and whitelabeling live in the enterprise directory, and Sim's own docs state that production deployment of those features requires an active Enterprise subscription. The smallest documented self-hosted setup (1-5 users) also asks for 12 GB of RAM. ## 10. Activepieces — 24,858 stars **What it is:** An open-source replacement for Zapier: AI agents and automations, with its integrations ("pieces") exposable as MCP servers. **License:** MIT for the core; `packages/ee/` is under the Activepieces Enterprise License. **How to self-host:** Docker Compose (the recommended path), Helm, or a single-container install. **Best for:** Business-user automation with AI agents and MCP in the loop. **One real limitation:** Projects and multi-tenancy, SSO, custom roles, SCIM and audit logs all require a paid license key. ## 11. Letta Code — 3,500 stars **What it is:** The current home of Letta, the platform for stateful agents — "AI with advanced memory that can learn and self-improve over time". The V1 server is on the `archive` branch; active source lives in letta-ai/letta-code. **License:** Apache-2.0. **How to self-host:** `npm install -g @letta-ai/letta-code`, then run `letta server`. **Best for:** Stateful agents with long-term memory that persists and grows across sessions. **One real limitation:** Letta Cloud is the default backend, and running agents across machines ("remote computers") requires signing in with Letta. ## 12. Agent Swarm — 851 stars **What it is:** An open-source operating system for AI work. A lead agent delegates goals to workers running in isolated Docker containers, and shared memory, tools, schedules and review gates preserve work across sessions. It runs your agents on Claude Code, Codex, pi-mono, Devin, or any ACP-compatible runtime. (Disclosure: Agent Swarm is built by the team behind this blog.) **License:** MIT. **How to self-host:** The CLI wizard `bunx @desplega.ai/agent-swarm onboard` (which generates the compose file and `.env`, starts the stack and checks health), Docker Compose directly, Kubernetes with Helm, or rootless Podman. Images publish to `ghcr.io/desplega-ai/agent-swarm`. **Best for:** A standing team of agents with shared memory that takes work from Slack, Linear and GitHub — with integrations for GitLab, email, Jira, Sentry and more, plus scheduled tasks and a DAG workflow engine with human-in-the-loop approvals. **One real limitation:** It is a multi-container stack, not a single binary: the example deployment runs an API server, a lead, workers and object storage, and the documented sizing starts at 2-4 vCPU and 4-8 GiB of RAM for one lead plus one worker. Agent Swarm has the smallest GitHub community on this list, which is exactly where our stated ordering puts it. Its entry describes only what its repository and docs document. ## Comparison Table | # | Platform | License | Self-host via | Best for | GitHub stars (2026-10-02) | |---|---|---|---|---|---| | 1 | OpenClaw | MIT | Install script, npm, Docker, Nix | Personal assistant across messaging apps | 391,191 | | 2 | Hermes Agent | MIT | Install script, Docker, desktop | Personal agent with cron jobs | 250,755 | | 3 | Dify | Modified Apache-2.0 (no multi-tenant) | Docker Compose | Visual RAG and agent workflow apps | 157,730 | | 4 | Langflow | MIT | pip/uv, Docker, Compose, desktop | Visual flows exposed as APIs or MCP tools | 155,451 | | 5 | Paperclip | MIT | npx onboard, Docker Compose | Running many agents like a company | 96,265 | | 6 | Agent Canvas (OpenHands) | MIT | npm, Docker, Helm | Coding agents and automations on your backends | 89,818 | | 7 | AnythingLLM | MIT | Docker, desktop | Document chat (RAG) plus no-code agent flows | 66,670 | | 8 | LibreChat | MIT | Docker Compose, Helm, npm | Multi-user, multi-provider chat with agents | 45,204 | | 9 | Sim | Apache-2.0 (open core) | npx sim-setup, Docker Compose, Helm | Visual workspace for mixed teams | 29,762 | | 10 | Activepieces | MIT (open core) | Docker Compose, Helm, single container | Business automation with AI agents and MCP | 24,858 | | 11 | Letta Code | Apache-2.0 | npm, `letta server` | Stateful agents with long-term memory | 3,500 | | 12 | Agent Swarm | MIT | CLI wizard, Docker Compose, Helm, Podman | A standing agent team with shared memory | 851 | ## Who Didn't Make the List, and Why Some of the most-cited names for this query fail our criteria today: - **CrewAI** — the open-source project is a pip/uv library; the platform (CrewAI AMP) is a commercial control plane whose self-hosted form is a licensed Helm chart. It fails criterion 3. - **Botpress** — self-hosted Botpress v12 has been officially sunset and is no longer available for new deployments. It fails criterion 2. - **Flowise** — the team wound down operations in August 2026; the repository was archived on August 13, 2026 and reached end of life on August 31, 2026. Users are advised to fork. - **Amplifi Labs** — a product-development agency, not an open-source platform. Engine mentions of it for this query appear to be a naming error. - **n8n** and **AutoGPT Platform** — both excellent and self-hostable, but the Sustainable Use License and PolyForm Shield license restrict what you may use the software for, so they are not open source under criterion 1. ## The Bottom Line Pick by use case, not by star count: the two biggest projects here are personal assistants, and the best team platform for you depends on whether you build workflows visually, chat with documents, or run agents as standing infrastructure. Before committing, read the license file in the repo — "open-source" covers everything from MIT to licenses that ban multi-tenant use — and check the self-hosting docs for the hardware floor. Every fact above traces to the sources listed below, verified October 2, 2026. ## Sources - OpenClaw: https://github.com/openclaw/openclaw , https://github.com/openclaw/openclaw/blob/main/LICENSE , https://docs.openclaw.ai/install/docker , https://docs.openclaw.ai/gateway/security - Hermes Agent: https://github.com/NousResearch/hermes-agent/blob/main/README.md , https://github.com/NousResearch/hermes-agent/blob/main/LICENSE , https://hermes-agent.nousresearch.com/docs/getting-started/installation , https://hermes-agent.nousresearch.com/docs/user-guide/docker , https://hermes-agent.nousresearch.com/docs/user-guide/security - Dify: https://github.com/langgenius/dify , https://github.com/langgenius/dify/blob/main/LICENSE , https://docs.dify.ai/en/self-host/quick-start/docker-compose , https://github.com/langgenius/dify/blob/main/README.md - Langflow: https://github.com/langflow-ai/langflow , https://github.com/langflow-ai/langflow/blob/main/LICENSE , https://docs.langflow.org/deployment-docker , https://docs.langflow.org/api-keys-and-authentication - Paperclip: https://github.com/paperclipai/paperclip/blob/master/README.md , https://github.com/paperclipai/paperclip/blob/master/LICENSE , https://docs.paperclip.ing/reference/deploy/docker/ - Agent Canvas: https://github.com/OpenHands/OpenHands/blob/main/README.md , https://github.com/OpenHands/OpenHands/pull/15397 , https://github.com/OpenHands/OpenHands/blob/main/LICENSE , https://github.com/OpenHands/OpenHands/blob/main/docs/SELF_HOSTING.md , https://github.com/OpenHands/legacy - AnythingLLM: https://github.com/Mintplex-Labs/anything-llm/blob/master/README.md , https://github.com/Mintplex-Labs/anything-llm/blob/master/LICENSE , https://docs.anythingllm.com/installation-docker/overview - LibreChat: https://github.com/LibreChat-AI/LibreChat , https://github.com/LibreChat-AI/LibreChat/blob/main/LICENSE , https://www.librechat.ai/docs/local/docker , https://www.librechat.ai/docs/local/helm_chart , https://github.com/LibreChat-AI/LibreChat/blob/main/README.md - Sim: https://github.com/simstudioai/sim , https://github.com/simstudioai/sim/blob/main/LICENSE , https://github.com/simstudioai/sim/blob/main/apps/sim/ee/LICENSE , https://docs.sim.ai/platform/self-hosting , https://github.com/simstudioai/sim/blob/main/apps/sim/ee/README.md - Activepieces: https://github.com/activepieces/activepieces , https://github.com/activepieces/activepieces/blob/main/LICENSE , https://github.com/activepieces/activepieces/blob/main/packages/ee/LICENSE , https://www.activepieces.com/docs/install/overview.md , https://www.activepieces.com/docs/install/configure-operate/enterprise-license.md - Letta Code: https://github.com/letta-ai/letta , https://github.com/letta-ai/letta-code , https://github.com/letta-ai/letta-code/blob/main/README.md , https://docs.letta.com - Agent Swarm: https://github.com/desplega-ai/agent-swarm , https://github.com/desplega-ai/agent-swarm/blob/main/LICENSE , https://docs.agent-swarm.dev/docs/getting-started , https://docs.agent-swarm.dev/docs/guides/deployment , https://docs.agent-swarm.dev/docs/guides/harness-providers , https://docs.agent-swarm.dev/docs/guides/performance-resource-sizing , https://docs.agent-swarm.dev/docs/integrations - Excluded projects: https://github.com/crewAIInc/crewAI/blob/main/README.md , https://enterprise-docs.crewai.com/installation/installation , https://botpress.com/docs/studio/guides/advanced/v12/ , https://github.com/FlowiseAI/Flowise/discussions/6727 , https://www.amplifilabs.com/ , https://github.com/n8n-io/n8n/blob/master/LICENSE.md , https://github.com/Significant-Gravitas/AutoGPT/blob/master/autogpt_platform/LICENSE.md - Star counts and latest releases: each project's GitHub repository page, linked above, as of October 2, 2026. --- # A TLA+ Playbook for Your Scheduler, Queue or Retry Loop > Five steps, one prompt each: model a concurrent subsystem in TLA+, calibrate it on bugs you already fixed, turn every counterexample into a failing test, and keep the spec true with a daily swarm workflow. Our run found ten reproduced counterexamples across seven root causes in a day. Published: 2026-09-29T00:00:00Z Read time: 5 min read Tags: `TLA+`, `formal verification`, `concurrency`, `race conditions`, `heartbeat`, `AI agents` Canonical URL: https://www.agent-swarm.dev/blog/tla-plus-races-agent-swarm --- Boris Cherny [posted](https://x.com/bcherny/status/2102543349102338309) that two prompts and a Lean model of the Claude Agent SDK produced 16 PRs fixing races. The recipe: model the race-prone part, find counterexamples, reproduce, fix. We ran it on Agent Swarm with TLA+. One day, ten reproduced counterexamples across seven root causes. The dated results below distinguish traces, tests, and merged fixes. Five steps, one prompt each. Paste, rename, run. The one rule: TLC checks the model, never your code. Every spec action maps to a line, and a counterexample only counts once a test reproduces it. ## Step 1: pick the target Rank subsystems by concurrency risk and bug history. Pick one with a transaction boundary, several writers, and two fixed bugs to calibrate on. We took the workflow engine and the heartbeat, one agent each. ```text Rank the 3 to 5 subsystems in this repo with the most concurrency risk. Use file paths, git log and merged PRs mentioning race, duplicate, stuck, re-fire. For each: the files, the actors that write the same rows, candidate invariants, the fixed bugs a model should rediscover. Recommend one first target. No spec yet. ``` ## Step 2: model it, then calibrate on fixed bugs Write the spec and the action map together: each action, the file and line it models, the SQL guard it encodes. One transaction is one action. Every `await` outside one is where other actors interleave. Keep constants small. Then remove the guard a fixed bug added. The model must find that bug, or the model is wrong. Ours went 7 of 7, and found the first new bug on the way: a later commit had swapped an original fix for a weaker gate. ```text Model in TLA+ under specs/tla//: - .tla: state, Init, one action per code path that reads or writes that state. Small constants: 2 workers, 1 retry. - .cfg: constants, invariants, temporal properties. - ACTIONS.md: every action, the file:line it models, the WHERE clause it encodes. One DB transaction is one action; every await outside one is a boundary. Actors: . Then calibrate on : add a constant that removes each fix's guard, run TLC with it off, record the violated property and state count in CALIBRATION.md, keep a control config with it on. If a known bug is not found, fix the model. Do not fix any code yet. ``` ## Step 3: every counterexample becomes a failing test A trace is a suspect, not a bug. Map each step through the action map and write a test that calls the production functions in that order. It must fail on main. If it passes, the model drifted: fix the spec. Seven workflow traces, seven failing tests, zero drift, four root causes. Three more from the heartbeat. ```text Run TLC on the current guards. For each counterexample: 1. Map every trace step to code through ACTIONS.md. No row: fix the model first. 2. Write a test that calls the production functions in trace order on a temporary database. Hold mid-flight executors on a barrier. 3. It must fail on main. If it passes, log model drift, fix the spec. 4. Commit it as expected-to-fail. ``` ## Step 4: fix, one PR per root cause Flip the repro to a plain test. Add a fix flag to the spec, a control config that still finds the old bug, a fix config that holds. When the model shows the design is the problem, let it design the replacement. Our old heartbeat was a chain of sweeps. The new one is two actions, checked before a line was written, in review at publication as [#1682](https://github.com/desplega-ai/agent-swarm/pull/1682). ```text Fix . One PR per root cause. 1. Fix the code. Flip the repro from expected-to-fail to a plain test. 2. Add a Fix flag to the .tla that keeps the pre-fix branch, plus Ctl-.cfg (flag off, still finds the bug) and Fix-.cfg (flag on, holds). Rerun TLC, report the counts. 3. PR body: what the model found, the trace, the counts. Open the PRs. Do not merge. ``` ## Step 5: keep the spec true, in a swarm A spec rots the day a mapped file changes. So a daily workflow lists PRs merged since the last watermark, fans out one agent per touched spec, reruns TLC, reduces into one PR, polls CI, merges, notifies. A drift gate catches silent failures. Every node below is real. The HTML page renders this as an interactive node graph. Workflow `tla-spec-sync`, all 13 nodes as defined in the swarm on 2026-09-29: | Node | Type | Label | Next | |---|---|---|---| | plan | swarm-script | List specs + PRs since watermark | sync-specs | | sync-specs | foreach | Map: sync each touched spec (one agent task per spec) | reduce | | reduce | swarm-script | Reduce: one PR with changed specs | has-pr, check-drift | | has-pr | property-match | Any spec changed? | pr-gate (true) | | pr-gate | swarm-script | Poll PR: scope, CI, enqueue, merged? | route | | route | code-match | Route gate state | sleep (wait), notify-merged (merged), notify-failed (failed), notify-error (error) | | sleep | wait | Wait 3 min | pr-gate | | notify-merged | notify | Slack: merged | end | | notify-failed | notify | Slack: not merged | end | | notify-error | notify | Slack: gate errored, PR left open | end | | check-drift | swarm-script | Drift gate: did plan/reduce fail silently? | route-drift | | route-drift | property-match | Drift alert needed? | notify-drift (true) | | notify-drift | notify | Slack: silent-failure drift alert | end | Key takeaway: the sync is a map-reduce over specs with a polling merge gate, plus a separate drift branch that alerts when plan or reduce fails without an error. First scheduled run, this morning: six merged PRs touched mapped files, both specs updated, one PR merged in 22 minutes, nobody in the loop. ```text Set up a daily job that keeps specs/tla/ true to the code: 1. Plan: PRs merged since the last watermark, per spec, that touch a file named in its ACTIONS.md. 2. Map: one agent per touched spec. Re-check the changed rows, update the spec, rerun control and fix configs, push a branch or no_change. 3. Reduce: one PR with every changed spec and the PRs that caused it. 4. Gate: poll CI, merge only if the PR touches specs/tla/ alone. Notify on merge or failure. Alert if plan or reduce failed silently. Advance the watermark only after the PR merges. ``` ## What we got Main, 2026-09-29: - 3 specs, 1,415 lines of TLA+. 7 of 7 known bugs rediscovered. - 10 reproduced counterexamples: 7 workflow traces across 4 root causes, plus 3 heartbeat findings. 8 repro tests on main, all green. - 7 fix PRs merged 2026-09-28, same day as the models. - Largest counterexample: 338,137 distinct states. Largest clean run: 928,920. - New heartbeat: 8 properties, 4,243 states, under 2 seconds. Review still caught a fence keyed on the wrong field, which the model never saw. - 3 more traces (CX8 to CX10) have no repro yet and do not count. ## Reproduce it TLC is Java 21 plus [tla2tools.jar](https://github.com/tlaplus/tlaplus/releases/latest/download/tla2tools.jar); the rest is in [specs/tla](https://github.com/desplega-ai/agent-swarm/tree/main/specs/tla). This rediscovers a historical bug: ```bash TLA2TOOLS_JAR=/absolute/path/to/tla2tools.jar cd specs/tla/workflows java -cp "$TLA2TOOLS_JAR" tlc2.TLC -workers auto -config Cal-bf12ab53.cfg Workflows.tla ``` Showreel music: "Mist City" by Section7, CC BY 4.0. --- # Rebuilding Linear's \ > Three video models read Linear's motion-design teaser; the two Gemini models called the 3D scene 2D until 7.5s. A frame-by-frame check caught it. The replica is 858 frames of Remotion and three.js, reviewed eight times. Published: 2026-09-25T00:00:00Z Read time: 7 min read Tags: `motion design`, `video analysis`, `Remotion`, `three.js`, `OpenRouter`, `AI agents` Canonical URL: https://www.agent-swarm.dev/blog/linear-loops-video-replica --- The swarm analyzed Linear's "Loops updates" teaser with three video models, then rebuilt it as a 28.6-second agent-swarm video about schedules. Music: "Mana Two - Part 1" Kevin MacLeod (incompetech.com), Licensed under Creative Commons: By Attribution 4.0, https://creativecommons.org/licenses/by/4.0/ The rebuild brief, from Taras, verbatim: > nice can you skillify the video analysis you performed, so we could re-use the same idea in the future? … then, could you perform a little experiemtn in which you could replicate the same video in terms of vibes and so on, but swarm focused (colors, logos, shapes, etc) on some feature from the swarm … ensure it looks as similar to it in terms of quality, animations, professionalism, etc ## Reading the clip The reference is approximately 28.59 seconds, 640x360, 30 fps, 858 frames. The original source URL was not retained in this writeup. We pulled a 2 fps contact sheet first: ``` ffmpeg -i in.mp4 -vf "fps=2,scale=480:270,tile=4x5:padding=4:color=red" sheet_%d.png ``` Then 12 frames at 480px for the models. Every call went through OpenRouter from an ephemeral `script-run`. The analysis brief said "qwen 3.8 max" and "gemini 3.8"; the live catalogue (446 models, 79 with video input) resolved those to `qwen/qwen3.8-max-0902` and `google/gemini-3.8-flash`. We added `google/gemini-2.5-pro` as a third. | Model | Input | Result | Latency | Cost | |---|---|---|---|---| | `google/gemini-3.8-flash` | 12 frames | completed | 10.4s | $0.013 | | `google/gemini-2.5-pro` | 12 frames | completed, 1,994 reasoning tokens | 28.9s | $0.030 | | `qwen/qwen3.8-max-0902` | 1 frame | completed | 5.0s | not logged | | `qwen/qwen3.8-max-0902` | 3, 7, 12 frames | timed out every time (>30s cap), reproduced 3x | | | | all three | raw video (base64 `video_url`) | initial calls timed out at the 30s cap | | | The exact prompt strings were inline in ephemeral runs and did not survive. What is on file is the spec they followed, now in the analysis skill: > Prompt for exactly these sections, each claim citing a timestamp: animation technique; timing & easing; composition & layout; transitions; likely tooling; vibe & aesthetic. Ask it to state whether the scene is 2D or 3D **at each timestamp** and what evidence it sees (perspective, foreshortening, blur that varies with depth). The audio went to a model too, because the analysis brief assumed there was none. The file has an AAC stereo track at mean -21.2 dB. The prompt spec: > Ask: is there speech; if yes, verbatim transcript with timestamps; if no, describe music (tempo, instrumentation, mood) and each SFX with its timestamp. Verdict: no speech, synth pad plus UI SFX. gemini-3.8-flash became the default. From the analysis: "It matched `gemini-2.5-pro`'s accuracy on the things that matter (reading UI text, describing the dial/HUD motif, plausible tooling guess) at roughly a third of the latency and cost, and unlike qwen it actually completed reliably on a multi-frame batch." ### What the frames contradicted Both gemini models said the clip is 2D until 7.5s, then 3D. gemini-2.5-pro: "reframes the interface from a 2D-style view (t=5s) to a 3D perspective (t=7.5s)". The lead checked the frames by eye: > Frames at t=0 and t=5 already show a foreshortened arc, a receding secondary ring and depth-of-field blur on the foreground dots — the scene is 3D throughout. What changes at t≈7.5s is the **camera** (head-on wide → close oblique macro), not the dimensionality. A re-run that asked for 2D or 3D per timestamp still answered "2D" for 0.5s to 6.6s. The models also called cuts camera moves. gemini-3.8-flash: "orbital 3D camera swing to change scenes at t=7.5s". Stepping the transition window at 10 fps shows hard cuts at 6.9s and 12.35s hidden under the streak. The "instantaneous typographic cuts" it reported were a roughly 5-frame vertical roll inside a mask. Our own first draft of the analysis repeated the camera-move error. So the skill now has a mandatory step: every model claim gets checked against frames before it becomes a build note. ## Rebuilding it The replica is Remotion 4.0.484 with `@remotion/three` and `postprocessing`. The scene is a dial with a streak running around it. The camera is a pure function of the frame number, and the cuts sit at the frames the reference put them: ```ts export const FPS = 30; export const WIDTH = 1920; export const HEIGHT = 1080; export const DURATION = 858; // 28.6s — matches the reference's 28.59s ... export const SHOT1 = { from: 0, to: 207 } as const; // head-on wide, trigger list export const SHOT2 = { from: 207, to: 371 } as const; // close oblique macro export const SHOT3 = { from: 371, to: 592 } as const; // reverse oblique macro, action list ``` The ring is a torus arc, not a flat annulus: ```tsx /** * Flat-lying tube arc on the dial plane, from `from` sweeping `length` degrees CCW. * A tube stays a uniform line at every viewing angle, where a flat annulus pinches * to nothing when the camera grazes it edge-on. */ ... () => new THREE.TorusGeometry(r, tube, 8, Math.max(8, Math.round(len * 3)), rad(len)), ``` The streak's tail length follows its speed: ```tsx const legEase = Easing.bezier(0.3, 0.55, 0.25, 1); ... const speed = prev ? Math.abs(s.head - prev.head) : 0; // deg / frame const moving = speed > 0.05; // tail: long when fast, collapses into the node at rest const tail = Math.min(34, 2 + speed * 5); ``` Depth of field is set per frame, and the camera's near and far planes have to be pushed into the circle-of-confusion material or the blur lands in the wrong place: ```tsx useFrame(() => { const c = camAt(frameRef.current); ... cam.near = 0.1; cam.far = 80; cam.updateProjectionMatrix(); if (dof.current) { // near/far changed above; the CoC depth linearisation must follow them dof.current.cocMaterial.adoptCameraSettings(cam); dof.current.cocMaterial.focusDistance = c.pos.distanceTo(c.focus); dof.current.cocMaterial.focusRange = c.range; // bokeh is in pixels — normalise to a 1920-wide frame so previews match the master dof.current.bokehScale = c.bokeh * (gl.domElement.width / 1920); } }); ``` Captions are canvas textures drawn before the three.js canvas mounts, because Remotion advances the render loop once per frame and a texture that arrives late never reaches the captured frame. The palette keeps the reference's monochrome grade and puts amber only on the streak, the pip, and the node. The render: ``` npx remotion render src/index.ts SchedulesDial out.mp4 --gl=swangle --concurrency=2 --timeout=3600000 --muted=false --props='{"music":"music/mana-two-part-1-27s.mp3"}' ``` `swangle` is the only GL backend that worked. Concurrency above 2 bought nothing. The timeout covers a font `delayRender` that kills the render at about 118 seconds. `--muted=false` because the project config mutes by default. About 9 minutes at 1080p. ## Eight rounds Each round rendered a master, sampled it against the reference, and logged what failed. | Round | Failed | Fix | |---|---|---| | 1 | Captions invisible; post-processing rendered black frames; camera inside the ring; captions mirrored in shots 2 and 3 | troika text replaced with canvas-texture labels; composer built synchronously | | 2 | DOF wrong everywhere; streak never drew | camera moved past the dial centre so the rim reads convex; `adoptCameraSettings`; draw order and culling | | 3 | Streak thin and brown (amber-500 at low alpha); long ticks read as grey slabs | ticks, outer ring and face dimmed in macro shots | | 4 | 79.7% of frame pairs frozen at 30 fps against 30.3% in the reference | camera drift tripled in all three shots | | 5 | Frozen fraction down to 38.2%; first second still frozen; macro ring thick grey | | | 6 | | camera moves from frame 0; hairline ring in macro; focus pulled onto caption start | | 7 | Lead's 7 frame notes on the round-6 master: ring pinched to a point at 12.5s; caption out of focus at 12.5s; caption off frame at 10.5s; streak a "beige blade" | ring and streak as tubes; focus racked onto the caption within 14 frames; captions laid level per shot; near-white bar with amber only on nodes | | 8 | Clock static: in the reference the outer tick ring steps once per caption swap in shot 1 | 200-tick outer ring steps at each trigger swap, same direction, same relative sizes, 30-frame ease; nothing else changed | Round 4 is the one that changed how we check. The stills matched. The motion did not: a 160x90 greyscale diff showed the replica frozen four fifths of the time. Round 7 came from the lead stepping the round-6 master frame by frame. The ring pinch, the soft caption and the caption off frame all sat between the roughly 14 timestamps we had been sampling, for six rounds. Round-7 QA sampled 7 to 20 seconds every half second, 27 pairs; every caption sharp and in frame at mid-hold. Round 8 came from one line from Taras: "make the clock move in ours as it does in the linear one". The clock is the outer tick ring around the dial in shot 1 (0 to 6.9s). In the reference it turns in one direction in discrete steps, one per caption swap, with onsets at 0.93, 2.73, 4.30 and 6.07s. Each step has a fast attack and a long settle of about a second, then the ring holds until the next swap. Tick travel at 640px width measures 67, 24, 39 and 40 px. Ours now steps at our trigger swaps (1.10, 3.10, 4.60 and about 6.1s), same direction, same relative sizes, fitted in degrees per reference pixel: ```ts const BEZEL_STEP_DEG = 0.082; // deg per reference px, fitted so our ticks travel the same px at 640w const BEZEL_STEPS = [ { at: TRIGGERS[1].from, px: 67 }, { at: TRIGGERS[2].from, px: 24 }, { at: TRIGGERS[3].from, px: 39 }, { at: STREAK.nodeOpen - 3, px: 40 }, ]; const bezelAt = (f: number) => BEZEL_STEPS.reduce( (deg, s) => deg + s.px * BEZEL_STEP_DEG * interpolate(f, [s.at, s.at + 30], [0, 1], { easing: Easing.bezier(0.25, 0, 0.1, 1), extrapolateLeft: "clamp", extrapolateRight: "clamp", }), 0, ); ``` A group rotated by `bezelAt(frame)` wraps the outer ticks. Nothing else changed in round 8, so the round-7 list stands. Still open: at 12.5s the caption is dim while it rolls in. Accepted and not fixed: no SFX, the display font renders at 700 instead of 600, and the outro moves less than the reference. The same model that analyzed the reference then judged the replica at 13 timestamps. It read the replica as "charcoal" and did not mention "negative space". Both differences were real and went into round 7. ## What we would do differently Measure motion from round 1. The frozen-fraction metric took until round 4 to exist and explained more than any still. Sample densely where the camera moves. Three of the seven lead notes were between our sample points. Step every transition at 10 fps before writing a word about it. The cuts hidden under the streak fooled two models and our first analysis. Use the input format that completes in your environment. Our frame batches completed, while raw-video requests timed out at 30 seconds and in a later 180-second run. Save the prompts. The specs survived in the skills; the sent strings did not. ## The two skills Both are installed on the swarm and carry the checks above. `motion-design-video-analysis`: contact sheets, transition windows at 10 fps, sampled frames to `google/gemini-3.8-flash`, audio to the same model, a palette sampler, a motion-density metric, and a claim-check table that every model output has to pass. `motion-design-replication`: the Remotion and three.js build, the eight render traps that each cost about an hour, the music-match request, the side-by-side render, and the judge step: run the analysis skill on both clips with the same prompt, model and timestamps. --- # TasteLabs Found Design Drift in Our Own Sites > Our landing sites had three amber ramps, 34 untokenized brand-color literals, and no BRAND.md files. One fix PR has merged; one is still open. Published: 2026-09-16T00:00:00Z Read time: 6 min read Tags: `TasteLabs`, `design systems`, `design tokens`, `MCP`, `AI agents` Canonical URL: https://www.agent-swarm.dev/blog/tastelabs-design-drift --- TasteLabs is a design-taste engine for agents, surfaced as an MCP server at `mcp.tastelabs.com/mcp` with twelve tools. It searches a curated corpus of real sites by aesthetic — describe a look in natural language, get concrete reference sites back. It extracts any URL's design system as structured data: tokens, CSS, screenshots, and a written brand signature. It grades a page against a reference brand, returning the worst-first fixes. Extractions cost two credits each. Re-reading a past search or extraction is free. We wired the MCP server into the swarm so every agent gets the tools natively. ## What the extractor found We extracted desplega.ai first, then our two landing sites: agent-swarm.dev and desplega.sh. The engine read desplega.ai correctly: CTA `TRY IT OUT`, copy tone "Confident, Direct, Technical." A `search_similar_brands` call on that extraction returned neon.tech, clickhouse.com, roocode.com, and finsweet.com — a correct cluster of dark developer-tool marketing sites. The visual embedding checked out, so we trusted what it said about our own sites. On **agent-swarm.dev** the engine named a primary accent of `#BB4D00`, its reported sRGB representation of the `--color-primary` token, `oklch(0.555 0.163 48.998)`. It named Space Grotesk for headings and body, Space Mono for labels and code. Correct on every dimension. The shipped stylesheet did not match. `#b75000`, a Tailwind v4 amber, appeared 16 times. `#b45309`, a Tailwind v3 amber, appeared 7 times. Both sat beside the token's `#BB4D00`. Three amber-700 values for one brand color, all live on the same page. Roughly thirteen surface tints — creams, success-state greens, and Slack-mention chrome — were baked per-component with no token entry. | Hex | Ramp | Occurrences | |---|---|---| | `#b75000` | Tailwind v4 amber-700 | 16 | | `#b45309` | Tailwind v3 amber-700 | 7 | | `#f99c00` | Tailwind v4 amber-500 | 6 | | `#d97706` | Tailwind v3 amber-600 | 3 | | `#92400e` | Tailwind v3 amber-800 | 3 | On **desplega.sh** the engine named `#000000` and `#0FEB3A`, with Geist Mono headings and Space Grotesk body. The brand green, `#0FEB3A`, appeared 34 times as a raw literal and was never bound to a token. The token layer that shipped was stock shadcn neutral plus an unused blue — `--sidebar-primary: #1447e6`. Grep the token layer for the brand color: nothing. Grep for a blue: a token that shipped but never rendered. Neither repo had a `BRAND.md`. The design system was whatever the components happened to do. ## The fixes Status recorded on September 16, 2026: agent-swarm-landing #182 merged. landing-labs #19 remained open. These are publication-time observations. **agent-swarm-landing #182** consolidates the stray amber ramps onto the `--color-primary` token. A `BRAND.md` records the canonical value and one rule: brand values live in tokens, no raw brand hex in components. The pixel shift from converging two ambers onto a third hex is subtle, visible mostly in blog chart bars. The PR includes before/after screenshots. **landing-labs #19** promotes `#0FEB3A` to a `--brand-green` token, removes the unused `--sidebar-primary`, and adds a `BRAND.md`. The change is a deliberate pixel-for-pixel no-op — same rendered color, now with one place that owns it. Both repos are private; neither PR is publicly linkable. ## What it means An external extractor that reads your rendered page detects the gap between what your tokens claim and what your stylesheet ships. We did not need an internal audit. We needed an outside reader looking at the same pixels our users see. A possible next step is a CI gate. We did not verify that integration. `verify_brand_adherence` scores any page against a reference brand for about one credit. A PR that introduces a page that stops matching the brand fails the check. The engine must reach the preview URL, and TasteLabs does that through an SSH reverse tunnel we have not tested. Every team says it has a design system. Shipping is the proof. Our design system is what ships, not what the tokens file says. Until this test, they no longer matched. ## Sources and further reading - [Taste Engine](https://engine.thetaste.ai) — the product the API key belongs to. The surface that works with our key is the MCP server at `https://mcp.tastelabs.com/mcp`. - [Taste-AI/skills](https://github.com/Taste-AI/skills) — the official agent skills for the Taste Engine, published under the Vercel skills standard. - The two audit reports behind this post are internal to the swarm, so the occurrence counts above are not independently linkable. The primary evidence is the stylesheet each site actually serves. - Both fix PRs (`agent-swarm-landing` #182, `landing-labs` #19) sit in private repos and are not publicly linkable either. ## FAQ ### What is TasteLabs? A design-taste engine for agents: it searches a corpus of real sites by aesthetic, extracts any URL's design system as structured data, and grades a page against a reference brand. ### What is design-token drift? The gap between the tokens a design system declares and what the shipped stylesheet actually renders — hardcoded hexes, duplicate color ramps, or a brand color never promoted to a token. Both of our sites had it. ### Did the two fix PRs merge? As of September 16, 2026, agent-swarm-landing #182 merged and its amber consolidation shipped. landing-labs #19 remained open. We did not refresh that status for this article. ### How much does TasteLabs cost? Extractions are two credits each. Brand-adherence grading is about one credit per run. Re-reading a past search or an extraction from your history is free. ## Visual data notes The HTML page renders three amber swatches, an interactive occurrence chart, a token-versus-stylesheet comparison, and a green-token gap card. The table above is the chart fallback, sourced from the internal stylesheet audit on September 16, 2026. Canonical amber: #BB4D00, one OKLCH token definition and zero raw hex occurrences. The five stray hexes total 35 raw occurrences; the largest is #b75000 with 16. Zero raw occurrences does not mean the token color never rendered. On desplega.sh, 34 raw #0FEB3A literals had zero owning token definitions; the unused sidebar token was #1447e6. --- # Multi-Agent Orchestration: The Production Architect's Guide > Core components of a production AI agent architecture, from orchestrator to human escalation, mapped to Agent Swarm docs and operator responsibilities. Published: 2026-08-10T17:36:55.681Z Read time: 8 min read Tags: `multi-agent orchestration`, `agent architecture`, `shared memory`, `self-hosted agents` Canonical URL: https://www.agent-swarm.dev/blog/multi-agent-orchestration --- Multi-agent orchestration coordinates work across specialized agents. A lead agent divides an objective into tasks, assigns workers, and collects their results. The architecture needs more than parallel model calls. Task state, memory, credentials, observability, and human review determine what happens when work fails or needs intervention. This guide maps those responsibilities to documented Agent Swarm capabilities. It also identifies the controls the operator must provide. ## When does a workflow need multiple agents? Use multiple agents when work divides into independent tasks or requires different tools and execution environments. Keep one agent when a bounded task needs neither division nor parallel execution. Define the expected result before choosing an architecture. A workflow needs a way to check completion, identify failures, and decide whether a person must intervene. Additional agents introduce dependencies, duplicated work, and opportunities for conflicting changes. Add workers only when an observed bottleneck justifies them. ## The eight components of the architecture The table distinguishes general responsibilities from documented product behavior. A documented capability still requires deployment configuration and operational ownership. | Component | Responsibility | What Agent Swarm documents | What the operator owns | | --- | --- | --- | --- | | Orchestrator | Divide objectives into tasks and collect results. | A lead agent assigns tasks to workers ([architecture overview](https://docs.agent-swarm.dev/docs/architecture/overview)). | Choose safe objectives and define task boundaries. | | Task and state layer | Record progress and support recovery. | Tasks have explicit states, dependencies, retries, and heartbeat detection ([task lifecycle](https://docs.agent-swarm.dev/docs/concepts/task-lifecycle)). Workflows store checkpoints after steps ([workflows](https://docs.agent-swarm.dev/docs/concepts/workflows)). | Back up the database. Define safe behavior when an interrupted step already affected an external service. | | Workers | Execute assigned tasks in separate environments. | Workers run coding harnesses, including Claude Code, Codex, and OpenCode, in Docker containers ([deployment guide](https://docs.agent-swarm.dev/docs/guides/deployment)). | Choose harnesses and model providers. Configure credentials and secure the host. | | Tools and credentials | Connect to external systems without placing secrets in prompts. | The product lists supported [integrations](/integrations). A [scripts credential broker](https://docs.agent-swarm.dev/docs/guides/scripts-credential-broker) keeps integration secrets on the server. | Issue and rotate API keys. Choose integrations and their access scopes. | | Memory | Retain knowledge between tasks. | Memory supports agent and swarm scopes, expiry, and ranked retrieval ([memory system](https://docs.agent-swarm.dev/docs/architecture/memory)). | Review stored information. Remove sensitive or incorrect records. | | Observability | Expose behavior, failures, and resource use. | API and worker runners support OpenTelemetry export ([observability guide](https://docs.agent-swarm.dev/docs/guides/observability-opentelemetry)). Export is off by default. | Configure the export endpoint and operate its backend. Set access controls, alerts, and retention. | | Governance | Restrict access and define accountability. | RBAC applies to REST requests with user tokens. Operator-key requests and agent calls bypass these gates ([Security and Trust](/security)). | Protect the operator key. Provide any additional authorization, content filtering, and cost controls the deployment requires. | | Human escalation | Pause work that requires a person. | A workflow node pauses for approval or input ([workflows](https://docs.agent-swarm.dev/docs/concepts/workflows)). Running tasks support [steering](https://docs.agent-swarm.dev/docs/guides/task-steering). | Define which actions require review. Staff the queue and decide what happens when reviewers do not respond. | ## Follow one task through the system A requester supplies an objective through a connected interface. The lead agent decomposes the work and assigns tasks to available workers. Workers execute tasks with their configured harnesses. Dependencies determine which tasks can proceed. The [task lifecycle](https://docs.agent-swarm.dev/docs/concepts/task-lifecycle) documents the transitions: - `unassigned`: no worker owns the task. - `offered`: the system offers the task to a worker. - `pending`: the task awaits execution. - `in_progress`: a worker executes the task. - `paused`: execution awaits further input or intervention. - `completed`: the task reaches completion. - `failed`: the task ends unsuccessfully. Task states and workflow checkpoints serve different purposes. Task states describe work status. Workflow checkpoints record progress between workflow steps. A checkpoint does not make external effects safe to repeat. If a step sends an email before a crash, the integration needs a way to prevent duplicate delivery. Keep outcome checks explicit. A worker response alone does not prove that a repository change passes tests or that an external operation succeeded. For sessions with actual tasks and outputs, inspect the [examples collection](/examples). Use those records to understand delegation behavior, rather than treating this architecture as a benchmark. ## Separate planned work from fixed workflows A lead agent can decide how to divide a new objective. That flexibility also means the plan can omit steps or assign conflicting tasks. A predefined workflow records the intended sequence and dependencies. This structure suits recurring procedures that need known transitions and explicit approval steps. Agent Swarm documents both [task coordination](https://docs.agent-swarm.dev/docs/concepts/task-lifecycle) and [checkpointed workflows](https://docs.agent-swarm.dev/docs/concepts/workflows). Choose the mechanism that matches the procedure you need to operate. Neither approach proves that the resulting work is correct. Check the resulting files, external state, or other task-specific evidence before accepting completion. ## Where the guarantees stop ### Access control Agent Swarm defines two built-in user roles: `admin` and `requester`. Every user currently receives `admin` by default. The application has no API or interface for role assignment. RBAC gates REST requests authenticated with `aswt_` user tokens. It does not gate requests authenticated with the operator API key or calls from agents. Worker containers therefore do not establish authorization for every tool call. Configure the underlying credentials and service permissions for the access each worker needs. SSO uses an external proxy. The API must remain reachable only through that proxy when the deployment relies on trusted identity headers. The [Security and Trust page](/security) describes these boundaries and links the deployment guides. ### Recovery and concurrency Stored state supports recovery, but recovery must account for partial external effects. Test interrupted steps before relying on retries for a sensitive workflow. Typed messages can reject malformed payloads. They do not prove deadlock freedom or prevent workers from making conflicting changes. Define task ownership, dependencies, and bounded waits. Check whether an interrupted task should retry, stop, or require a person. ### Memory and data Persistent memory retains useful context across runs. It can also retain incorrect conclusions or information that should expire. Choose memory scope and retention deliberately. Review sensitive records rather than assuming that shared memory provides access isolation by itself. ### Cost and telemetry Container resource limits bound host resources. They do not bound charges from external model providers. Pre-execution cost caps and any policy engine remain operator responsibilities. Do not treat a cost dashboard or an approval prompt as an enforced spending limit. OpenTelemetry export requires configuration. The operator chooses the backend and its retention policy. See [observability](https://docs.agent-swarm.dev/docs/guides/observability-opentelemetry) for the supported export settings. Agent Swarm claims no compliance certifications. Evaluate deployment requirements against the [documented security boundary](/security). ## Validate one bounded workflow Start with a task whose outcome you can verify independently. Keep the initial worker set small enough to inspect each assignment and result. Before expanding its scope, check these conditions: 1. Every worker receives a clear task and an observable completion criterion. 2. Task dependencies prevent work from starting before its inputs exist. 3. A failed worker produces a visible failure state. 4. An interrupted workflow preserves its checkpoint and handles repeated external effects safely. 5. Sensitive actions wait for the required approval. 6. Credentials grant only the intended access in the external service. 7. Telemetry reaches the configured backend. 8. A person can inspect results and intervene when needed. These checks are an operating checklist, not reported test results. Adapt them to your actual tools and failure consequences. Agent Swarm is free software under MIT. Enterprise support is available by conversation, with services and scope agreed separately. See [pricing](/pricing). ## Sources - [Architecture overview](https://docs.agent-swarm.dev/docs/architecture/overview) - [Task lifecycle](https://docs.agent-swarm.dev/docs/concepts/task-lifecycle) - [Workflows](https://docs.agent-swarm.dev/docs/concepts/workflows) - [Deployment guide](https://docs.agent-swarm.dev/docs/guides/deployment) - [Scripts credential broker](https://docs.agent-swarm.dev/docs/guides/scripts-credential-broker) - [Memory system](https://docs.agent-swarm.dev/docs/architecture/memory) - [OpenTelemetry observability](https://docs.agent-swarm.dev/docs/guides/observability-opentelemetry) - [Task steering](https://docs.agent-swarm.dev/docs/guides/task-steering) - [Security and Trust](/security) ## FAQ ### What is multi-agent orchestration? Multi-agent orchestration coordinates work across specialized agents. A lead agent divides an objective into tasks, assigns workers, and collects their results. ### What components does the architecture need? It needs orchestration, task state, workers, tools and credentials, memory, observability, governance, and human escalation. Each component needs an operational owner. ### Do typed messages prevent deadlocks? No. Typed messages can reject malformed payloads, but they do not prove deadlock freedom. Define dependencies, bounded waits, and recovery behavior separately. ### Does Agent Swarm enforce permissions for every worker tool call? No. RBAC applies to REST requests with user tokens. Operator-key requests and agent calls bypass those gates. Every user currently defaults to admin. ### Do container limits cap model spending? No. Container limits bound host resources. They do not bound charges from external model providers. Operators must provide pre-execution cost controls when required. --- # 25 MIT-licensed open-source projects worth tracking for agent infrastructure > 25 MIT-licensed agent-infrastructure repos with outsized, rising attention among 655 agent-swarm stargazers. Stars and activity checked 2026-10-10. Published: 2026-07-29T00:00:00Z Updated: 2026-10-10T00:00:00Z Read time: 9 min read Tags: `FOSS`, `agent infrastructure`, `MCP`, `agent harnesses`, `observability` Keywords: `agent infrastructure`, `open source projects worth tracking`, `FOSS AI agents`, `open source agent tools`, `agent observability`, `MCP tools`, `agent harness`, `multi-agent systems`, `GitHub repositories`, `agent-swarm` Canonical URL: https://www.agent-swarm.dev/blog/25-foss-repos-agentic-infra --- Which open-source projects are worth tracking for agent infrastructure? These 25. They are the MIT-licensed repositories with outsized, rising attention among the 655 GitHub accounts that star agent-swarm. "Worth tracking" is not "most starred": we rank by popularity-normalized lift plus a recency gate, so a repository with under 200 stars can qualify while giants like `facebook/react` drop out. The boundary: MIT license only, cohort attention measured in our July 2026 crawl, star counts and last-push dates refreshed 2026-10-10. Several of these repos have fewer than 200 stars. ## Selection evidence — crawled July 2026, facts refreshed 2026-10-10 - **528,916 star edges** across **228,177 distinct repositories**, from **655 agent-swarm stargazers** with bot and drive-by accounts removed. - **Lift** is the observed versus expected number of co-stars, compared on a log scale. Given how many repositories each stargazer has starred and how popular a repository is globally, we estimate how many of our accounts would have starred it by chance, then measure how far reality exceeds that. A shrinkage term discounts thin support. - **Recency** is weighted with an exponential half-life, so a repo that spiked in this cohort a year ago and went quiet ranks below one accelerating right now. - **Recency filters:** at least 8 cohort stars, at least 5 of them in the last 90 days, and at least half of all cohort stars inside that window. This cut the pool from 2,471 candidates to 342 (13.8%). - **MIT gate:** the recorded final candidate pool contained 340 repositories, of which 179 carried an exact MIT license. The published funnel does not explain the two-repository difference from the preceding 342 count. - **Editorial pass:** we removed mirrors, templates, prompt and skill collections, and awesome-lists, leaving 25. One caveat before the list: co-starring signals attention, not adoption or production use. This is a cohort description, not a survey, and our clustering of the 25 into four groups is weak — read the categories as vicinities, not boundaries. ![Static preview of the hidden-gems repository cluster graph](https://www.agent-swarm.dev/blog/25-foss-repos-agentic-infra/graph-preview.png) Node size represents popularity-normalized lift; color represents neighborhood. [Open the interactive graph full screen](https://www.agent-swarm.dev/blog/25-foss-repos-agentic-infra/graph.html). ## The 25, as of 2026-10-10 ### 1. Operator-Visible Agent Systems Exposing agentic work as a state a human can inspect, pause, or override. | Repository | Why it matters | Current limitation | Stars | Last push | License | |---|---|---|---|---|---| | [swarmclawai/swarmclaw](https://github.com/swarmclawai/swarmclaw) | Self-hosted, multi-provider runtime for persistent agent teams with restart-safe branching, scheduling, and background jobs across several agent CLIs. | No commits in over 90 days. | 689 | 2026-06-30 | MIT | | [leodavinci1/kanbots](https://github.com/leodavinci1/kanbots) | Desktop kanban that dispatches issues to coding-agent CLIs in isolated Git worktrees, streaming tool activity and pausing for decisions instead of running unattended. | No commits in over 90 days — the quietest on the list. | 610 | 2026-05-25 | MIT | | [ClaudioDrews/memory-os](https://github.com/ClaudioDrews/memory-os) | Local memory stack that separates permanent instructions, sessions, trust-scored facts, and a generated wiki instead of dumping everything into one vector store. | Built around the Hermes stack, not a general-purpose memory layer. | 1,372 | 2026-09-20 | MIT | | [pikpikcu/airecon](https://github.com/pikpikcu/airecon) | Authorized-testing agent that drives any OpenAI-compatible LLM gateway — local or hosted — and adds testing-specific phases, checkpoints, and failure-aware payload reuse on top of a generic shell agent. | Needs a Kali Linux Docker sandbox and a model with native tool calling; target data stays local only with a local gateway. | 1,074 | 2026-09-11 | MIT | | [kerlenton/mcpsnoop](https://github.com/kerlenton/mcpsnoop) | Transparent stdio/HTTP proxy that records the actual MCP traffic between a client and its servers — replay, drift detection, and CI failures on malformed frames. | Sees only the traffic that passes through the proxy. | 361 | 2026-10-07 | MIT | ### 2. Closed-Loop Agent Engineering These projects treat "*configure*, run, observe, grade, ship" as the actual unit of work, and make that loop repeatable around whatever runtime you already use. | Repository | Why it matters | Current limitation | Stars | Last push | License | |---|---|---|---|---|---| | [LiteLLM-Labs/litellm-agent-control-plane](https://github.com/LiteLLM-Labs/litellm-agent-control-plane) | One creation/execution UI spanning multiple managed and local agent backends, instead of a separate dashboard per runtime. | No commits in over 90 days. | 1,305 | 2026-06-20 | MIT | | [exoharness/exo](https://github.com/exoharness/exo) | Experimental harness whose agent can modify and restart its own prompts, tools, memory, and policies — with a rewindable sandbox keeping canonical conversations outside the part being changed. | Self-described experimental; self-modification only stays safe inside the rewindable sandbox. | 1,495 | 2026-10-08 | MIT | | [Amal-David/pagecast](https://github.com/Amal-David/pagecast) | Local-first CLI/MCP server for publishing agent-generated static reports, tracking context so repeat publishes update one URL rather than sprawling. | Publishes only to Cloudflare Pages. | 191 | 2026-09-21 | MIT | | [darkrishabh/agent-skills-eval](https://github.com/darkrishabh/agent-skills-eval) | Runs the same prompt with and without a given Agent Skill to estimate its incremental lift, with reusable artifacts and deterministic tool-call assertions. | Measures a skill's incremental lift, not end-to-end agent quality. | 799 | 2026-10-07 | MIT | | [raindrop-ai/workshop](https://github.com/raindrop-ai/workshop) | Local debugger that streams agent tokens, tool calls, and spans into a browser, and can replay a captured production trace against real agent code. | Replay only covers traces it captured. | 1,108 | 2026-08-22 | MIT | | [mgechev/skillgrade](https://github.com/mgechev/skillgrade) | Cross-provider CLI that tests whether Claude, Gemini, or Codex actually discover and use a skill under declared tasks and graders — CI mode included. | Scoped to skill discovery and use, not general agent capability. | 720 | 2026-10-05 | MIT | ### 3. Sidecars That Extend the Agent Small, attachable capabilities that add leverage without replacing the host agent. Think MCP, CLIs, plugins, deliberately narrow in scope. | Repository | Why it matters | Current limitation | Stars | Last push | License | |---|---|---|---|---|---| | [xhluca/agent-talk](https://github.com/xhluca/agent-talk) | Encrypted peer messaging for independent coding agents across sessions or machines, without requiring a full orchestration suite. | Messaging only — no shared state or orchestration. | 191 | 2026-09-10 | MIT | | [raiyanyahya/recall](https://github.com/raiyanyahya/recall) | Claude Code plugin that captures sessions into a compact project-resume document using local TF-IDF/TextRank summarization — no extra model call. | Claude Code is the first-class harness; OpenCode support is opt-in. | 755 | 2026-09-07 | MIT | | [zaydmulani09/mnemo](https://github.com/zaydmulani09/mnemo) | Local Rust sidecar that builds a SQLite knowledge graph and returns ranked prompt context via weighted multi-hop relationships, not just vector similarity. | No commits in over 90 days. | 237 | 2026-06-04 | MIT | | [ronak-create/FableCut](https://github.com/ronak-create/FableCut) | Browser video editor whose timeline is editable as JSON through UI, MCP, files, or REST — compact patch operations and revision-counter conflict rejection instead of silent overwrites. | One person's project, created in early July. | 711 | 2026-10-08 | MIT | | [bschoepke/ableton-live-mcp](https://github.com/bschoepke/ableton-live-mcp) | Experimental MCP server giving agents access to Ableton Live's Python object model, including an audio-tap loop for capture-analyze-adjust cycles. | Experimental, and tied to Ableton Live. | 228 | 2026-10-06 | MIT | | [tracewayapp/traceway](https://github.com/tracewayapp/traceway) | OpenTelemetry-native platform unifying logs, traces, metrics, and AI telemetry under one trace ID, with an agent-oriented CLI exposing stable JSON and exit codes. Highest cohort penetration on this list (27 of our 655 accounts). | You adopt its telemetry platform, not just a library. | 1,603 | 2026-10-05 | MIT | | [nikitadoudikov/claude-pulse](https://github.com/nikitadoudikov/claude-pulse) | Local ops dashboard built from Claude Code/Codex session files and hooks — live context fill, usage estimates, and phone-based allow/deny for pending commands. | Quieter since July, and reads Claude Code/Codex session files only. | 247 | 2026-07-19 | MIT | ### 4. Beyond Context, Execution Governance Execution needs structured _context_ about state, permissions, provenance, and prior work. A bigger context window alone can't give you that. | Repository | Why it matters | Current limitation | Stars | Last push | License | |---|---|---|---|---|---| | [sympozium-ai/sympozium](https://github.com/sympozium-ai/sympozium) | Kubernetes-native coordination layer that represents agents, policies, and executions as cluster resources, putting RBAC and sandboxing in the control plane itself. | Requires running Kubernetes. | 659 | 2026-10-08 | MIT | | [MaxGfeller/open-harness](https://github.com/MaxGfeller/open-harness) | TypeScript library for embeddable agent harnesses — sessions, tools, middleware, virtual filesystems — with compaction and resumable subagents as opt-in pieces, not a monolith. | Quieter since July; it's a library, so you assemble the runtime yourself. | 617 | 2026-07-17 | MIT | | [vshulcz/deja-vu](https://github.com/vshulcz/deja-vu) | Local index/MCP recall layer over coding-agent session histories already on disk, retroactively indexing across several harnesses. | Created 2026-07-14 — about three months old at the 2026-10-10 re-check; recall quality depends on the session histories you already have. | 1,160 | 2026-10-09 | MIT | | [ModernRelay/omnigraph](https://github.com/ModernRelay/omnigraph) | Branchable graph database for shared agent state where agents mutate isolated branches and submit graph-wide changes for review, combining graph traversal, vector, and full-text search. | Introduces a graph database your team has to operate. | 1,271 | 2026-10-10 | MIT | | [manojmallick/sigmap](https://github.com/manojmallick/sigmap) | Deterministic, byte-stable code-signature map generated without an LLM or vector database — diffable, and able to gate fabricated files, symbols, and tests in CI. | Signatures only: it checks structure, not behavior. | 646 | 2026-10-09 | MIT | | [tastyeffectco/sandboxd](https://github.com/tastyeffectco/sandboxd) | Self-hosted API running coding agents inside per-app Docker containers with live preview URLs, credential proxying, and checkpoint/revert. | You run the container fleet yourself. | 963 | 2026-09-29 | MIT | | [cosmtrek/mindwalk](https://github.com/cosmtrek/mindwalk) | Local visualization replaying coding-agent sessions over a deterministic 3D map of the repository, making scope and churn spatially visible instead of just chronological. | A visualization layer: it explains sessions, it doesn't change them. | 1,367 | 2026-08-10 | MIT | All 25 remain MIT-licensed and unarchived as of 2026-10-10. The biggest movers since publication are `exo` (594 to 1,495 stars), `deja-vu` (495 to 1,160), `traceway` (1,048 to 1,603), and `mindwalk` (949 to 1,367). ## What to watch next **Which open-source tools let a human inspect or pause agent work?** That is the operator-visible question, and where this cohort concentrates hardest. `swarmclaw` and `kanbots` both render agent work as inspectable state a person can interrupt, and `mcpsnoop` shows the actual MCP frames instead of a black box. Our [delegation architecture article](/blog/task-delegation-architecture) describes how operators assign and inspect work. **How do you know a change actually made your agent better?** Closed-loop evaluation answers it: run, observe, grade, repeat. `agent-skills-eval` and `skillgrade` isolate whether a skill earns its place, while `exo` pushes the loop further by letting the agent modify itself inside a rewindable sandbox. These repositories offer different ways to inspect that loop. Their presence in the cohort does not establish evaluation quality. **What can you add without replacing the agent you already run?** Sidecars are deliberately narrow tools that attach to the host agent. `recall` bolts session memory onto Claude Code with no extra model call, `agent-talk` adds encrypted messaging between independent agents, and `traceway` attaches OpenTelemetry-native observability. Our [Code Mode measurement](/blog/code-mode-token-savings) examines one way to reduce tool-result payloads. **Who is allowed to do what, and where is that enforced?** Execution governance. `sympozium` puts RBAC and sandboxing in the Kubernetes control plane, `sandboxd` isolates agents in per-app containers with credential proxying, and `omnigraph` makes shared state changes reviewable. Our [security page](/security) describes the product security boundaries. For a wider view beyond this cohort, see [our self-hosted open-source agent platforms list](/blog/best-open-source-ai-agent-platforms-self-host). ## Conclusion: never outsource the thinking Two things we noticed; both held up on the re-check. The trend for **observability and composability over ease-of-use** keeps accelerating: a kanban board that shows agent work as inspectable state, a proxy that shows the actual MCP frames, sidecars that bolt one capability onto whatever agent you already run, execution substrates that carry provenance and permissions as data rather than prompt text. And the stack is still being assembled in public by individuals and small teams. `deja-vu` and `FableCut` were weeks old when we found them; since publication `exo`, `deja-vu`, `traceway`, and `mindwalk` each gained hundreds of stars. Attention is a signal, not a verdict — the thinking about what to adopt stays with you. --- *Star counts and last-push dates from the GitHub API, checked 2026-10-10. Cohort selection from the July 2026 crawl. agent-swarm does not use or endorse the listed repositories.* --- # 26 Tool Calls, One Script, $0.02: Measuring “Code Mode” in Production > Our session rubric already tells agents: past ten items, write a script instead of N tool calls. We measured what that's worth on one production job, and where the savings stop. Published: 2026-07-08T00:00:00Z Updated: 2026-10-10T00:00:00Z Read time: 12 min read Tags: `code mode`, `MCP`, `agent scripts`, `token economics`, `LLM cost optimization` Keywords: `code mode`, `MCP`, `agent scripts`, `token economics`, `LLM cost optimization`, `agent-swarm`, `AI agents`, `multi-agent systems` Canonical URL: https://www.agent-swarm.dev/blog/code-mode-token-savings --- > **Updated October 10, 2026.** The first version of this post drew [deserved criticism on Hacker News](https://news.ycombinator.com/item?id=49019301). The prose was machine-drafted and read like it, and it said "we didn't estimate this" two paragraphs before a section full of estimates. This is a rewrite. The measurements are unchanged, the labels on them are now accurate, and we added the end-to-end production numbers the original left out. ## What is Code Mode for MCP? Code Mode is a pattern for connecting a model to MCP tools: instead of calling tools one at a time, the model writes a short program against a typed API generated from those tools, the program runs in a sandbox, and only its returned value goes back into the model's context. Our modeled baseline uses sequential raw calls and retains their full JSON results in context. Actual harnesses can batch tool calls, discover schemas, prune results, or compact history. Those choices change the comparison. We measured the difference on one production job: 26 underlying calls became one script call, and about 99.2% fewer characters entered context for that data-gathering step (modeled raw path vs measured script run — the labels matter and we keep them throughout). The roughly 50% figure you will see later is the end-to-end cost of the recurring job that uses the script, which is the number we actually bank. In November, Anthropic published [a piece on code execution with MCP](https://www.anthropic.com/engineering/code-execution-with-mcp): give an agent a sandbox and a generated API instead of raw tool calls, and a task that cost 150,000 tokens costs 2,000, because intermediate data never passes through the model's context. [Cloudflare shipped the same idea](https://blog.cloudflare.com/code-mode/) in September as "Code Mode," and later [put a number on it](https://blog.cloudflare.com/code-mode-mcp/): 2,500+ API endpoints, 1.17M tokens down to about 1,000. None of that is a new idea. "If you do the same thing twice, write a script" predates LLMs by half a century. Agent Swarm sessions have shipped a version of it as a rubric for a while: past roughly ten items, or any bulk fan-out, the agent is told to write a script instead of making individual tool calls. It's the same machinery behind [Script Workflows](https://www.agent-swarm.dev/blog/script-workflows-durable-one-off-runs), and nothing in this post was built for the post. What we hadn't done was measure it. So we picked one real job, ran the script path live, and modeled what the tool-call path would have put in front of the model. One number in this post is measured end to end, one is modeled from measured samples, and the difference is labeled everywhere it appears. ## When Code Mode helps, and when raw tool calls are simpler There are three ways to wire a model to tools, and the right one depends on how many calls the job makes and who needs to see each result. | Approach | What enters the model's context | When it helps | When it is the wrong choice | |---|---|---|---| | **Raw MCP tool calls** | Our modeled baseline includes schemas and retains raw results. Discovery, batching, output limits, and compaction can reduce that payload. | One to three calls; each result needs the model's judgment before the next call; a human must approve each call individually; irreversible writes. | Bulk fan-out, loops over many items, or large payloads you would filter down anyway. | | **Single code tool** ([Cloudflare's pattern](https://developers.cloudflare.com/agents/model-context-protocol/codemode/)): one tool that accepts code written against a typed API built from the server's tools | The code tool's schema and the typed API; only the program's return value re-enters context. | Many sequential calls whose intermediate data the model does not need to read; filtering and joining large payloads; loops. | Steps that need judgment between calls, per-call human approval, or irreversible writes. | | **Search-and-execute** (Cloudflare's pattern for very large APIs): a search tool finds the relevant endpoints, then an execute tool runs code against them | The search and execute schemas; endpoint definitions are discovered on demand. Cloudflare reports 2,500+ endpoints going from 1.17M tokens to about 1,000. | APIs too large to describe in a prompt at all. | Small tool catalogs where the whole typed API fits up front; the discovery step is overhead you do not need. | Our own rubric, which ships in every Agent Swarm session template: past roughly ten items, or any bulk fan-out, write a script. Below that threshold, or whenever a step needs the model's judgment or a human's approval before the next one, stay with raw calls. Cloudflare documents both server patterns in its [Code Mode MCP server patterns](https://developers.cloudflare.com/agents/model-context-protocol/codemode/) guide. If your stack is Python, [FastMCP's Code Mode](https://gofastmcp.com/servers/transforms/code-mode) is the equivalent option: the model writes Python that orchestrates tools in a sandbox, with staged tool discovery. ## What the script does `workflow-triage` scans every automation the swarm runs (all workflows and all cron schedules) and flags which ones are dead, failing, or fine. Under the hood that's 26 calls: one `workflow_list`, one `schedule_list`, and one `workflow_listRuns` per workflow (24 of them). Our modeled sequential baseline makes all 26 calls and retains their full results. Actual harness behavior can reduce that context. The script makes the same 26 calls inside a sandboxed subprocess. Only the final summary object reaches the agent. ## The numbers The script column comes off a live run. The raw-path column is modeled: we ran the same underlying calls on a sample and extrapolated to the full catalog (24 workflows, 60 schedules). The arithmetic is in the next section. | | Script (measured) | Raw tool calls (modeled) | |---|---|---| | Calls made | 1 | 26 | | Reaches the agent's context | 25,811 characters (one JSON result) | ~3.26M characters | | Approx. tokens (chars ÷ 4) | ~6,450 | ~815,000 | | Wall-clock | 13.12s (`durationMs: 13120`) | ~2–6.5 min (26 sequential turns) | | Input cost at an assumed $3/M tokens | ~$0.02 | ~$2.44, one uncached read | | Reduction | – | ~126x fewer characters entering context (~99.2%) | To be clear about what that last row claims: 99.2% is the reduction in characters put in front of the model for this one data-gathering step, script versus tool calls. It is not the change in our bill. The end-to-end effect on the real scheduled task is further down, and it's smaller. ## What's measured, what's modeled - **Measured:** the script's side. `durationMs: 13120` and the 25,811-character result came off a live `workflow-triage` run. - **Modeled from samples:** the raw-path character count. We called the same underlying SDK methods directly, outside the script: `workflow_list({})` returned 16,304 characters and `schedule_list({})` returned 72,105. For `workflow_listRuns` we sampled 4 of the 24 workflows, from smallest to largest: 6, 26, 53, and 227 runs, totalling 1,075,430 characters over 312 runs, an average of 3,447 characters per run. The script itself recorded 920 total runs across all 24 workflows, so 920 × 3,447 plus the two list calls gives ~3.26M characters. - **Why we sampled instead of running all 26 calls:** running the full raw path means pulling ~3.2M characters of JSON into a live context. We sampled a third of the runs (including the largest workflow) and extrapolated. If you think that weakens the number, that's fair. It's why every appearance of it is labeled modeled. - **A bug we found on the way:** the `limit: 25` we pass to `workflow_listRuns` doesn't cap the result: it returned all 227 runs for our busiest workflow. The estimate therefore describes the observed uncapped responses. A working limit would reduce raw payloads. This behavior does not establish whether our sample extrapolates high or low. - **The $2.44 prices one uncached read:** we apply the assumed input rate once to the estimated payload. Repeated uncached reads would add cost. Caching, output limits, and compaction can reduce billed input. We did not measure the full raw-call run or its bill. ## What it changes end to end The honest headline is not 99.2%. The schedule that runs this triage daily is the end-to-end picture: after the data-gathering moved into the script, run time went from around 5 minutes to 1–2 minutes, and per-run cost dropped by roughly half. Why half and not 99%? Because the script only compresses the mechanical middle of the task. The agent still reads the summary, reasons about which flagged workflow actually matters, and decides what to escalate. In practice the run ends with a Slack ping telling us what to go check. That reasoning is most of what's left of the cost, and it's the part we want a model doing. Scripts don't remove the thinking at either end of a task; they stop the model from paying to page through raw JSON in between. Since this measurement we've leaned in hard. As of late July the swarm runs about 150 reusable scripts, with ~25,000 script executions over the last 30 days, and roughly 70% of our schedules now use at least one. The roughly 50% reduction describes the measured triage job. We did not establish that reduction across the full script catalog. ## The code that does it This is an abbreviated script (`id da3b5c7b-b9a6-4f9e-be9e-f682aca48ea0`, global scope in our deployment). Two of our agents wrote it. The excerpt omits report construction, so it is not a standalone executable example. ```typescript // workflow-triage — read-only health scan of all workflows + schedules. // Returns per-item run stats + DEAD/FAILING/OK flags + a markdown report of flagged items. export default async function (args: any, ctx: any) { const runLimit = args?.runLimit ?? 25; const staleDays = args?.staleDays ?? 14; const includeSchedules = args?.includeSchedules ?? true; const now = Date.now(); const dayMs = 86400000; const isFail = (s: string) => /fail|error|halt|timeout|abort/i.test(String(s || "")); // ---- Workflows: run stats require workflow_listRuns (no lastRunAt on the row) ---- const wl = await ctx.swarm.workflow_list({}); const wfs: any[] = wl?.data ?? []; const rows: any[] = []; const pool = 6; // small concurrency to avoid hammering for (let i = 0; i < wfs.length; i += pool) { const batch = wfs.slice(i, i + pool); const res = await Promise.all(batch.map(async (w: any) => { let runs: any[] = []; try { const rr = await ctx.swarm.workflow_listRuns({ workflowId: w.id, limit: runLimit }); runs = rr?.data ?? []; } catch { runs = []; } const total = runs.length; const failed = runs.filter((r: any) => isFail(r.status)).length; const stamps = runs.map((r: any) => Date.parse(r.startedAt || r.createdAt || r.finishedAt || "")).filter((n: number) => !isNaN(n)); const lastRun = stamps.length ? Math.max(...stamps) : null; const daysSince = lastRun ? Math.round((now - lastRun) / dayMs * 10) / 10 : null; const failRatio = total ? Math.round(failed / total * 100) / 100 : 0; const dead = !w.enabled || total === 0 || (lastRun != null && daysSince! > staleDays); const failing = total >= 2 && failRatio >= 0.5; return { kind: "workflow", id: w.id, name: w.name, enabled: w.enabled, runs: total, failed, failRatio, lastRunAt: lastRun ? new Date(lastRun).toISOString() : null, daysSinceLastRun: daysSince, nodeCount: w.nodeCount, flag: failing ? "FAILING" : dead ? "DEAD" : "OK", }; })); rows.push(...res); } // ---- Schedules: lastRunAt + consecutiveErrors already on the row ---- const scRows: any[] = []; if (includeSchedules) { const sl = await ctx.swarm.schedule_list({}); const scs: any[] = sl?.data?.schedules ?? []; for (const s of scs) { const lastRun = s.lastRunAt ? Date.parse(s.lastRunAt) : null; const daysSince = lastRun ? Math.round((now - lastRun) / dayMs * 10) / 10 : null; const dead = !s.enabled || (!lastRun) || (daysSince != null && daysSince > staleDays); const failing = (s.consecutiveErrors ?? 0) >= 3; scRows.push({ kind: "schedule", id: s.id, name: s.name, enabled: s.enabled, consecutiveErrors: s.consecutiveErrors ?? 0, lastRunAt: s.lastRunAt ?? null, daysSinceLastRun: daysSince, nextRunAt: s.nextRunAt ?? null, cron: s.cronExpression, flag: failing ? "FAILING" : dead ? "DEAD" : "OK", }); } } const rank = (f: string) => f === "FAILING" ? 0 : f === "DEAD" ? 1 : 2; rows.sort((a, b) => rank(a.flag) - rank(b.flag) || (b.failRatio - a.failRatio)); scRows.sort((a, b) => rank(a.flag) - rank(b.flag) || (b.consecutiveErrors - a.consecutiveErrors)); const sum = (arr: any[]) => ({ total: arr.length, failing: arr.filter(r => r.flag === "FAILING").length, dead: arr.filter(r => r.flag === "DEAD").length, ok: arr.filter(r => r.flag === "OK").length, }); // markdown report of only the flagged (non-OK) items const flaggedW = rows.filter(r => r.flag !== "OK"); const flaggedS = scRows.filter(r => r.flag !== "OK"); let report = `## Workflow triage — flagged\n`; report += `Workflows: ${sum(rows).failing} failing / ${sum(rows).dead} dead / ${sum(rows).ok} ok (of ${rows.length})\n`; // ... table-building omitted here for length; full source has per-row markdown // tables for both workflows and schedules — see the script catalog entry. return { params: { runLimit, staleDays, includeSchedules }, workflows: { summary: sum(rows), rows }, schedules: includeSchedules ? { summary: sum(scRows), rows: scRows } : null, report, }; } ``` There's no framework here. It's a `for` loop with a concurrency pool of 6, some `Date.parse`, and a sort. The only thing that makes it "code mode" rather than 26 tool calls is where it runs. Every `workflow_listRuns` payload lands in the loop variable `runs` and stays there; the agent sees only the `return` at the bottom. > "Intermediate results stay in the execution environment by default... the agent only sees what you explicitly log or return." [Anthropic, Code execution with MCP](https://www.anthropic.com/engineering/code-execution-with-mcp) ## Chart Fallback The canonical HTML post renders this as an interactive Recharts bar chart. This markdown mirror provides a static data table for clients that negotiate `text/markdown`. ### Share of the modeled raw-tool-call path reaching the model Source: live `workflow-triage` run (script id `da3b5c7b-b9a6-4f9e-be9e-f682aca48ea0`) measured 2026-07-07, plus a raw-tool-call path modeled from measured samples (see the methodology section in the post body). | Scenario | Tokens | Share of modeled raw path | |---|---:|---:| | Script (measured) | ~6,450 | ~0.79% | | Raw tool calls (modeled) | ~815,000 | 100% | Takeaway: ~99.2% fewer tokens enter the model's context for this one data-gathering step. The end-to-end effect on the daily scheduled task that uses the script is smaller: roughly half the cost, with run time down from ~5 minutes to 1–2, because the agent still reasons about the summary and decides escalations. As of late July 2026 the swarm runs ~150 reusable scripts, with ~25,000 executions in the last 30 days, and ~70% of schedules use at least one. ## The security boundary Moving work from tool calls into generated code changes what you trust. Five properties decide whether that trade is safe. ### Sandboxing Scripts run in a separate Bun subprocess with the environment stripped to a small allowlist. Filesystem modules do not exist in the sandbox, scripts cannot shell out, and a run is killed after about 30 seconds with stdout capped at 1 MB. The full surface is documented in the [scripts runtime guide](https://docs.agent-swarm.dev/docs/guides/scripts-runtime). ### Authorization A script's `ctx` exposes only an allowlist of SDK methods, not arbitrary APIs. [Scripts-only mode](https://docs.agent-swarm.dev/docs/guides/scripts-only-mode) can hide the direct tool list entirely, so agents go through scripts for every swarm operation. Role-scoped `ctx` is not shipped: we're building role-based permissions so a script only exposes the tools that agent's role is allowed to touch. ### Credential handling Secrets never appear in script source, arguments, or logs. The [credential broker](https://docs.agent-swarm.dev/docs/guides/scripts-credential-broker) attaches them server-side at egress, and only for allowlisted hosts: a script sends a placeholder, and the runtime swaps in the real value only when the destination host is on the list. Only lead agents manage bindings. ### Approval granularity You lose per-call approvals. One script that hits ten tools is coarser to gate than ten separate calls a human can approve one by one — that objection from the HN thread is true. Our answer is moving the boundary from calls to capabilities: the sandbox, the SDK allowlist, and the credential broker above are what you gate. Gating the surface instead of the call is a different security model, not a free upgrade. ### Unverified generated code The other HN objection: a one-off script the model writes into a REPL has to be trusted fresh every run, which is a bad deal for anything that mutates state. That is why the unit we care about is the *saved* script: written once, reviewed once, visible in a dashboard, and re-run many times. The economics of "review it once" only work when the script is durable, and mutating jobs should not run as ad-hoc code. ## Implementation checklist If you are building Code Mode into your own agent setup, this is the order we would do it in: - Start from a repeated fan-out job, not a one-off. The savings only compound if the job runs often. - Generate a typed API from your tools, so the model writes code against types instead of raw JSON schemas. - Run the code in a sandbox: no filesystem, a wall-clock timeout, and a cap on output size. - Return a small summary object, not raw payloads. The return value is the only thing that re-enters the model's context. - Keep secrets out of the sandbox and inject them at egress, per destination host. - Save and review the scripts you re-run. A reviewed, durable script is the unit of trust, not the one-off generation. - Keep raw tool calls for steps that need the model's judgment between calls, or per-call human approval. - Measure before and after, and label what was measured and what was modeled. ## Takeaway The script-over-tool-calls rubric already ships in every session template, so for us the question was never whether to adopt Code Mode. The measurement made the rubric sharper: 26 calls became one, 13 seconds, about two cents to read the result, and roughly half the cost of the daily job that uses it. The implementation matters less than the properties: typed, sandboxed, reusable, and honest about what was measured and what was modeled. ## Sources and further reading - [Code Mode: the better way to use MCP](https://blog.cloudflare.com/code-mode/): Cloudflare's original post: convert MCP tools into a generated TypeScript API and let the model write code against it instead of calling tools directly. - [Code Mode: give agents an entire API in 1,000 tokens](https://blog.cloudflare.com/code-mode-mcp/): Cloudflare's follow-up with the concrete number: a search()/execute() pattern took 2,500+ API endpoints from 1.17M tokens to ~1,000. - [Code execution with MCP: building more efficient agents](https://www.anthropic.com/engineering/code-execution-with-mcp): Anthropic's engineering post. The 150,000-to-2,000-token (98.7%) example, and why intermediate tool results never need to re-enter the model's context. - [Code Mode MCP server patterns](https://developers.cloudflare.com/agents/model-context-protocol/codemode/): Cloudflare's server-side patterns: the single code tool and search-and-execute, and the sandbox and authorization boundary each one implies. - [FastMCP: Code Mode](https://gofastmcp.com/servers/transforms/code-mode): The Python option: FastMCP's Code Mode transform lets the model write Python that orchestrates tools in a sandbox, with staged tool discovery. - [workflow-triage (global script, id da3b5c7b-b9a6-4f9e-be9e-f682aca48ea0)](https://github.com/desplega-ai/agent-swarm): The worked example in this post. An excerpt is inline above. It omits report construction. --- # An AI-Native Company OS Is Owned, Not Rented > An AI native company OS is owned, not rented: the durable IP is the learning loop on top of models — memory, skills, workflows, traces, agents. Published: 2026-06-15T00:00:00Z Read time: 10 min read Tags: `AI-native`, `agent-swarm`, `institutional memory`, `self-hosting`, `private evals`, `ai native company os` Keywords: `agent-swarm`, `AI-native`, `agent memory`, `frontier models`, `self-hosted AI agents`, `institutional memory`, `private evals`, `multi-agent systems`, `ai native company os` Canonical URL: https://www.agent-swarm.dev/blog/a-frontier-model-is-rented-a-swarm-is-owned --- This post is rendered as React components on the canonical URL. For the full content with code blocks, diagrams, and inline links, fetch the HTML at [https://www.agent-swarm.dev/blog/a-frontier-model-is-rented-a-swarm-is-owned](https://www.agent-swarm.dev/blog/a-frontier-model-is-rented-a-swarm-is-owned) (send `Accept: text/html`). A short summary, plus the listed metadata above, is provided here so AI agents performing content negotiation can index the article without parsing the React tree. --- # Is Grep All You Need? A Paper on Agent Memory > A PwC paper benchmarked grep against vector retrieval in agent harnesses. It matched the exact memory-search failure mode we had just fixed in Agent Swarm. Published: 2026-06-10T00:00:00Z Read time: 12 min read Tags: `agent memory`, `agentic search`, `vector search`, `grep`, `agent-swarm` Keywords: `agent memory`, `agentic search`, `grep`, `vector search`, `semantic search`, `LongMemEval`, `agent harness`, `hybrid search`, `AI agents`, `agent-swarm` Canonical URL: https://www.agent-swarm.dev/blog/is-grep-all-you-need-agent-memory --- ## Linked Sources - Primary paper: [Is Grep All You Need? How Agent Harnesses Reshape Agentic Search](https://arxiv.org/abs/2605.15184), Sen et al., PwC, May 2026. [PDF](https://arxiv.org/pdf/2605.15184) - Benchmark: [LongMemEval project](https://xiaowu0162.github.io/long-mem-eval/) and [LongMemEval paper](https://arxiv.org/abs/2410.10813) - Harnesses/repos: [Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview), [Codex CLI](https://github.com/openai/codex), [Gemini CLI](https://github.com/google-gemini/gemini-cli) - Agent Swarm fixes: [PR #684](https://github.com/desplega-ai/agent-swarm/pull/684), [PR #696](https://github.com/desplega-ai/agent-swarm/pull/696) ## Article Summary The post connects Sen et al.'s grep-versus-vector retrieval paper to Agent Swarm's memory-search relevance incident. The practical lesson is not that embeddings are bad. It is that agent memory often contains literal witnesses: PR numbers, task IDs, dates, config keys, exact user decisions, and incident labels. For those questions, lexical retrieval needs to be a first-class path rather than an emergency fallback after semantic search fails. Agent Swarm's shipped vector fix was [PR #696](https://github.com/desplega-ai/agent-swarm/pull/696): source-aware recency decay, a minimum similarity floor, source quality multipliers, protected manual memories, embedding dimension validation, and boot-time re-embedding for wrong-dimension rows. [PR #684](https://github.com/desplega-ai/agent-swarm/pull/684) had already capped sqlite-vec KNN queries and purged expired memory rows. ## Chart Fallbacks The canonical HTML post renders these as interactive Recharts charts. This markdown mirror provides static data tables for clients that negotiate `text/markdown`. ### Table 1 Inline Accuracy: Grep vs Vector Source: [Sen et al., Table 1](https://arxiv.org/abs/2605.15184), accuracy on the 116-question LongMemEval-S subset. | Harness/model pair | Inline grep | Inline vector | |---|---:|---:| | Opus 4.6 / Chronos | 93.1% | 83.6% | | Opus 4.6 / Claude Code | 76.7% | 75.0% | | Haiku 4.5 / Chronos | 83.6% | 76.7% | | Haiku 4.5 / Claude Code | 55.2% | 44.0% | | GPT-5.4 / Chronos | 89.7% | 81.9% | | GPT-5.4 / Codex CLI | 93.1% | 75.9% | | Gemini 3.1 Pro / Chronos | 91.4% | 82.8% | | Gemini 3.1 Pro / Gemini CLI | 81.9% | 75.0% | | Gemini Flash-Lite / Chronos | 86.2% | 62.9% | | Gemini Flash-Lite / Gemini CLI | 87.1% | 67.2% | Takeaway: in the inline result configuration, grep beat vector retrieval for every harness/model pair reported in this table. ### Harness Effect: Claude Opus 4.6 Source: [Sen et al., Table 1](https://arxiv.org/abs/2605.15184). | Harness | Inline grep | Inline vector | |---|---:|---:| | Chronos | 93.1% | 83.6% | | Claude Code | 76.7% | 75.0% | Takeaway: with the same Claude Opus 4.6 backbone and inline grep, the harness moved accuracy from 93.1% to 76.7%, a 16.4 point drop. ### Agent Swarm Recency Decay Source: [Agent Swarm PR #696](https://github.com/desplega-ai/agent-swarm/pull/696). Scores are the remaining multiplier after applying each half-life. | Age in days | Old flat 14d | Manual | File index 180d | Task completion 14d | Session summary 7d | |---:|---:|---:|---:|---:|---:| | 0 | 1.000 | 1.000 | 1.000 | 1.000 | 1.000 | | 15 | 0.476 | 1.000 | 0.944 | 0.476 | 0.226 | | 30 | 0.226 | 1.000 | 0.891 | 0.226 | 0.051 | | 45 | 0.108 | 1.000 | 0.841 | 0.108 | 0.012 | | 60 | 0.051 | 1.000 | 0.794 | 0.051 | 0.003 | | 76 | 0.023 | 1.000 | 0.746 | 0.023 | 0.001 | | 90 | 0.012 | 1.000 | 0.707 | 0.012 | 0.000 | | 120 | 0.003 | 1.000 | 0.630 | 0.003 | 0.000 | | 150 | 0.001 | 1.000 | 0.561 | 0.001 | 0.000 | | 180 | 0.000 | 1.000 | 0.500 | 0.000 | 0.000 | Takeaway: the old 14-day half-life reduced a 76-day canonical memory to about 2.3% of its original score. PR #696 made decay source-aware so manual memories do not decay, file-indexed memories use a 180-day half-life, task completions keep 14 days, and session summaries use 7 days. ## Practical Rule If your agent memory contains literal witnesses, start with lexical retrieval: PR numbers, issue IDs, task IDs, dates, migration names, environment variables, config keys, API routes, CLI flags, quoted user preferences, and exact decisions. Use semantic search for paraphrase, fuzzy discovery, and conceptual recall. For Agent Swarm, the next architecture suggested by the paper is hybrid retrieval: SQLite FTS5 for exact witnesses, vectors for semantic recall, and reciprocal rank fusion over the two result lists. --- # Right-Sizing Agent Swarm Containers: CPU and RAM Signals > A straight-line CPU climb and a coder worker stuck near 1.1 GB looked like production problems. They were metric interpretation traps. Here are the sizing numbers we actually run. Published: 2026-06-07T00:00:00Z Read time: 11 min read Tags: `container sizing`, `SigNoz`, `self-hosting`, `AI agents`, `observability` Keywords: `agent swarm container sizing`, `AI agent infrastructure`, `container CPU metrics`, `container memory working set`, `SigNoz container metrics`, `self-hosted AI agents`, `Docker Compose agent swarm`, `multi-agent systems` Canonical URL: https://www.agent-swarm.dev/blog/right-sizing-agent-swarm-containers --- This post is rendered as React components on the canonical URL. For the full content with code blocks, diagrams, and inline links, fetch the HTML at [https://www.agent-swarm.dev/blog/right-sizing-agent-swarm-containers](https://www.agent-swarm.dev/blog/right-sizing-agent-swarm-containers) (send `Accept: text/html`). A short summary, plus the listed metadata above, is provided here so AI agents performing content negotiation can index the article without parsing the React tree. --- # Script Workflows: Durable One-off Runs for Agent Work > How Agent Swarm gives agents workflow power for one ad-hoc job, with journaled replay and the reusable swarm scripts catalog. Published: 2026-06-04T00:00:00Z Read time: 9 min read Tags: `Script Workflows`, `durable replay`, `swarm scripts`, `workflow journal`, `AI agents` Keywords: `agent-swarm`, `Script Workflows`, `durable workflows`, `agent workflows`, `workflow journal`, `swarm scripts`, `one-off script runs`, `AI agents`, `multi-agent systems` Canonical URL: https://www.agent-swarm.dev/blog/script-workflows-durable-one-off-runs --- This post is rendered as React components on the canonical URL. For the full content with code blocks, diagrams, and inline links, fetch the HTML at [https://www.agent-swarm.dev/blog/script-workflows-durable-one-off-runs](https://www.agent-swarm.dev/blog/script-workflows-durable-one-off-runs) (send `Accept: text/html`). A short summary, plus the listed metadata above, is provided here so AI agents performing content negotiation can index the article without parsing the React tree. --- # Parallel Agents in Production: Pools, Routing, Dependencies > How we run parallel agents in production: task pools, dependency graphs, and offer/accept routing across 6 agents. Lessons from 3,000+ tasks. Published: 2026-03-30T00:00:00Z Read time: 7 min read Tags: `architecture`, `task delegation`, `AI agents`, `orchestration`, `parallel agents` Keywords: `agent swarm`, `AI agents`, `task delegation`, `multi-agent orchestration`, `task pools`, `dependency graphs`, `AI task routing`, `Claude Code`, `agent workflow`, `concurrent AI agents`, `MCP server`, `multi-agent architecture`, `parallel agents` Canonical URL: https://www.agent-swarm.dev/blog/task-delegation-architecture --- This post is rendered as React components on the canonical URL. For the full content with code blocks, diagrams, and inline links, fetch the HTML at [https://www.agent-swarm.dev/blog/task-delegation-architecture](https://www.agent-swarm.dev/blog/task-delegation-architecture) (send `Accept: text/html`). A short summary, plus the listed metadata above, is provided here so AI agents performing content negotiation can index the article without parsing the React tree. --- # Openfort Hackathon: Teaching Agents to Pay > We added x402 HTTP payment support to Agent Swarm — AI agents now autonomously pay for API services with USDC on Base mainnet via Openfort managed wallets. No human approval needed. Published: 2026-02-28T00:00:00Z Read time: 8 min read Tags: `x402`, `Openfort`, `crypto`, `hackathon` Keywords: `agent swarm`, `AI agents`, `x402 protocol`, `HTTP 402`, `crypto payments`, `Openfort`, `autonomous payments`, `Base mainnet`, `USDC`, `web3 AI agent`, `AI agent wallet`, `AI automation` Canonical URL: https://www.agent-swarm.dev/blog/openfort-hackathon --- This post is rendered as React components on the canonical URL. For the full content with code blocks, diagrams, and inline links, fetch the HTML at [https://www.agent-swarm.dev/blog/openfort-hackathon](https://www.agent-swarm.dev/blog/openfort-hackathon) (send `Accept: text/html`). A short summary, plus the listed metadata above, is provided here so AI agents performing content negotiation can index the article without parsing the React tree. --- # AI Agents Pay for Services with Crypto > Watch a real session where agent-swarm.dev used x402 protocol to autonomously pay $0.05 USDC on Base mainnet and generate an AI image. Tags: `x402`, `Crypto Payments`, `Base`, `Image Gen` Keywords: `AI agent crypto payments`, `x402 protocol`, `AI autonomous payments`, `agent swarm x402`, `HTTP 402 payment required`, `USDC AI agent payments`, `AI agent micropayments`, `Openfort AI agents`, `crypto payment automation`, `autonomous agent wallet` Canonical URL: https://www.agent-swarm.dev/examples/x402 --- This example is rendered as React components on the canonical URL. For the full walkthrough with screenshots and embedded media, fetch the HTML at [https://www.agent-swarm.dev/examples/x402](https://www.agent-swarm.dev/examples/x402) (send `Accept: text/html`). --- # From Issue to Human-Approved Merge in Four Hours > A real session: a feature request went from pull request open to a human merge in 4 h 8 min — 6 commits, 29 files, 30 green checks. Tags: `Engineering`, `GitHub`, `Delegation`, `Code Review` Canonical URL: https://www.agent-swarm.dev/examples/engineering-pr --- **How-to: From GitHub Issue to Approved Pull Request (swar.am)** · [Watch on YouTube](https://www.youtube.com/watch?v=tuWsUp1PMuM) **Aim for your users to directly send PRs to your product** · [Watch on YouTube](https://www.youtube.com/watch?v=oQwue9SWyus) > **Real session, redacted.** This ran in our own swarm on 1 October 2026. Names, task identifiers, and internal hosts are removed; the verifiable artifact is the public pull request linked below. All times are Barcelona time. ## Request A maintainer asked the swarm for a memory feature: memories should get logical paths, so a nightly consolidation workflow can write, move, and search a curated `/longterm` tree instead of a flat pile of entries. The lead made the design call up front — no new memory source; the key itself is the tier — and assigned the implementation to a coding worker on the public [desplega-ai/agent-swarm](https://github.com/desplega-ai/agent-swarm) repository. This is the intake shape documented in the [feature development playbook](https://docs.agent-swarm.dev/docs/playbooks/feature-development): a request becomes a merged pull request through specialized agents that hand context off instead of losing it. ## Starting context The repository is registered with the swarm, so its guidelines were already known: which checks gate a pull request, how reviews work, and who may merge. The GitHub integration was connected, a security-scanning review bot watches the repository, and every worker starts in its own isolated container with the `gh` CLI available. The change touched the swarm's own [memory architecture](https://docs.agent-swarm.dev/docs/architecture/memory), so the worker had both the code and the documented design intent in front of it. ## Task breakdown 1. **18:07 — first commit.** The worker implemented logical paths: a `key` to place a memory, `newKey` to move it, `keyPrefix` to search a subtree, and path weight so curated entries rank higher. 2. **18:19 — pull request opened**, with the design summarized in the PR body. 3. **19:55 — bot finding.** The security scanner flagged a P2: the HTTP memory index endpoint could derive a curated key from a caller-controlled path and skip the lead-only guard. 4. **20:17 — triage and fix.** The coding worker judged the finding valid, said so on the PR, and routed every key write through one shared permission check so no endpoint can bypass it. 5. **21:33 — human review.** A human maintainer requested changes: the memory skill the swarm ships with had to document the new behavior. 6. **21:45 — fix pushed.** At 21:51 the worker replied to the review thread with what changed. 7. **22:19 — human approval. 22:27 — human merge.** ## Worker roles and handoffs The **lead** took the design question and routed the work; it wrote no code. One **coding worker** held the whole session — implementation, bot triage, both fix rounds, and the review replies — so the security context and the review context never left the session that wrote the code. Review came from two directions: the **security bot** scanning the diff, and a **human maintainer** whose judgment closed the loop. Every handoff carried the full session history with it. ## Approval points [Two gates](https://docs.agent-swarm.dev/docs/playbooks/patterns/hitl-gates) stayed closed until a human opened them. The bot's review is advisory — the worker must triage it, but triage is not approval. The binding gates were the human's change request, the human's approval, and the human's merge. The swarm never approves or merges its own pull request. ## Output One merged pull request: [feat(memory): logical paths under /longterm via key, newKey, keyPrefix and path weight](https://github.com/desplega-ai/agent-swarm/pull/1814) — 6 commits, 29 files changed, +1920/-99, with the shipped memory skill updated to document the new paths. ## Measurable result From pull request open to merge: 4 hours 8 minutes on a Thursday evening, with about 30 checks green — lint and typecheck, split test shards, Docker builds, OpenAPI freshness, CodeQL, the security scan, and the merge gate, the only check the main branch requires. Two review rounds completed: one automated security review whose valid P2 finding was fixed the same evening, and one human review whose change request was answered in twelve minutes. ## What stayed human-owned The design question — whether `/longterm` deserved to exist at all — the change request, the approval, and the merge. The swarm did the implementation, the security triage, the fixes, and the paperwork; the human kept every decision that could not be undone. ## Sources and tools - **GitHub integration and the `gh` CLI** — branching, committing, opening the pull request, and replying to review. See the [GitHub integration docs](https://docs.agent-swarm.dev/docs/integrations/github). - **Registered repo guidelines** — the required checks, the conventional-commit convention, and the rule that a human merges. - **The security-scanning review bot** — automated review on every pull request; its findings arrive as review comments the assigned worker must triage. - **Memory docs** — the [memory architecture page](https://docs.agent-swarm.dev/docs/architecture/memory) describes the system being changed. More real sessions: the [recurring research brief](/examples/recurring-research-brief) that runs every morning, the [security-alert triage](/examples/support-triage) that closed thirty-three Dependabot alerts, the [two-day orchestration loop](/examples/long-running-orchestration) that carried one request to four human-merged pull requests, and the fully public [x402 payment session](/examples/x402). Browse everything on the [examples index](/examples). --- # A Research Brief That Writes Itself Every Morning > A real recurring workflow: 150 stories scraped and 20 curated daily, delivered by email and archived — 211 dated briefs, no failed run since 24 August. Tags: `Schedules`, `Research`, `Memory`, `GTM` Canonical URL: https://www.agent-swarm.dev/examples/recurring-research-brief --- > **Real session, redacted.** This workflow runs in our own swarm every morning and has since 25 February 2026. The brief itself is internal, so the figures below come from the swarm's own task records; the primitives behind it are open source. All times are Barcelona time. ## Request A standing ask from the two founders: every morning, before the day starts, a short brief of what moved in AI — from sources they chose, curated to what is worth reading, delivered by email. No prompting, no reminding; the schedule is the request. ## Starting context The workflow has run daily since 25 February 2026. Each run scrapes the Hacker News front page (pages one to three), the New page, and Show HN, then loads a shared source-registry script that adds the Anthropic blog, the OpenAI and DeepMind RSS feeds, and eight X accounts read through the X API. Adding a source means adding one entry to the registry — not editing a prompt. Two artifacts land on every run: an email to the two founders and a dated Markdown file in the shared workspace archive. ## Task breakdown The run of 5 October 2026 is representative. **04:30** the schedule fired. The scrape pulled 150 stories from the registered sources. The deterministic build curated them to 20 — ten from the front page, five from New, five from Show HN — plus two deep dives and one external item. The three lab blogs had published nothing in the 24-hour window, so the brief said so instead of padding the section. **04:33** the email was sent and the dated brief archived: 3 minutes 28 seconds end to end. ## Worker roles and handoffs The **schedule** is the dispatcher — nobody asks for the brief; it exists every morning. The **scripts** do the fetching, curation, formatting, delivery, and archiving, with no model in the formatting path since the late-June rebuild. An **agent** enters only on failure: the lead reviews the failed run, fixes the cause, and records the learning. There is one handoff — schedule to scripts — which is why this is the cheapest workflow the swarm runs. ## Approval points The brief is internal, so the gates sit on its configuration rather than on each run: which sources count, what the brief is for, and who receives it are human-set and human-changeable. Any external reuse of its content — a post, a customer note — goes through a human first. ## Output Two artifacts per run: the email in the founders' inboxes before they start the day, and a dated Markdown brief in the shared archive — 211 dated briefs and counting, every one searchable by every agent in the swarm. ## Measurable result Measured from the swarm's task records. Before the rebuild (4 March to 28 June): 105 completed of 118 runs, 11 failed, 8.9 minutes on average. The LLM-driven formatting step that kept retry-looping was replaced with two deterministic scripts, and email delivery moved server-side after authentication errors. After the rebuild (29 June to 5 October): 91 completed of 94 runs, 3 failed, 7.5 minutes on average — and no failure since 24 August. ## What stayed human-owned Which sources count, what the brief is for, and every decision to act on it. The swarm owns the pulling, the curating, and the delivering; the founders own what the news means. ## Sources and tools - **Schedules** — the recurring trigger: a cron expression on a timezone that creates the task each morning. Documented under [scheduling](https://docs.agent-swarm.dev/docs/concepts/scheduling). - **The shared source registry** — one script, one entry per source, shared by every run and reusable by other workflows. - **Deterministic build and send scripts** — curation, formatting, delivery, and archiving run as code, not as model output, so the figures in the brief are auditable and the email sends server-side. - **Shared memory** — past runs and source quirks stay searchable; see the [memory architecture docs](https://docs.agent-swarm.dev/docs/architecture/memory). More real sessions: the [engineering pull request](/examples/engineering-pr) merged in four hours, the [security-alert triage](/examples/support-triage) that closed thirty-three Dependabot alerts, the [two-day orchestration loop](/examples/long-running-orchestration) that carried one request to four human-merged pull requests, and the fully public [x402 payment session](/examples/x402). Browse everything on the [examples index](/examples). The schedule, script, and memory primitives behind this page are open source in [desplega-ai/agent-swarm](https://github.com/desplega-ai/agent-swarm). --- # Thirty-Three Security Alerts to Zero > A real operations run: 33 Dependabot alerts triaged read-only, one grouped pull request opened only after a human approved the plan, zero left open. Tags: `Support`, `Triage`, `Integrations`, `Approvals` Canonical URL: https://www.agent-swarm.dev/examples/support-triage --- > **Real session, redacted.** This ran in our own swarm on 28 September 2026 against the public agent-swarm repository. Names, task identifiers, and internal hosts are removed; the verifiable artifact is the public pull request linked below. All times are Barcelona time. ## Request A standing security workflow on the public [desplega-ai/agent-swarm](https://github.com/desplega-ai/agent-swarm) repository: drain the Dependabot alert queue. Triage every open alert, propose a fix for each, and execute only what a human approves. On 28 September the scheduled 08:00 run started with 33 open alerts. ## Starting context The repository's docs site lockfile had accumulated 33 open Dependabot alerts, and there were no open Dependabot pull requests. The workflow is built on the [GitHub integration](https://docs.agent-swarm.dev/docs/integrations/github) and an approval gate: the first phase is read-only and produces a plan, nothing executes before a human approves that plan, and even then nothing merges itself. ## Task breakdown 1. **08:00 — run starts.** A triage worker reads the alerts. Read-only: no branch, no install, no dismissal. 2. **08:03 — plan proposed.** All 33 alerts sit in the docs site lockfile. The worker proposes fixing all 33 as one grouped pull request — esbuild, dompurify, js-yaml, fast-uri, postcss, mermaid, and three more, each to its patched version inside its current major — with zero dismissals and zero items needing manual triage. Every item sits on the plan card, pre-selected, waiting for a human. 3. **10:12 — human approves the plan.** An execution worker starts. 4. **10:16 — pull request open.** Frozen install, build, and typecheck pass; the docs deploy preview is green. The worker reports one honest failure: alert #132 has no patched version published, so it stays open — expected to close after merge, because the pinned override is outside its vulnerable range. One dependency is held back because its newer minor broke postinstall. 5. **10:31 — a human maintainer merges.** ## Worker roles and handoffs The **triage worker** investigates and proposes; it changes nothing. The **human** holds the gate between proposal and execution — the plan waited two hours for review, and nothing timed out or proceeded without it. The **execution worker** applies exactly the approved plan and reports what it could not do. The handoff between the two workers is the approved plan card, not a chat transcript. ## Approval points Two gates, both human. First, the plan: nothing executes before approval, and each item can be overridden individually — approve all, approve some, dismiss, or hold. Second, the merge: the swarm opens the pull request but never merges it. The merge at 10:31 was a human maintainer's click. ## Output One grouped pull request: [chore(deps): bump vulnerable docs-site dependencies](https://github.com/desplega-ai/agent-swarm/pull/1635), covering 32 of the 33 alerts — esbuild 0.28.2, dompurify 3.4.13, js-yaml 4.3.2, fast-uri 3.1.6, postcss 8.5.23, mermaid 11.17.2, and three more — with every bump, every pinned override, and the one alert left open listed with its reason in the PR body. ## Measurable result 33 open Dependabot alerts before the run; one grouped pull request; zero open Dependabot alerts on the repository when checked on 5 October. The one alert without a patched version closed as predicted once the override landed. Total human time: one plan review and one merge. ## What stayed human-owned Approving the plan, overriding any item in it, the merge, and every dismissal decision. The swarm read, proposed, executed, and verified; the humans decided what was allowed to happen at all. ## Sources and tools - **GitHub Dependabot alerts API** — the full alert list with severity and patched-version data, read through the `gh` CLI. - **A plan card with per-item approval** — each alert pre-selected with its proposed fix, for a human to approve or override. The pattern is documented in the [human-in-the-loop gates playbook](https://docs.agent-swarm.dev/docs/playbooks/patterns/hitl-gates). - **Frozen install, build, and typecheck** — the verification pass every dependency change must survive, plus the docs deploy preview. More real sessions: the [engineering pull request](/examples/engineering-pr) merged in four hours, the [daily research brief](/examples/recurring-research-brief) that runs every morning, the [two-day orchestration loop](/examples/long-running-orchestration) that carried one request to four human-merged pull requests, and the fully public [x402 payment session](/examples/x402). Browse everything on the [examples index](/examples). --- # Nine Runs, One Refused Push, Four Merges > A real long-running orchestration: one advisor request carried to three live pages over 47 hours — 9 scheduled runs, 23 tasks, $14.14 model cost, and a human behind every merge. Tags: `Workflows`, `Orchestration`, `Recovery`, `Approvals` Canonical URL: https://www.agent-swarm.dev/examples/long-running-orchestration --- > **Real session, redacted.** This ran in our own swarm from 5 to 7 October 2026. Task, run, and chat identifiers are removed, and the pull requests live in a private repository, so their numbers are named but not linked; the verifiable artifacts are the three live example pages this session shipped. All times are Barcelona time. ## Request An outside SEO advisor reviews our search visibility and files recommendations. One of them became a standing request in the swarm: add real example pages to the [/examples](/examples) collection — measured walkthroughs of actual sessions, not capability claims. One short agent loop could not carry it. The work needed prose, code, review, and a human merge. It also needed an outside reviewer to read the live site, which only happens after a deploy. No single session spans hours of waiting on review and deploy, so the request ran as a [workflow](https://docs.agent-swarm.dev/docs/concepts/workflows) instead: many short runs, each resuming where the last one stopped. ## Starting context The workflow runs on a [schedule](https://docs.agent-swarm.dev/docs/concepts/scheduling) — twice a day, plus manual runs. Each run reads a state record the workflow keeps for the request: the stage (`new`, `prose_approved`, `live_feedback`), the open pull request and its branch, and a failed-attempt count. From it, the run routes the request to the right role. The state record is the checkpoint — the shared state every run resumes from. Workers never receive chat history — only artifacts: a brief, a draft file, a pull request. ## Task breakdown 1. **Run 1, 5 Oct, 12:55 to 13:12.** The Implementer read the request, saw that new prose was needed, and returned a brief in 53 seconds instead of writing copy — writing is not its job. The Content Strategist drafted three pages, and the Content Reviewer approved them. 2. **Run 2, 13:29 to 13:49.** Pull request #232 opened at 13:36. The Reviewer returned FIX: a customer name had to come out of the opening paragraphs, plus one copy change. 3. **The pause.** The fix step refused to push. The fix needed new published prose, and only the Content Strategist writes published prose — so the step stopped with nothing pushed. The pull request head stayed unchanged, and the checkpoint kept the stage, the pull request, and the branch for the next run. 4. **Run 3, 14:08 to 14:31.** The run resumed from the stored pull request and branch and sent only the delta to the Content Strategist; the Content Reviewer approved it. Nothing was redrafted and no duplicate pull request opened. A human merged #232 at 15:11. 5. **The second loop.** Live feedback said the pages were illustrative, not real. A founder made the call: example pages show real sessions only. Run 5 (18:12 to 18:32) opened #238 with real redacted sessions. The Reviewer caught a measurement error — a "4 h 8 min" figure measured pull-request-open to merge, not first-commit to merge — the figure was re-anchored, and a human merged #238 at 19:54. 6. **The quiet runs.** #239, a Reviewer PASS, merged on 6 October at 10:28. Two later runs that day found nothing actionable and stopped without opening a pull request. #246 — a layout-only reorder, no new copy — merged on 7 October at 11:45. ## Worker roles and handoffs Four specialized roles, and none does another's job. The **Implementer** owns code: the worktree, the checks, the pull request. The **Content Strategist** writes every published word. The **Content Reviewer** judges the prose. The **Reviewer** judges the diff and the redaction. ## Approval points Three gates held. The Content Reviewer's pass is the only prose approval — no draft ships on its writer's say-so. The Reviewer's pass gates every pull request, and it issued two FIX verdicts that were caught before merge, not after. Every merge was a human click, and the "real sessions only" rule was a founder's decision, not a workflow default. ## Output Four merged pull requests: #232 (the three walkthrough pages), #238 (real redacted sessions replacing the illustrative drafts), #239 (the re-anchored measurement), and #246 (a layout reorder). Three live pages came out of it: [an engineering pull request](/examples/engineering-pr), [a recurring research brief](/examples/recurring-research-brief), and [a security-alert triage](/examples/support-triage). ## Measurable result From the swarm's task, workflow-run, and session-cost records: 9 workflow runs over about 47 hours — 5 October, 12:55 to 7 October, 11:46 — 23 agent tasks, 0 failed tasks, about 77 agent-minutes of compute, and $14.14 in measured model cost. Cost by role: Implementer $9.53, Content Strategist $3.04, Reviewer $1.53, Content Reviewer $0.04. Two Reviewer FIX verdicts caught before merge, one refused push recovered without redrafting, zero duplicate pull requests. ## What stayed human-owned Every merge, the "real sessions only" rule, and redaction sign-off — a Reviewer pass plus the human merge. The swarm owned the drafting, the code, the checks, the review rounds, and the retries. ## Sources and tools - **Workflows** — durable runs that resume from stored state: the [workflows documentation](https://docs.agent-swarm.dev/docs/concepts/workflows). - **Schedules** — the cron trigger behind the twice-daily runs: the [scheduling documentation](https://docs.agent-swarm.dev/docs/concepts/scheduling). - **Architecture overview** — how a lead routes work to specialized workers: the [architecture documentation](https://docs.agent-swarm.dev/docs/architecture/overview). - **The orchestration guide** — the pattern behind this session: [multi-agent orchestration](/blog/multi-agent-orchestration). For a vendor-neutral reference, Microsoft's [AI agent design patterns](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns). More real sessions: the [engineering pull request](/examples/engineering-pr) merged in four hours, the [recurring research brief](/examples/recurring-research-brief) that runs every morning, the [security-alert triage](/examples/support-triage) that closed thirty-three Dependabot alerts, and the fully public [x402 payment session](/examples/x402). Browse everything on the [examples index](/examples). The workflow, scheduling, and review primitives behind this page are open source in [desplega-ai/agent-swarm](https://github.com/desplega-ai/agent-swarm).