Platform April 24, 2026 6 min read

Squad: Open-Source Multi-Agent Orchestration

Gateway-centric. Connector-based. Docker-first. Subagents, tasks, and ask-user as native protocol primitives — not markdown hacks.

I built lobs-core over eight versions. Each time, the bottleneck wasn't the agent itself — it was coordination. Running one agent is easy. Running a team of agents that need to talk to each other, share state, spawn subagents, and route requests across platforms? That's where every framework falls apart.

Squad is what I built to solve that properly.

The Problem with Script-Based Orchestration

Most agent coordination today happens one of two ways: either a single monolithic agent that tries to do everything, or a mess of scripts that trigger other scripts with bash pipes and prayer.

The first approach hits ceiling after ceiling as you add capability. The second approach is technically functional but breaks the moment you need anything more than a linear pipeline. What happens when a subagent fails? When you need parallel execution? When you need to route a question back to the user mid-workflow?

Most frameworks patch around these with markdown instructions and hope the LLM follows them. Squad treats coordination as a first-class concern with native protocol support.

The Gateway: Center of Everything

Squad's architecture has one core principle: the gateway is the center of everything.

Connector (Discord, Slack, API...) → Gateway → Agent Runtime (Ollama, OpenAI...)

All agents register with the gateway. All communication flows through the gateway. This means:

Connectors: One Agent, Many Faces

Connectors are adapters for each platform. Discord, Slack, HTTP, CLI — they all look the same from the gateway's perspective. The connector converts the platform's protocol into Squad's internal message format, and vice versa on the way back.

This means you can:

Native Primitives

The three core coordination primitives in Squad are:

Tasks — Work items with state, ownership, and lifecycle. A task can fail, be retried, or spawn sub-tasks. The gateway tracks task state so nothing gets lost.

Subagents — Spawning a subagent isn't a markdown instruction, it's a protocol message. The gateway handles spawning, routing, and result collection. You get parallelism without race conditions.

Ask-user — Per-channel, blocking. The gateway pauses the workflow and asks the user a specific question before continuing. Not a tool, not a markdown instruction — a first-class protocol primitive.

Pluggable Runtimes

Squad doesn't care what model you use. The runtime interface is clean and swappable. Currently supported:

Swap providers with a config change. Test the same workflow against different models without rewriting anything.

Plugin API

The plugin system exposes hooks for every lifecycle event. Write once, run in any agent. Plugins handle:

Docker-First

Every agent runs in its own container. Isolation, reproducibility, and one command to deploy. The Docker Compose setup gets you a full Squad environment in under a minute:

git clone https://github.com/lobs-ai/squad.git
cd squad
docker compose up

Status

Gateway core and basic connectors are working. The agent runtime, workflow engine, and full plugin system are in progress. See SPEC.md for the complete design specification.

What's Next

The workflow engine is the biggest remaining piece — DAG-based workflow definitions with branching, rollback, and cron scheduling. Then the observability layer: structured logs, traces, and a UI to see what's happening across your agents in real time.

If you want to follow along or contribute, the repo is at github.com/lobs-ai/squad.