För att köra kodningsagenter parallellt ger du varje agent ett eget git worktree och en egen gren, matar agenterna från en kö av planer som en människa redan har granskat, kör tester och linting inuti varje worktree innan någon läser diffen, samt loggar vad varje plan kostar. De flesta team når denna arkitektur genom att passera tre tidigare mönster: en ensam agent i ett chattfönster, en agent per gren startad manuellt och en kö med worker-agenter. Varje mönster löser ett problem och blottar nästa. Den här guiden går igenom de fyra mönstren, vad som fallerar i varje steg och de sex saker en orkestrerare måste äga.

De fyra mönstren

Steve Yegges "8 Levels of AI-Assisted Development" (2025) är en användbar referensram. Den underliggande loopen – resonera kring ett steg, agera, observera resultatet, upprepa – är den som formaliserats i Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, och varje mönster nedan är ett svar på vem som övervakar den loopen. De flesta team befinner sig i skrivande stund på nivå 2 till 3: en utvecklare instruerar en agent, granskar resultatet och committar. Orkestrering med parallella agenter, beständigt minne och granskningsgrindar är nivå 8.

Mönster 1: En ensam agent i ett chattfönster

En utvecklare öppnar en terminal eller en panel i sin utvecklingsmiljö (IDE), beskriver en uppgift och ser hur agenten redigerar filer i arbetskatalogen. Genomströmningen är en uppgift per utvecklare åt gången, eftersom agenten och utvecklaren delar samma checkout. Startas en andra uppgift innan den första är klar hamnar båda uppsättningarna ändringar i samma filträd, och diffen förlorar all betydelse.

Mönster 2: En agent per gren, startad manuellt

Nästa steg är att ge varje uppgift en egen gren och en egen checkout. Git worktrees gör detta resurssnålt: ett gemensamt objektarkiv, flera separata arbetskataloger.

# Från huvudkatalogen:
git worktree add ../feature-search-button -b feature/search-button
cd ../feature-search-button
claude "Add a search button to the sidebar. Run the tests when done."

En utvecklare kan nu köra två eller tre agenter samtidigt, var och en i sin egen katalog. Det som fallerar är bokföringen: Ingen dokumenterar vilket worktree som hör till vilken uppgift, och promptarna försvinner i terminalens historik. Om två agenter riktas mot samma filer uppstår merge-konflikter som upptäcks först vid sammanslagningen.

Mönster 3: En kö med worker-agenter i isolerade worktrees

När teamet kör fler än en handfull agenter blir det manuella startsteget den trånga sektorn. Lösningen är en kö: uppgifter läggs in, worker-processer plockar upp dem, skapar ett worktree, kör agenten, pushar en gren och öppnar en pull request. Ramverk för multi-agentforskning som AutoGen formaliserar exakt detta upplägg med workers och köer.

Att ta bort människan från startsteget i varje uppgift är dock platsen där nästa problem uppstår. Ingenting granskar uppgiften innan agenten börjar, så illa specificerade uppgifter bränner tokens på pull requests som ingen vill ha. Ingenting kontrollerar resultatet innan pull requesten skapas, vilket gör mänskliga granskare till flaskhalsen. Och eftersom kön körs obevakad ackumuleras kostnader i det dolda.

Mönster 4: En planlivscykel med mänskliga kontrollpunkter

Det sista mönstret lägger till två mänskliga kontrollpunkter och ett automatiserat verifieringssteg. En uppgift formuleras som en skriftlig plan. En människa läser planen innan någon kod skrivs. Agenterna körs i isolerade worktrees. Tester, linting och en diff-sammanfattning körs inuti worktreen – samma princip som kontinuerlig integration, tillämpad per agent i stället för per utvecklare. En människa granskar diffen. Först därefter öppnas en pull request.

Ivy kallar detta mönster för en mjukvarufabrik (software factory): ett repeterbart arbetsflöde där varje förändring passerar samma faser och samma två godkännanden. Se Vad är en mjukvarufabrik för hela definitionen.

Vad som fallerar i varje steg

Mönster	Vad det löser	Vad som fallerar härnäst
Ensam agent i chatt	Inget ännu; detta är utgångsläget	En uppgift per utvecklare; delad arbetskatalog
En agent per gren, manuellt	Parallella uppgifter utan katalogkrockar	Förlorad kontext, ologgade promptar, konflikter först vid merge
Kö med workers	Manuellt startsteg tas bort	Ogranskade indata och utdata, okontrollerade kostnader
Planlivscykel med kontrollpunkter	Minimerar spilld körning och ogranskade diffar	Kräver verktyg för kö, isolering, verifiering, kostnad och minne

Vad en orkestrerare måste hantera

En orkestrerare är programvaran som driver mönster 4. Den har sex ansvarsområden; om något saknas måste det göras manuellt och blir omedelbart flaskhalsen igen:

Kö. Planer väntar i en definierad ordning med ett tydligt tillstånd: utkast (draft), godkänd (approved), körs (executing), verifieras (verifying), under granskning (in review), mergad (merged). Tillståndet måste gå att se utan att öppna en terminal.
Isolering. Varje aktiv plan får ett eget worktree och en egen gren. Huvudgrenen (main) tar aldrig emot ändringar från agenter direkt. Git worktrees för parallella AI-agenter förklarar varför worktrees slår delade arbetskataloger och containrar.
Verifiering. Tester, linting, typkontroller och en diff-sammanfattning körs inuti worktreen efter körning och innan en människa ser koden. Vid fel skickas uppgiften tillbaka till agenten med felloggarna bifogade.
Granskning. Exakt två kontrollpunkter, planen och diffen, var och en med en uttrycklig åtgärd för att godkänna eller avvisa. Avvisning i planfasen kostar inga tokens i kodgenerering. Avvisning i difffasen kostar en enskild körning.
Kostnadsredovisning. Tokens och kostnader bokförs per plan och per jobb, så att teamet vet vad en mergad ändring kostade och vilka planer som avbröts efter förbrukade resurser.
Minne. Det agenten lärde sig under en plan måste vara tillgängligt i nästa; annars börjar varje plan från noll och upprepar samma misstag.

Hur Ivy Tendril implementerar detta

Ivy Tendril är en lokal skrivbordsapplikation (local-first) för macOS, Windows och Linux som kör mönster 4 för valfri CLI-kodningsagent. Den kan också köras headless via tendril --web.

Kö: Vyn Plans hanterar alla planer med deras livscykeltillstånd. Drafts, Icebox och Recommendations samlar arbete som ännu inte godkänts. Planer kan skapas från GitHub-ärenden och jam.dev-buggrapporter via webhooks, eller genom MCP-servern, REST-API:et och CLI.
Isolering: När körningen startar skapar Tendril ett git worktree och en gren för planen. Många planer körs samtidigt, var och en i sin egen miljö. Efter merge raderar Tendril worktreen. Se git worktrees för parallella AI-agenter.
Verifiering: Review-appen presenterar tester, linting och diff som flikar för varje plan. Pro-kunder kan importera verifieringsresultat direkt från sin CI.
Granskning: Planens kontrollpunkt låter granskaren använda funktionerna Expand, Split eller Update på ett utkast, eller kommentera direkt så att planen skrivs om. Diffens kontrollpunkt sker efter verifiering. Ingen pull request öppnas utan båda stegen.
Kostnadsredovisning: Tokens och kostnader spåras per plan och jobb, och instrumentpanelen (Dashboard) visar nyckeltal och trendgrafer.
Minne: Varje fas drivs av en promptware-enhet med en Program.md med instruktioner som utvecklas över tid, en Memory/-katalog med beständiga erfarenheter, avgränsade Tools/ och Logs/. Inbyggda enheter inkluderar CreatePlan, ExpandPlan, ExecutePlan, UpdatePlan, SplitPlan, CreatePr och CreateIssue. Se promptware.

Tendril är helt agentoberoende. Det stöder Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode och alla andra terminalbaserade agenter, och agent eller modell kan ändras per plan. Koden stannar på datorn; de enda externa anropen går till det LLM-API du konfigurerar och till GitHub.

Ivy rapporterar att deras eget team gick från ungefär 10 till över 100 pull requests per dag efter att ha infört detta arbetsflöde.

Så här kommer du igång

Installera Tendril: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh på macOS eller Linux, irm https://cdn.ivy.app/install-tendril.ps1 | iex på Windows. Detaljer finns under installation.
Öppna ett arkiv i appen och lägg till en API-nyckel för den modelloperatör du redan använder.
Skapa en plan från ett befintligt ärende, granska utkastet, starta körningen och läs diffen i Review-appen.
När den första planen har mergats skapar du tre planer samtidigt och ser hur de körs parallellt.

Tendril är gratis och har tillgänglig källkod under Functional Source License; funktioner för team, SSO, drift på egen infrastruktur (on-prem) och CI-verifieringsimport ingår i planerna Pro ($59 per användare/månad) och Enterprise.

Vanliga frågor

Behöver jag containrar för att köra agenter parallellt?

Nej. Git worktrees ger varje agent en egen arbetskatalog och gren samtidigt som de delar ett gemensamt objektarkiv. Containrar ger körningsisolering (runtime isolation), vilket behövs om agenter installerar systempaket eller binder nätverksportar; de flesta kodningsuppgifter kräver inte det.

Hur många agenter kan köras samtidigt?

Begränsningen brukar vara modelloperatörens anropsgränser (rate limits) och datorns kapacitet att köra tester samtidigt, inte orkestreraren. Börja med tre till fem parallella planer och höj antalet så länge verifieringen slutförs utan fördröjning.

Vad händer när två planer rör samma fil?

Den plan som mergas sist kommer att få en konflikt på sin gren. Lösningen sker på planstadiet: dela upp eller sekvensera planer som berör samma moduler före körning, vilket är precis vad Split-funktionen i Tendril är utformad för.

Kom igång med Ivy Tendril

Är du redo för parallell agentorkestrering på utvecklarnivå?

Utforska källkoden: Upptäck Ivy Tendril på GitHub (Open Source).
Läs dokumentationen: Hitta integrationsguider på tendril.ivy.app.
Boka arkitekturgenomgång: Kontakta renco@ivy.app för en 30-minuters teknisk konsultation.

Mönster för agentorkestrering: Så kör du kodningsagenter parallellt