Hoe bouw je betrouwbare multi-agentsystemen?

Geef elke agent een eigen werkplek, leg de workflow vast als expliciete stappen en houd de context van de hoofdagent schoon door zijtaken aan subagents te geven. In maart 2026 dekten drie open bronnen die onderdelen af: Galactic, een macOS-app die parallelle codeeragents elk een eigen Git-worktree en netwerkadres geeft; Binex, een nieuwe open-source runtime die agent-workflows als graaf uitvoert en elke stap vastlegt; en het hoofdstuk over subagents in de gids van Simon Willison. Alle drie verpakken ze werkwijzen die ontwikkelaars al gebruikten, en Binex was twee weken oud.

Waarom zitten parallelle agents elkaar in de weg?

Een multi-agentsysteem belooft snelheid: meerdere agents werken tegelijk aan losse delen van een probleem. De naïeve opzet start een paar codeeragents in één checkout van dezelfde repository, elk op een eigen issue. Stel dat twee ervan hetzelfde bestand aanraken:

• Agent A leest /src/config.ts, past het aan en schrijft het terug.
• Agent B las hetzelfde bestand een moment eerder en schrijft zijn eigen versie weg.
• De wijziging van A is weg, en geen van beide agents weet het.

File locks helpen daartegen, maar andere conflicten blijven:

• Semantische conflicten: twee agents passen dezelfde functie aan met een ander doel, de een voor nauwkeurigheid en de ander voor snelheid.
• Strijd om resources: beide willen dezelfde poort voor de dev-server, dezelfde GPU of dezelfde databaseverbinding.
• Uiteenlopende conclusies: elke agent redeneert in zijn eigen context, en niemand brengt de uitkomsten samen.

De eenvoudigste veilige opzet laat agents na elkaar draaien. Dat werkt, en het kost precies de snelheid die parallelle agents aantrekkelijk maakte.

Hoe houden Git-worktrees codeeragents uit elkaars vaarwater?

Een Git-worktree is een extra werkmap die aan dezelfde repository hangt. Volgens de Git-documentatie kan een repository meerdere werkmappen hebben, zodat je meer dan één branch tegelijk kunt uitchecken:

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

Elke agent werkt dan in een eigen map op een eigen branch, en het werk komt weer samen via een merge of pull request. Alle worktrees delen één repository en één geschiedenis.

Galactic verpakt dit in een desktop-app voor macOS (open source, AGPL-3.0, sinds november 2025 gebouwd door één ontwikkelaar). De app maakt met één klik een worktree aan en lost het poortprobleem op met netwerkisolatie: elke omgeving krijgt een eigen loopback-adres, zodat dezelfde stack meerdere keren op dezelfde poort kan draaien. Schematisch:

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 draait ook een MCP-server die actieve agent-sessies uit Cursor, VS Code, Claude en Codex op één plek toont. Worktrees voorkomen dat agents elkaars bestanden overschrijven. Onverenigbare wijzigingen voorkomen ze niet: die komen nu als mergeconflict boven, waar je ze ziet.

Hoe maakt Binex een workflow expliciet?

Binex (MIT-licentie, op 9 maart 2026 begonnen door één ontwikkelaar) is een lokale runtime voor agent-workflows. Je beschrijft de workflow als gerichte acyclische graaf (DAG) in YAML. Elke node noemt zijn agent, en dat kan een taalmodel zijn, een lokaal script, een menselijke stap of een externe agent, plus zijn invoer, uitvoer en afhankelijkheden. Een pipeline voor een bugfix met een menselijke goedkeuringsstap ziet er in het formaat van Binex zo uit:

1
name: bugfix-pipeline
2
nodes:
3
  researcher:
4
    agent: "llm://gemini/gemini-2.5-flash"
5
    system_prompt: "Onderzoek de bug in /src/validators.ts"
6
    inputs: {}
7
    outputs: [analysis]
8
  fixer:
9
    agent: "llm://gemini/gemini-2.5-flash"
10
    system_prompt: "Stel een fix voor op basis van de analyse"
11
    inputs:
12
      analysis: "${researcher.analysis}"
13
    outputs: [patch]
14
    depends_on: [researcher]
15
  review:
16
    agent: "human://approve"
17
    system_prompt: "Keur de voorgestelde fix goed of af"
18
    inputs:
19
      patch: "${fixer.patch}"
20
    outputs: [decision]
21
    depends_on: [fixer]

Binex bewaart de invoer, uitvoer, prompts en kosten van elke run in een lokale SQLite-database. Vanaf de commandline start je een workflow en bekijk je hem achteraf:

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

debug toont de invoer en uitvoer per node, trace de tijdlijn van de run. Andere commando's vergelijken twee runs (diff, bisect) of draaien één node opnieuw met een ander model of een andere prompt (replay). Nodes kunnen vertakken op eerdere uitkomsten met een when-voorwaarde, en Binex kan ook componenten van LangChain, CrewAI en AutoGen als node draaien.

Wanneer geeft een agent werk door aan een subagent?

Een contextvenster raakt vol. Simon Willison schrijft in zijn hoofdstuk over subagents (17 maart 2026) dat de limieten meestal rond 1.000.000 tokens ophouden en dat benchmarks vaak betere kwaliteit melden onder de 200.000. Een subagent is zijn antwoord: de agent stuurt een verse kopie van zichzelf op een omschreven doel af, met een nieuw contextvenster dat met een verse prompt begint.

Claude Code doet dat standaard. Voordat het aan een taak in een bestaande repository begint, draait het een Explore-subagent die de code doorzoekt en een samenvatting teruggeeft. Een voorbeeld van het verloop:

1. De hoofdagent moet weten waar de invoervalidatie zit voordat hij iets verandert.
2. Hij stuurt een subagent op pad met een smalle prompt: zoek de validatiefuncties en geef hun bestanden, signatures en aanroepers terug.
3. De subagent leest wat nodig is in zijn eigen context en levert een korte samenvatting.
4. De hoofdagent gaat verder met zijn eigen context intact.

Subagents kunnen ook parallel werken aan bestanden die niet van elkaar afhangen, en ze kunnen een sneller, goedkoper model gebruiken zoals Claude Haiku. Willison noemt daarnaast gespecialiseerde subagents: een code-reviewer, een testrunner die lange testuitvoer voor de hoofdagent verborgen houdt, en een debugger. OpenAI maakte subagents op 16 maart 2026 algemeen beschikbaar in Codex, met standaardagents "explorer", "worker" en "default".

Welke tools geven agents veiliger toegang tot API's en het web?

Composio centraliseert tool-integratie en authenticatie, zodat niet elke agent zelf API-sleutels en OAuth-flows hoeft te regelen. Met de Python-SDK haal je de tools van een toolkit voor een gebruiker op en geef je ze door aan je 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 een headless browser die vanaf nul in Zig is geschreven voor agents en automatisering (AGPL-3.0). Hij spreekt het Chrome DevTools Protocol (CDP), zodat Playwright en Puppeteer hem kunnen aansturen. In maart 2026 kwamen er eigen commando's bij in een "LP"-domein: LP.getMarkdown op 5 maart, dat de gerenderde pagina als Markdown teruggeeft met volgens Lightpanda tot 80% minder tokens per pagina, en op 11 maart LP.getSemanticTree, LP.getInteractiveElements en LP.getStructuredData, plus een ingebouwde MCP-server. Met 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' });

Hoe passen de onderdelen in elkaar?

Zie een betrouwbare opzet als drie lagen:

• Workflow: elke stap en overdracht staat in een bestand, en elke node logt zijn invoer, uitvoer en kosten (zoals in Binex).
• Isolatie: worktrees voor werk aan bestanden, subagents voor verkenning en andere zijtaken die veel tokens kosten.
• Tooltoegang: authenticatie op één plek (zoals bij Composio), en gestructureerde paginadata zoals Markdown of een semantische boom in plaats van ruwe HTML.

Wat controleer je voordat je agents parallel laat draaien?

• Staat elke overdracht tussen agents in een workflowbestand, of hangt die af van een chatgeschiedenis?
• Heeft elke agent een eigen worktree, branch of subagent-context?
• Lopen tool-aanroepen via één plek die de authenticatie regelt?
• Worden de invoer, uitvoer en kosten van elke stap vastgelegd?
• Is er een menselijke goedkeuringsstap voor wijzigingen die moeilijk terug te draaien zijn?
• Kun je een mislukte stap los opnieuw draaien?

Wat lossen deze tools niet op?

Isolatie verschuift conflicten naar het moment van mergen, zonder ze weg te nemen. Willison waarschuwt ervoor werk te verdelen over tientallen gespecialiseerde subagents: hun grootste waarde is dat de hoofdcontext vrij blijft. Galactic en Binex waren eenmansprojecten toen dit werd geschreven, in maart 2026, dus kijk hoe actief ze worden onderhouden voordat een team ervan afhangt.