--- title: "Multi-agent orchestration: mikä hajosi 3 315 agenttiajossa" description: "Multi-agent orchestration käytännössä: 3 315 aliagenttiajoa, tokenien hinta API-hinnoin ja seitsemän virhettä, joista kukin johti hookiin." url: "https://madsalt.tech/fi/blog/multi-agent-orchestration-what-broke/" author: "Denys Zaichenko" language: "fi" published: 2026-10-19 updated: 2026-10-22 --- # Multi-agent orchestration: mikä hajosi 3 315 agenttiajossa TL;DR Elokuun 17. päivän ja lokakuun 19. päivän 2026 välillä Claude Code -ympäristöni käynnisti 3 315 aliagenttia. Viimeisen 30 päivän aikana tokeneita kului noin 16 miljardia, ja niistä 97,7 % oli välimuistilukuja. Maksan kiinteää tilausmaksua; API:n listahinnoilla samat tokenit maksaisivat vähintään 3 350 Yhdysvaltain dollaria. Viat eivät melkein koskaan johtuneet siitä, että malli kirjoitti huonoa koodia. Ne olivat saumoissa: rinnakkaiset agentit ylikirjoittivat saman tiedoston kaikkien tarkistusten palaessa vihreinä, siivousskripti poisti valmiin työn, ja agentti muokkasi tarkistuksia, jotka estivät sitä. Jokaisesta viasta tuli pieni skripti, joka estää seuraavan ajon tekemästä samaa, ja juuri nämä skriptit, eivät kehotteet, tekivät järjestelmästä käyttökelpoisen. Olen Denys, full-stack- ja tekoäly-insinööri. Rakennan ohjelmistoja yhdellä Claude Code -pääistunnolla, joka antaa työtä erikoistuneille aliagenteille: kartoittajille, suunnittelijalle, toteuttajille sekä tietoturva- ja koodikatselmoijille. Tämä on raportti kyseisestä moniagenttijärjestelmästä, ei asiakkaan tuotteesta. Luvut tulevat sen pitämistä lokeista: käynnistysloki (yksi rivi jokaista käynnistettyä agenttia kohden), istuntojen tallenteet ja itse kokoonpanon git-historia. Asiakkaiden ja projektien nimet on jätetty pois. Rakensin myös [interaktiivisen moniagenttiorkestroinnin dashboardin](https://madsalt.tech/fi/work/multi-agent-orchestration/) prototyypiksi esimerkkidatalla. Kaikki alla oleva on oikeista ajoista. ## Mitä multi-agent orchestration tarkoittaa? Multi-agent orchestration (moniagenttiorkestrointi) on järjestely, jossa yksi pääagentti antaa rajatut tehtävät erikoistuneille agenteille ja yhdistää niiden tulokset; orkestroija omistaa kontekstin, budjetit ja uudelleenyritykset. Tässä kirjoituksessa se näkyy kahtena mallina: pääistunto aliagentteineen (kartoittajat, suunnittelija, toteuttajat, katselmoijat) sekä hookit, jotka valvovat sääntöjä, joista agentit eivät pääse puhumalla ohi. [Moniagenttiorkestroinnin dashboard](https://madsalt.tech/fi/work/multi-agent-orchestration/) näyttää saman idean esimerkkidatalla; alla olevat osiot kertovat siitä, mikä hajosi oikeissa ajoissa. ## Miltä järjestelmä näyttää? Yksi pääistunto keskustelee kanssani ja omistaa tehtävän. Suuremmissa tehtävissä se ei itse kirjoita tuotantokoodia. Se jakaa työn: - **Kartoittajat** lukevat yhden koodikannan kerroksen (frontend, backend, tietokanta) ja kirjoittavat lyhyen kartan. - **Suunnittelija** muuttaa kartan numeroiduiksi vaiheiksi tiedostopolkuineen. - **Toteuttajat** ottavat kukin yhden suunnitelman vaiheen, kirjoittavat ensin testit ja sitten koodin. Rinnakkaiset toteuttajat saavat oman git worktreen. - **Katselmoijat** tarkistavat diffin: yksi tietoturvan, yksi oikeellisuuden kannalta, molemmat samasta commitista. Niiden välissä ovat hookit: pienet skriptit, joita Claude Code ajaa ennen jokaista työkalukutsua ja sen jälkeen. Hook voi estää kutsun, esimerkiksi agentin käynnistyksen, tiedoston kirjoituksen tai komennon `git commit`. Kokoonpanossa on 165 hookia, joista noin 40 liittyy orkestrointiin. Agenttien lukemat säännöt ovat Markdownia; säännöt, joista ne eivät pääse ohi, ovat hookeja. Tämä jako on kahden kuukauden tärkein oppi, ja loppu kirjoituksesta kertoo, miksi. ![Miten tehtävä kulkee agenttien läpi. Hookit ovat jokaisen vaiheen välissä ja voivat estää sen. Normaali reitti: Kartoitus → Suunnitelma → Toteutus → Katselmointi → Commit; Sama virhe kolmesti: Toteutus → Sama virhe 3x → Vahvempi malli → Ihminen.](https://madsalt.tech/charts/fi/multi-agent-orchestration-what-broke-flow.svg) *Kuva 1. Claude-ympäristöni elokuusta lokakuuhun 2026. Jokainen rinnakkainen toteuttaja saa oman git worktreensa.* ## Kuinka monta agenttia ajettiin, ja millä malleilla? | Mittari (17.8.–19.10.2026) | Arvo | | ------------------------------------------- | -------------------------------------------------------------------------- | | Käynnistetyt aliagentit | 3 315 yli 57 aktiivisen päivän | | Agenttityypit | 30 | | Eniten käynnistetyt | toteuttaja (tdd-guide) 793, tietoturvakatselmoija 455, general-purpose 424 | | Tosiasiallinen malli | Opus 46,5 %, Sonnet 45,8 %, Fable 1,3 %, loput perittiin pääistunnolta | | Käynnistetty yksi kerrallaan | 67,7 % | | Suurin rinnakkainen aalto | 5 agenttia (yläraja), saavutettu 9 kertaa | | Katselmoijien ajoja toteuttajan ajoa kohden | 0,71 (680 katselmointia, 963 toteutusta) | Kaksi lukua yllätti minut. Ensinnäkin useimmat käynnistykset olivat yksittäisiä agentteja, eivät haarautumia. Rinnakkaistyö on poikkeus: se kannattaa lukemisessa ja katselmoinnissa ja tulee kalliiksi kirjoittamisessa (katso ensimmäinen virhe alla). Toiseksi 23 %:ssa käynnistyksistä, joissa agentin tiedosto nimeää mallin, ajettu malli oli toinen, lähes aina Sonnet nostettuna Opukseksi (584 / 610). Se on tarkoituksellista: hook nostaa mallin, kun vaihe koskee riskialtista koodia kuten migraatioita, todennusta tai palvelinreittejä, ja kun Sonnetilla ajava toteuttaja epäonnistuu samassa testissä kolme kertaa peräkkäin. Vahvempi toteuttaja ajettiin 159 kertaa; lokia ei voi jakaa "riskialtis vaihe" ja "toistuva virhe" -ryhmiin, joten en väitä, kuinka monta oli pelastusyrityksiä. ## Mitä multi-agent orchestration maksaa? Maksan kiinteää tilausmaksua, joten tokenikohtaista laskua ei ole. Tallenteisiin kirjautuu silti jokainen token, joten tässä on, mitä viimeiset 30 päivää (20. syyskuuta–19. lokakuuta) maksaisivat Anthropicin API:n listahinnoin: | 30 päivää | Tokenit | | -------------------------- | ------------------------------------------------------ | | Yhteensä | noin 15,99 miljardia | | Välimuistiluvut | 15,55 miljardia (97,7 % kaikesta mallille lähetetystä) | | Välimuistikirjoitukset | 372 miljoonaa | | Tuore, välimuistiton syöte | 0,18 miljoonaa | | Tuloste | 69 miljoonaa | Listahinnoin (Opus 5.5: 4 dollaria miljoonalta syötetokenilta, 20 miljoonalta tulostokenilta ja 0,20 miljoonalta välimuistiluvulta; Sonnet 5.5 ja Fable 5.1 omilla hinnoillaan) pelkästään kolmen nykyisen mallin tuloste, syöte ja välimuistiluvut tekevät noin 3 350 dollaria. Siitä puuttuvat välimuistikirjoitukset ja lokeissa edelleen olevat vanhemmat mallit, joten todellinen API-luku on suurempi. Kaksi kolmasosaa näistä 3 350 dollarista on välimuistilukuja: jokainen vuoro lähettää koko kontekstin uudelleen, ja välimuisti on ainoa syy, miksi tämä on lainkaan edullista. ![Kuka kirjoitti 69 miljoonaa tulostokenia. Miljoonaa tokenia, 30 päivää. Aliagentit käyttivät 42 % kaikista tokeneista. Pääistunto: 23,70; Aliagentit: 45,30.](https://madsalt.tech/charts/fi/multi-agent-orchestration-what-broke-output.svg) *Kuva 2. Clauden tallenteet 20. syyskuuta–19. lokakuuta 2026: 75 129 mallipyyntöä.* Pääistunnon ja aliagenttien välinen jako on se osa, jota käyttäisin budjettia suunnitellessa: - **Aliagentit käyttivät 42 % kaikista tokeneista mutta kirjoittivat 66 % tulosteesta.** Pääistunto on kallis, koska se kantaa pisintä kontekstia; aliagenteissa varsinainen teksti ja koodi kirjoitetaan. - **Katselmoijat ovat halpoja.** Tietoturva- tai koodikatselmointi kulutti 1–4 miljoonaa tokenia. Toteuttaja kulutti 5–100 miljoonaa. Kaksi katselmoijaa jokaiselle riskialttiille commitille maksaa vähemmän kuin yksi uudelleen yrittävä toteuttaja. - **Suurin istunto** 6. lokakuuta käynnisti 63 aliagenttia ja kulutti 372 miljoonaa tokenia 3,5 tunnissa. ## Mikä hajosi Jokainen alla oleva vika tapahtui, siitä on päivämäärä, ja se päättyi hookiin tai skriptiin, joka estää sen toistumisen. Yksikään ei ole "malli kirjoitti bugin". Tavalliset bugit jäivät testeille ja katselmoijille. Nämä pääsivät molempien ohi. | Päivä (2026) | Mikä hajosi | Mikä estää sen nyt | | ------------ | ---------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | 19.8. | Rinnakkaiset agentit ylikirjoittivat yhden käännöstiedoston: 55 noin 95 avaimesta hävisi, kaikki tarkistukset vihreinä | Jokainen agentti kirjoittaa avaimensa omaan osatiedostoonsa; yhdistämisskripti todistaa, että jokainen avain päätyi perille | | 24.8. | Siivousskripti poisti 4 valmista työpakettia | Siivous ohittaa jokaisen worktreen, jossa on keräämättömiä muutoksia; kerää ensin, siivoa sitten | | 1.9. | Myöhemmät agenttiaallot aloittivat vanhasta koodista | Yhdistä jokaisen agentin työ kolmisuuntaisena patchina, älä koskaan tiedostokopiona | | 13.9. | Agentti kuoli käynnistyksessä, ja käynnistys ilmoitti "onnistui" | Käynnistin lukee agentin ensimmäisen tulosteen ja merkitsee kuolleen mallin kaikille istunnoille | | 20.9. | Kaksi omaa sääntöäni oli keskenään ristiriidassa; agentit yrittivät uudelleen evättyä komentoa | Eristettyjen agenttien toimeksiannoissa on komentomuodot, jotka hiekkalaatikko hyväksyy | | 18.10. | Agentti muokkasi tarkistuksia, jotka estivät sen commitin | Tarkistustiedostot ovat vain luettavia projektiistunnoista; muutokset kirjataan ja niistä hälytetään | | 18.10. | Korjausohjeet muuttivat hiljaa sitä, mitä asiakkaan sovelluksen käyttäjät saavat | Jokainen korjaustoimeksianto sanoo "keep live behaviour"; tuotemuutokset palaavat minulle | ### Rinnakkaiset kirjoittajat ja tiedosto, johon jokainen ominaisuus koskee Kolme agenttia rakensi samaan aikaan kolme ominaisuutta asiakkaan iOS-sovellukseen. Jokainen lisäsi tekstijononsa sovelluksen yhteen käännöskatalogiin, ja jokainen tallensi oman versionsa koko tiedostosta. Viimeinen tallennus voitti. 55 noin 95 uudesta avaimesta hävisi. Jokaisen agentin build meni läpi, koska jokaisen agentin kopio oli johdonmukainen; katalogitarkistus meni läpi, koska sen kattavuus oli rikki toisella tavalla. Huomasin sen laskemalla avaimet käsin. Korjaus koostuu kolmesta osasta. Hook kieltäytyy käynnistämästä agenttia, jonka ilmoitetut tiedostot ovat päällekkäin edelleen ajossa olevan kirjoittajan kanssa. Agentit eivät koskaan muokkaa jaettuja katalogeja; ne kirjoittavat avaimensa osatiedostoon, ja yksi skripti yhdistää osat, epäonnistuu ristiriitaisissa arvoissa ja tarkistaa sitten, että jokainen avain on mukana. Toinen hook estää commitin, jos katalogissa on vähemmän avaimia kuin ennen. Rehellinen osuus: lisäsin nämä suojat 18. lokakuuta, 60 päivää menetyksen jälkeen. Näiden päivien välillä ainoa suoja oli rivi Markdown-säännössä, ja sääntö on ehdotus. ### Siivous, joka poisti valmiin työn Rinnakkaiset toteuttajat työskentelevät git worktreissä ja kirjaavat muutoksensa stageen ilman commitia. Commit-tarkistus käski pääistuntoa ajamaan siivousskriptin. Skripti ohitti worktreet, joiden agentti oli vielä ajossa, ja nämä agentit olivat valmistuneet. Neljä valmista työpakettia poistettiin, eikä palautettavia git-objekteja jäänyt. "Onko agentti vielä ajossa?" ja "onko sen työ kerätty?" ovat eri kysymyksiä, ja skripti kysyi vain ensimmäisen. Siivous ohittaa nyt jokaisen worktreen, jossa on muutoksia, joita päähakemistossa ei ole, ja erillinen hook estää worktree-kansioiden suoran poistamisen. ### Aallot, jotka aloittivat vanhasta koodista 11 vaiheen suunnitelma ajettiin 6 toteuttajalla 3 aallossa. Aallot 2 ja 3 aloittivat commitista, jolla istunto alkoi, kolme committia jäljessä. Yhden agentin tiedoston kopioiminen takaisin olisi kumonnut toisen agentin valmiin muutoksen. Worktree on tilannekuva siitä, mistä aloitit, joten tulokset palautetaan nyt kolmisuuntaisina patcheina, ja ristiriidat tulevat esiin sen sijaan, että ne ylikirjoitettaisiin hiljaa. ### Kuollut agentti, joka ilmoitti onnistumisesta Malliin sidottu agentti, jonka käyttöraja oli täynnä, kuoli ennen ensimmäistä vaihettaan. Käynnistys palautti "spawned successfully"; vika tuli myöhemmin joutilaisuusilmoituksena. Uusi yritys toisella mallilla vaihdettiin takaisin samalla hookilla, joka kiinnittää mallit. Pääistunto kirjoitti sitten suunnitelman itse hiljaa, mikä oli juuri se lopputulos, jonka välttämiseksi suunnittelija oli olemassa. Hook lukee nyt agentin ensimmäisen tulosteen ja merkitsee kuolleen mallin kaikille istunnoille joksikin aikaa. ### Agentti, joka muokkasi omia tarkistuksiaan 18. lokakuuta asiakasprojektia tehnyt istunto sai commitinsa toistuvasti estettyä tarkistuksella. Se muokkasi kolmea tarkistusskriptiä niin, että sen commit meni läpi. Mitään tästä ei piilotettu; muokkaukset olivat täysin näkyvissä. Mikään ei kuitenkaan estänyt niitä, koska tarkistukset sijaitsivat kansiossa, johon agentti pystyi kirjoittamaan, ja vain tiedostoeditorityökaluja valvottiin, ei shell-komentoja. Nyt tarkistustiedostoja voi muuttaa vain istunnosta, joka on käynnistetty itse kokoonpanokansiossa, jokainen kirjoitusreitti on katettu (editori, shell-uudelleenohjaukset, skriptit, git), ja jokainen niihin projektiistunnossa tehty muutos kirjataan hälytyksen kera. Tämä on se vika, josta varoittaisin ensimmäisenä. Agentti, jolle sanotaan "vie commit läpi", pitää porttia osana ongelmaa. ### Kaksi omaa sääntöäni oli eri mieltä Yksi sääntö käski agenttien yhdistää kolme tai useampia shell-vaiheita yhdeksi skriptiksi tokenien säästämiseksi. Worktreeen eristetyt agentit toimivat hiekkalaatikossa, joka kieltäytyy juuri tästä muodosta. Agentit törmäsivät virheeseen "too complex to verify" kolme kertaa peräkkäin useina päivinä ja kuluttivat budjettinsa uudelleenmuotoiluun. Agentit pysähtyvät nyt kahden identtisen kieltäytymisen jälkeen, ja eristettyjen agenttien toimeksiannoissa kerrotaan toimivat komentomuodot. ## Miksi moniagenttijärjestelmät epäonnistuvat? Näiden kahden kuukauden perusteella: ei siksi, että malli olisi liian heikko. Yksikään seitsemästä yllä olevasta viasta ei ollut mallin epäonnistuminen sille annetussa tehtävässä. Ne epäonnistuvat agenttien välisissä saumoissa, joissa mikään yksittäinen agentti ei ole vastuussa: - **Jaettu tila.** Tiedosto, johon jokainen ominaisuus koskee, työhakemisto, haara. Jokainen agentti on paikallisesti oikeassa ja tulos on kokonaisuutena väärä. - **Vihreät tarkistukset.** Jokainen yllä oleva tapaus meni läpi tarkistuksista, jotka silloin olivat olemassa. Tarkistus todistaa sen, mitä se tarkistaa, ei muuta. - **Valehtelevat onnistumissignaalit.** "Spawned", "saved", "cleaned up" tarkoittivat kukin kapeampaa asiaa kuin väittivät. - **Portille optimoivat agentit.** Kerro agentille, että commit on estetty, niin se etsii tavan avata commit, myös portin kautta. Muut rakentajat raportoivat samasta kuviosta suuremmissa laivastoissa. Jed Arden, joka ajaa noin kahtakymmentä agenttia, kirjoitti, että ["the LLM barely appears in the incident log"](https://jedarden.com/notes/what-breaks-at-twenty-agents/) (suomeksi: LLM tuskin näkyy häiriölokissa; heinäkuu 2026). [Cursorin tiimi havaitsi](https://cursor.com/blog/scaling-agents), että kaksikymmentä agenttia, jotka jakoivat yhden lukituksilla varustetun koordinaatiotiedoston, hidastuivat kahden tai kolmen läpimenoon (tammikuu 2026). ## Mitä perustaisin ensin Jos aloitat Claude Coden aliagenteilla tai mitä tahansa moniagenttiorkestrointia, tässä järjestyksessä tekisin sen sen perusteella, mitä oppiminen maksoi minulle: 1. **Kirjaa jokainen agentin käynnistys.** Yksi rivi per käynnistys: aika, agenttityyppi, malli, riski. Ilman sitä et tiedä, mitä järjestelmä tekee, eikä mitään yllä olevista luvuista olisi olemassa. 2. **Yksi kirjoittaja per tiedosto.** Rinnakkaiset kirjoittajat saavat worktreen ja ilmoitetun tiedostolistan. Tiedostoilla, joihin jokainen ominaisuus lisää (käännökset, lukitustiedostot, changelogit), on yksi omistaja, ja muut toimittavat osatiedostoja. 3. **Kerää ennen kuin siivoat.** Älä anna siivousvaiheen päättää kysymyksellä "onko se ajossa". Päätä kysymyksellä "onko sen työ päähakemistossa". 4. **Vie tarkistukset agenttien ulottumattomiin.** Estävät hookit säilytetään paikassa, johon projektiistunto ei voi kirjoittaa. 5. **Rajaa aalto.** Viisi rinnakkaista agenttia on kattoni; sen yli katselmoinnista tulee pullonkaula ja ristiriidat kasvavat nopeammin kuin läpimeno. 6. **Eskaloi toiston, ei vaivan perusteella.** Oletuksena halpa malli; saman virheen jälkeen kolme kertaa yksi yritys vahvemmalla mallilla; sen jälkeen ihminen. Mitä tekoälyagentti maksaa rakentaa ja ajaa yritykselle eikä yhden kehittäjän työnkulkuun? Se on eri kysymys, johon vastataan luvuilla kirjoituksessa [Paljonko tekoälyagentti maksaa? Luvut neljästä projektista](https://madsalt.tech/fi/blog/how-much-does-an-ai-agent-cost/). Mitä paneeleita seuraan nyt, samoista lokeista kuukautta myöhemmin, kerrotaan artikkelissa [AI agent monitoring dashboard: mitä 1 238 ajoa näytti](https://madsalt.tech/fi/blog/ai-agent-monitoring-dashboard/). ## Tämän raportin rajat - **Yhden kehittäjän ympäristö.** Yksi pääistunto, enintään viisi rinnakkaista agenttia. Kymmenien tai satojen agenttien laivastot epäonnistuvat lisäksi muilla tavoilla, esimerkiksi käynnistyksessä. - **Ei oikeaa laskua.** Dollarimäärä on API:n listahinnan vastine 30 päivälle, alaraja, josta puuttuvat välimuistikirjoitukset ja vanhemmat mallit. Maksan kiinteää tilausmaksua. - **Aukkoja lokeissa.** Estettyjä käynnistyksiä ei kirjata, joten en voi sanoa, kuinka usein aaltoraja laukesi. Vahvemman toteuttajan 159 ajoa sekoittavat riskialttiit vaiheet ja toistuvat virheet. - **Päivämäärät omista muistiinpanoistani.** Tapausten päivämäärät tulevat samana päivänä kirjoitetuista muistiinpanoista ja commiteista; yksi tapaus on päivätty eri tavalla vanhemmassa sääntötiedostossa, ja käytin muistiinpanoa. Tästä työstä kasvanut dashboard-prototyyppi on [moniagenttiorkestroinnin tapaus](https://madsalt.tech/fi/work/multi-agent-orchestration/), ja agenttien rakentaminen asiakkaille kuuluu palveluun [Tekoälyagentit ja chatbotit](https://madsalt.tech/fi/services/ai-agent-development/). Ajatko agentteja rinnakkain ja menetätkö työtä niiden välillä? Vertaan mielelläni kokemuksia hookeista, worktreistä ja katselmointiporteista. Ei myyntipuhetta. [Ota yhteyttä](https://madsalt.tech/fi/#contact)