How do you build reliable multi-agent systems?

Give each agent its own workspace, write the workflow down as explicit steps, and keep the main agent's context clean by handing side tasks to subagents. In March 2026, three open resources covered those parts: Galactic, a macOS app that gives parallel coding agents their own Git worktree and network address; Binex, a new open-source runtime that runs agent workflows as a graph and records every step; and Simon Willison's guide chapter on subagents. All three package practices developers already used, and Binex was two weeks old.

Why do parallel agents get in each other's way?

A multi-agent system promises speed: several agents work on separate parts of a problem at the same time. The naive setup starts several coding agents in one checkout of the same repository, each on its own issue. Suppose two of them touch the same file:

• Agent A reads /src/config.ts, changes it and writes it back.
• Agent B read the same file a moment earlier and writes its own version.
• A's change is gone, and neither agent knows it happened.

File locks help against that, but other conflicts remain:

• Semantic conflicts: two agents change the same function with different goals, one for accuracy and one for speed.
• Contention for resources: both want the same dev-server port, GPU or database connection.
• Diverging conclusions: each agent reasons in its own context, and nobody reconciles the results.

The simplest safe setup runs agents one after another. That works, and it gives up the speed that made parallel agents attractive.

How do Git worktrees keep coding agents apart?

A Git worktree is an extra working directory attached to the same repository. In the words of the Git documentation, a repository "can support multiple working trees, allowing you to check out more than one branch at a time":

1
git worktree add -b agent-a ../app-agent-a
2
git worktree add -b agent-b ../app-agent-b
3
git worktree list

Each agent then works in its own directory on its own branch, and the work comes back together through a merge or pull request. All worktrees share one repository and history.

Galactic wraps this in a macOS desktop app (open source, AGPL-3.0, built by one developer since November 2025). It creates a worktree with one click and solves the port problem with network isolation: each environment gets its own loopback address, so the same stack can run on the same port several times over. Schematically:

1
/repo/main      branch main      127.0.0.1:3000
2
/repo/agent-a   branch agent-a   127.0.0.2:3000
3
/repo/agent-b   branch agent-b   127.0.0.3:3000

Galactic also runs an MCP server that shows active agent sessions from Cursor, VS Code, Claude and Codex in one place. Worktrees prevent agents from overwriting each other's files. They do not prevent incompatible changes: those now surface as merge conflicts, where you can see them.

How does Binex make a workflow explicit?

Binex (MIT licence, started on 9 March 2026 by a single developer) is a local runtime for agent workflows. You describe the workflow as a directed acyclic graph (DAG) in YAML. Each node names its agent, which can be an LLM, a local script, a human step or a remote agent, plus its inputs, outputs and dependencies. A bug-fix pipeline with a human approval gate looks like this in Binex's format:

1
name: bugfix-pipeline
2
nodes:
3
  researcher:
4
    agent: "llm://gemini/gemini-2.5-flash"
5
    system_prompt: "Investigate the bug in /src/validators.ts"
6
    inputs: {}
7
    outputs: [analysis]
8
  fixer:
9
    agent: "llm://gemini/gemini-2.5-flash"
10
    system_prompt: "Propose a fix based on the analysis"
11
    inputs:
12
      analysis: "${researcher.analysis}"
13
    outputs: [patch]
14
    depends_on: [researcher]
15
  review:
16
    agent: "human://approve"
17
    system_prompt: "Approve or reject the proposed fix"
18
    inputs:
19
      patch: "${fixer.patch}"
20
    outputs: [decision]
21
    depends_on: [fixer]

Binex stores the inputs, outputs, prompts and costs of every run in a local SQLite database. From the command line you run a workflow and inspect it afterwards:

1
binex run bugfix-pipeline.yaml
2
binex debug latest --node fixer
3
binex trace latest

debug shows the inputs and outputs per node, and trace the timeline of the run. Other commands compare two runs (diff, bisect) or re-run a single node with another model or prompt (replay). Nodes can branch on earlier results with a when condition, and Binex can also run LangChain, CrewAI and AutoGen components as nodes.

When should an agent hand work to a subagent?

A context window fills up. Simon Willison notes in his chapter on subagents (17 March 2026) that context limits "generally top out at around 1,000,000" tokens and that benchmarks often report better quality below 200,000. A subagent is his answer: the agent "dispatches a fresh copy of itself to achieve a specified goal, with a new context window that starts with a fresh prompt."

Claude Code does this as standard. Before it starts on a task in an existing repository, it runs an Explore subagent that searches the code and returns a summary. An example of the flow:

1. The main agent needs to know where input validation lives before it changes anything.
2. It dispatches a subagent with a narrow prompt: find the validation functions, and return their files, signatures and callers.
3. The subagent reads what it needs in its own context and returns a short summary.
4. The main agent continues with its own context intact.

Subagents can also run in parallel on independent files, and they can use a faster, cheaper model such as Claude Haiku. Willison also names specialist subagents: a code reviewer, a test runner that hides verbose test output from the main agent, and a debugger. OpenAI made subagents generally available in Codex on 16 March 2026, with default "explorer", "worker" and "default" agents.

Which tools give agents safer access to APIs and the web?

Composio centralises tool integration and authentication, so each agent does not have to handle API keys and OAuth flows itself. With its Python SDK you fetch the tools of a toolkit for a user and pass them to your agent framework:

1
from composio import Composio
2
 
3
composio = Composio()
4
tools = composio.tools.get(user_id="user@acme.org", toolkits=["GITHUB"])

Lightpanda is a headless browser written from scratch in Zig for agents and automation (AGPL-3.0). It speaks the Chrome DevTools Protocol (CDP), so Playwright and Puppeteer can drive it. In March 2026 it added its own commands in an "LP" domain: LP.getMarkdown on 5 March, which returns the rendered page as Markdown with "up to 80% fewer tokens per page" according to Lightpanda, and on 11 March LP.getSemanticTree, LP.getInteractiveElements and LP.getStructuredData, plus a built-in MCP server. With Playwright:

1
import { chromium } from 'playwright-core';
2
 
3
const browser = await chromium.connectOverCDP('ws://127.0.0.1:9222');
4
const page = await (await browser.newContext()).newPage();
5
await page.goto('https://example.com');
6
const client = await page.context().newCDPSession(page);
7
const { markdown } = await client.send('LP.getMarkdown');
8
const tree = await client.send('LP.getSemanticTree', { format: 'text' });

How do the pieces fit together?

Think of a reliable setup as three layers:

• Workflow: every step and hand-off is defined in a file, and every node logs its input, output and cost (Binex-style).
• Isolation: worktrees for work on files, subagents for exploration and other token-heavy side tasks.
• Tool access: authentication in one place (Composio-style), and structured page data such as Markdown or a semantic tree instead of raw HTML.

What should you check before running agents in parallel?

• Is every hand-off between agents defined in a workflow file, or does it depend on a chat transcript?
• Does each agent have its own worktree, branch or subagent context?
• Do tool calls go through one place that handles authentication?
• Are the inputs, outputs and costs of every step recorded?
• Is there a human approval step for changes that are hard to undo?
• Can you re-run a failed step on its own?

What do these tools not solve?

Isolation moves conflicts to merge time without removing them. Willison warns against splitting work over "dozens of different specialist subagents": their main value is keeping the root context free. Galactic and Binex were one-person projects when this was written, in March 2026, so check how actively they are maintained before a team depends on them.