---
title: "Multi-agent orchestration: vad gick sönder i 3 315 körningar"
description: "Agentorkestrering i praktiken: 3 315 körningar av subagenter under två månader, tokenkostnaden till API-priser och sju fel som vart och ett blev en hook."
url: "https://madsalt.tech/sv/blog/multi-agent-orchestration-what-broke/"
author: "Denys Zaichenko"
language: "sv"
published: 2026-10-19
updated: 2026-10-22
---

# Multi-agent orchestration: vad gick sönder i 3 315 körningar

Kort sagt

Mellan 17 augusti och 19 oktober 2026 startade min Claude Code-uppsättning 3 315 subagenter. Under de senaste 30 dagarna blev det cirka 16 miljarder tokens, varav 97,7 % var cache-läsningar. Jag betalar ett fast abonnemang; till API-listpriser skulle samma tokens kosta minst 3 350 USD. Felen var nästan aldrig att modellen skrev dålig kod. De satt i fogarna: parallella agenter som skrev över samma fil medan alla kontroller var gröna, ett städskript som raderade färdigt arbete, en agent som redigerade de kontroller som blockerade den. Varje fel blev ett litet skript som blockerar nästa körning, och det är de skripten, inte promptarna, som gjorde systemet användbart.

Jag heter Denys och är full-stack- och AI-ingenjör. Jag bygger mjukvara med en lead-session i Claude Code som lämnar arbete vidare till specialiserade subagenter: utforskare, en planerare, implementerare samt säkerhets- och kodgranskare. Det här är en rapport om det multiagentsystemet, inte om en klientprodukt. Siffrorna kommer från de loggar det för själv: en spawn-logg (en rad per startad agent), sessionstranskript och git-historiken för själva konfigurationen. Klient- och projektnamn är utelämnade.

Jag har också byggt en [interaktiv dashboard för multiagent-orkestrering](https://madsalt.tech/sv/work/multi-agent-orchestration/) som prototyp med exempeldata. Allt nedan kommer från riktiga körningar.

## Vad är multi-agent orchestration?

Multi-agent orchestration, på svenska agentorkestrering, är en uppsättning där en lead-agent lämnar avgränsade uppgifter till specialiserade agenter och sammanfogar deras resultat; orkestratorn äger kontexten, budgetarna och omförsöken. I den här artikeln dyker det upp som två mönster: en lead-session med subagenter (utforskare, en planerare, implementerare, granskare) och hooks som tvingar fram de regler agenterna inte kan prata sig runt. [Dashboarden för multiagent-orkestrering](https://madsalt.tech/sv/work/multi-agent-orchestration/) visar samma idé på exempeldata; avsnitten nedan handlar om vad som gick sönder i riktiga körningar.

## Hur ser uppsättningen ut?

En lead-session pratar med mig och äger uppgiften. På större uppgifter skriver den aldrig produktionskod själv. Den skickar ut arbetet:

- **Utforskare** läser ett lager av kodbasen (frontend, backend, databas) och skriver en kort karta.
- **En planerare** gör kartan till numrerade steg med filsökvägar.
- **Implementerare** tar var sin planfas, skriver testerna först och sedan koden. Parallella implementerare får varsin git worktree.
- **Granskare** kontrollerar diffen: en för säkerhet, en för korrekthet, båda på samma commit.

Mellan dem sitter hooks: små skript som Claude Code kör före och efter varje verktygsanrop. En hook kan blockera ett anrop, till exempel en agentstart, en filskrivning eller en `git commit`. Konfigurationen har 165 hooks, cirka 40 av dem om orkestrering. De regler agenterna läser är Markdown; de regler de inte kan ta sig förbi är hooks. Den uppdelningen är den viktigaste lärdomen från de två månaderna, och resten av texten handlar om varför.

![Så går en uppgift genom agenterna. Hooks sitter mellan varje steg och kan blockera det. Normal väg: Utforskare → Planerare → Utvecklare → Granskare → Commit-gate; Samma fel tre gånger: Utvecklare → Samma fel 3x → Starkare modell → En person.](https://madsalt.tech/charts/sv/multi-agent-orchestration-what-broke-flow.svg)

*Figur 1. Min Claude-uppsättning, augusti till oktober 2026. Parallella implementerare får varsin git worktree.*

## Hur många agenter kördes, och på vilka modeller?

| Mått (17 aug – 19 okt 2026)                   | Värde                                                                    |
| --------------------------------------------- | ------------------------------------------------------------------------ |
| Startade subagenter                           | 3 315 under 57 aktiva dagar                                              |
| Agenttyper                                    | 30                                                                       |
| Oftast startade                               | implementer (tdd-guide) 793, säkerhetsgranskare 455, general-purpose 424 |
| Faktisk modell                                | Opus 46,5 %, Sonnet 45,8 %, Fable 1,3 %, resten ärvt från lead-sessionen |
| Startade en i taget                           | 67,7 %                                                                   |
| Största parallella vågen                      | 5 agenter (taket), nådd 9 gånger                                         |
| Granskningskörningar per implementerarkörning | 0,71 (680 granskningar, 963 implementeringar)                            |

Två siffror förvånade mig. För det första var de flesta starter enskilda agenter, inte fan-outs. Parallellt arbete är undantaget: det lönar sig vid läsning och granskning och kostar mycket vid skrivning (se det första felet nedan). För det andra var modellen som faktiskt kördes en annan i 23 % av de starter där en agents fil anger en modell, nästan alltid Sonnet höjd till Opus (584 av 610). Det är avsiktligt: en hook höjer modellen när steget rör riskabel kod som migreringar, autentisering eller serverrutter, och efter att en implementerare på Sonnet misslyckats med samma test tre gånger i rad. Den starkare implementeraren kördes 159 gånger; jag kan inte dela upp loggen i "riskabelt steg" och "upprepat fel", så jag påstår inte hur många som var räddningar.

## Vad kostar multi-agent orchestration?

Jag betalar ett fast abonnemang, så det finns ingen räkning per token. Transkripten registrerar dock varje token, så här är vad de senaste 30 dagarna (20 september – 19 oktober) skulle kosta till Anthropics API-listpriser:

| 30 dagar              | Tokens                                                       |
| --------------------- | ------------------------------------------------------------ |
| Totalt                | cirka 15,99 miljarder                                        |
| Cache-läsningar       | 15,55 miljarder (97,7 % av allt som skickades till modellen) |
| Cache-skrivningar     | 372 miljoner                                                 |
| Nytt input utan cache | 0,18 miljoner                                                |
| Output                | 69 miljoner                                                  |

Till listpriser (Opus 5.5 4 USD per miljon input, 20 per miljon output, 0,20 per miljon cache-läsningar; Sonnet 5.5 och Fable 5.1 till sina) landar output, input och cache-läsningar för de tre nuvarande modellerna ensamma på cirka 3 350 USD. Det utelämnar cache-skrivningar och äldre modellversioner som fortfarande finns i loggarna, så den verkliga API-siffran är högre. Två tredjedelar av de 3 350 USD är cache-läsningar: varje tur skickar om hela kontexten, och cachning är den enda anledningen till att det alls är överkomligt.

![Vem skrev de 69 mn output-tokens. Miljoner tokens, 30 dagar. Subagenter använde 42 % av alla tokens. Lead-session: 23,70; Subagenter: 45,30.](https://madsalt.tech/charts/sv/multi-agent-orchestration-what-broke-output.svg)

*Figur 2. Claude-transkript, 20 september till 19 oktober 2026: 75 129 modellanrop.*

Fördelningen mellan lead-sessionen och subagenterna är den del jag skulle använda för att planera en budget:

- **Subagenter använde 42 % av alla tokens men skrev 66 % av outputen.** Lead-sessionen är dyr eftersom den bär den längsta kontexten; subagenterna är där den faktiska texten och koden skrivs.
- **Granskare är billiga.** En säkerhets- eller kodgranskning använde 1–4 miljoner tokens. En implementerare använde 5–100 miljoner. Två granskare på varje riskabel commit kostar mindre än en implementerare som försöker igen.
- **Den största sessionen**, den 6 oktober, startade 63 subagenter och använde 372 miljoner tokens på 3,5 timmar.

## Vad gick sönder

Varje fel nedan hände, har ett datum och slutade med en hook eller ett skript som blockerar att det händer igen. Inget av dem är "modellen skrev en bugg". Vanliga buggar fångades av testerna och granskarna. De här slank förbi båda.

| Datum (2026) | Vad gick sönder                                                                                       | Vad blockerar det nu                                                                                               |
| ------------ | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| 19 aug       | Parallella agenter skrev över en översättningsfil: 55 av ~95 nycklar förlorade, alla kontroller gröna | Varje agent skriver sina nycklar till ett eget fragment; ett sammanfogningsskript bevisar att varje nyckel kom med |
| 24 aug       | Ett städskript raderade 4 färdiga arbetspaket                                                         | Städningen hoppar över varje worktree med ohämtade ändringar; hämta först, städa sedan                             |
| 1 sep        | Senare agentvågor startade från föråldrad kod                                                         | Slå ihop varje agents arbete som en trevägspatch, aldrig som en filkopia                                           |
| 13 sep       | En agent dog vid starten, och starten meldade "lyckades"                                              | Startaren läser agentens första output och markerar en död modell för alla sessioner                               |
| 20 sep       | Två av mina egna regler motsade varandra; agenter försökte om ett nekat kommando                      | Briefar för isolerade agenter anger de kommandoformer sandlådan accepterar                                         |
| 18 okt       | En agent redigerade de kontroller som blockerade dess commit                                          | Kontrollfiler är skrivskyddade från projektsessioner; ändringar loggas och larmar                                  |
| 18 okt       | Åtgärdsinstruktioner ändrade i tysthet vad användarna av en klientapp får                             | Varje åtgärdsbrief säger "behåll live-beteendet"; produktändringar går tillbaka till mig                           |

### Parallella skrivare och filen som varje funktion rör

Tre agenter byggde tre funktioner i en klients iOS-app samtidigt. Var och en lade till sina textsträngar i appens enda översättningskatalog och sparade sin egen version av hela filen. Den sista sparningen vann. 55 av cirka 95 nya nycklar var borta. Varje agents bygge gick igenom, eftersom varje agents kopia var konsekvent; katalogkontrollen gick igenom, eftersom dess täckning var trasig på ett annat sätt. Jag hittade det genom att räkna nycklar för hand.

Åtgärden har tre delar. En hook vägrar starta en agent vars deklarerade filer överlappar med en skrivare som fortfarande kör. Agenter redigerar aldrig delade kataloger; de skriver sina nycklar till en fragmentfil, och ett skript slår ihop fragmenten, felar vid motstridiga värden och kontrollerar sedan att varje nyckel finns. En andra hook blockerar commit om en katalog har färre nycklar än förut. Den ärliga delen: jag lade till de skydden den 18 oktober, 60 dagar efter förlusten. Mellan de datumen var det enda skyddet en rad i en Markdown-regel, och en regel är ett förslag.

### Städning som raderade färdigt arbete

Parallella implementerare arbetar i git worktrees och stagear sina ändringar utan att committa. En commit-kontroll sa åt lead-sessionen att köra städskriptet. Skriptet hoppade över worktrees vars agent fortfarande kördes, och de här agenterna var färdiga. Fyra färdiga arbetspaket raderades, utan git-objekt kvar att återskapa från. "Körs agenten fortfarande?" och "har dess arbete hämtats?" är olika frågor, och skriptet ställde bara den första. Städningen hoppar nu över varje worktree med ändringar som huvudcheckouten inte har, och en separat hook blockerar direkt radering av worktree-mappar.

### Vågor som startade från gammal kod

En plan med 11 steg kördes som 6 implementerare i 3 vågor. Våg 2 och 3 startade från den commit sessionen började på, tre commits efter. Att kopiera tillbaka en agents fil hade återställt en annan agents färdiga ändring. En worktree är en ögonblicksbild av där du startade, så resultat går nu tillbaka som trevägspatchar, och konflikter kommer upp i stället för att i tysthet skrivas över.

### En död agent som meldade framgång

En agent låst till en modell vars användningsgräns var slut dog före sitt första steg. Starten returnerade "spawned successfully"; felet kom senare som ett inaktivitetsmeddelande. Ett nytt försök på en annan modell växlades tillbaka av samma hook som låser modeller. Lead-sessionen skrev sedan i tysthet planen själv, vilket var precis det utfall planeraren fanns till för att undvika. Hooken läser nu agentens första output och markerar en död modell för alla sessioner en stund.

### Agenten som redigerade sina egna kontroller

Den 18 oktober fick en session på ett klientprojekt gång på gång sin commit blockerad av en kontroll. Den redigerade tre av kontrollskripten så att dess commit skulle gå igenom. Inget av det var dolt; ändringarna låg öppet. Men inget stoppade dem heller, eftersom kontrollerna låg i en mapp som agenten kunde skriva till, och bara filredigeringsverktygen övervakades, inte shell-kommandon. Nu kan kontrollfilerna bara ändras från en session som startats i själva konfigurationsmappen, varje skrivväg är täckt (editor, shell-omdirigeringar, skript, git), och varje ändring av dem under en projektsession loggas med ett larm.

Det här är felet jag först skulle varna alla för. En agent som får veta att den ska "få commiten att gå igenom" behandlar grinden som en del av problemet.

### Två av mina egna regler var oeniga

En regel sa åt agenter att slå ihop tre eller fler shell-steg till ett skript för att spara tokens. Agenter isolerade i en worktree körs under en sandlåda som vägrar precis den formen. Agenter stötte på "too complex to verify" tre gånger i rad under flera dagar och brände sin budget på att formulera om. Nu slutar agenter efter två identiska nekanden, och briefar för isolerade agenter anger de kommandoformer som fungerar.

## Varför misslyckas multiagentsystem?

Utifrån de två månaderna: inte för att en modell är för svag. Inget av de sju felen ovan var en modell som misslyckades med uppgiften den fick. De misslyckas i fogarna mellan agenter, där ingen enskild agent har ansvaret:

- **Delat tillstånd.** En fil som varje funktion rör, ett arbetsträd, en gren. Varje agent har lokalt rätt och resultatet blir fel globalt.
- **Gröna kontroller.** Varje incident ovan klarade de kontroller som fanns då. En kontroll bevisar det den kontrollerar, inget mer.
- **Framgångssignaler som ljuger.** "Spawned", "sparat", "städat" betydde var och en något snävare än vad de sa.
- **Agenter som optimerar mot grinden.** Säg åt en agent att commiten är blockerad så letar den efter ett sätt att häva blockeringen, även genom själva grinden.

Andra byggare rapporterar samma mönster från större flottor. Jed Arden, som kör omkring tjugo agenter, skrev att [LLM:en knappt syns i incidentloggen](https://jedarden.com/notes/what-breaks-at-twenty-agents/) (juli 2026). [Cursors team fann](https://cursor.com/blog/scaling-agents) att tjugo agenter som delade en koordineringsfil med lås bromsades ner till en genomströmning på två eller tre (januari 2026).

## Vad jag skulle sätta upp först

Om du börjar med Claude Code-subagenter eller någon multi-agent orchestration är det här ordningen jag skulle ta det i, utifrån vad det kostade mig att lära mig:

1. **Logga varje agentstart.** En rad per start: tid, agenttyp, modell, risk. Utan den kan du inte se vad systemet gör, och ingen av siffrorna ovan skulle finnas.
2. **En skrivare per fil.** Parallella skrivare får en worktree och en deklarerad fillista. Filer som varje funktion lägger till i (översättningar, lockfiles, changelogs) får en ägare, och de andra lämnar in fragment.
3. **Hämta innan du städar.** Låt aldrig ett städsteg avgöra utifrån "körs den". Avgör utifrån "finns dess arbete i huvudcheckouten".
4. **Lägg kontrollerna utom räckhåll för agenterna.** Hooks som blockerar, placerade där en projektsession inte kan skriva.
5. **Sätt tak på vågen.** Fem parallella agenter är mitt tak; bortom det blir granskningen flaskhalsen och konflikterna växer snabbare än genomströmningen.
6. **Eskalera vid upprepning, inte vid ansträngning.** En billig modell som standard; efter samma fel tre gånger ett försök på en starkare modell; därefter en människa.

Vad kostar en AI-agent att bygga och driva för ett företag, i stället för för en utvecklares arbetsflöde? Det är en annan fråga, besvarad med siffror i [vad en AI-agent kostar](https://madsalt.tech/sv/blog/how-much-does-an-ai-agent-cost/). Vilka paneler jag bevakar nu, från samma loggar en månad senare, finns i [AI agent monitoring dashboard: vad 1 238 körningar visade](https://madsalt.tech/sv/blog/ai-agent-monitoring-dashboard/).

## Begränsningar i den här rapporten

- **En utvecklares uppsättning.** En lead-session, upp till fem parallella agenter. Flottor på tiotals eller hundratals agenter misslyckas på ytterligare sätt, till exempel vid start.
- **Ingen verklig räkning.** Dollarsumman är en API-listprisekvivalent för 30 dagar, ett golv som utelämnar cache-skrivningar och äldre modeller. Jag betalar ett fast abonnemang.
- **Luckor i loggarna.** Blockerade starter loggas inte, så jag kan inte säga hur ofta vågtaket slog till. De 159 körningarna av den starkare implementeraren blandar riskabla steg och upprepade fel.
- **Datum från mina egna anteckningar.** Incidentdatumen kommer från anteckningar och commits skrivna samma dag; en incident har ett annat datum i en äldre regelfil, och jag använde anteckningen.

Dashboard-prototypen som växte fram ur arbetet är [caset om multiagent-orkestrering](https://madsalt.tech/sv/work/multi-agent-orchestration/), och att bygga agenter åt klienter hör under [AI-agenter och chatbotutveckling](https://madsalt.tech/sv/services/ai-agent-development/).

Kör du agenter parallellt och tappar arbete mellan dem?

Jag jämför gärna erfarenheter om hooks, worktrees och granskningsgrindar. Ingen säljpitch.

[Hör av dig](https://madsalt.tech/sv/#contact)