Multi-agent Mønstre

Multi-agent er et power-værktøj — ikke default. Her er mønstre, omkostninger, fejltilstande og beslutningsguiden til hvornår du skal bruge det.

6mønstre

5fejltilstande

2-3xsweet spot

4overkill checks

🏗️ Multi-agent Mønstre

Mønster	Beskrivelse	Kompleksitet	Pris	Brug Når
Orchestrator + Workers	Én koordinator, flere workere	Mellem	2-3x	3+ trin, klart definerede opgaver
Router + Specialists	Router dirigerer til specialister	Lav	1.5-2x	Varierede opgavetyper
Planner → Worker → Reviewer	Pipeline med kvalitetstjek	Mellem	3x	Højrisiko kode/docs
LLM Council	Flere modeller evaluerer hinanden	Høj	4-5x	Kritiske beslutninger
Mixture of Experts	Specialiserede modeller per domæne	Høj	3-4x	Tværfaglige projekter
Kanban + Workers	Holdbare opgaver med status-tracking	Mellem	2x	Langvarige projekter

Baseline — ingen koordination

Handoff overhead

1.5x

Context sharing, retry, merge

2-3x

Orchestration, debugging, result merging

4-5x

💡 Sweet spot: 2-3 agenter for de fleste opgaver. Derover stiger koordinationsomkostningerne eksponentielt.

Fejl	Beskrivelse	Mitigation
Context lækage	Agenter deler utilsigtet kontekst	Strict isolation, explicit handoff formats
Dobbeltarbejde	To agenter laver det samme	Kanban board, opgave-ejerskab
Tavse fejler	Agent fejler uden at rapportere	Fail-closed, exit code checking
Koordinations-losion	For mange agenter, for lidt arbejde	Max 3 agenter, evaluer om multi-agent er nødvendigt
Resultat-konflikt	Agenter producerer modstridende output	Reviewer agent, merge protocol

Enkelt domæne, < 3 trin → Single agent er bedre

Gentagen opgave → Cron + single specialist er bedre

Budget-tight → Single agent med free model

Tidskritisk → Single agent (lavere latency)

⚡ Konklusion: Multi-agent er et power-værktøj, ikke default. Start altid med single agent — udvid kun når opgaven kræver det.