Arbetsflödesmönster för AI-agenter: 7 mönster och när varje faktiskt vinner (2026)

Arbetsflödesmönster för AI-agenter: 7 mönster och när varje faktiskt vinner (2026)

Arbetsflödesmönster för AI-agenter har äntligen fått siffror på sig: i januari 2026 utvärderade Google Research 180 agentkonfigurationer och fann att samma koordineringsförändring lyfte parallelliserbart finansiellt resonemang med 80,9 % medan den krossade sekventiell planering med upp till 70 % på PlanCraft. Samma hävstång, motsatta utfall. Variabeln som avgör är uppgiftens uppdelbarhet, inte antalet agenter, och de sju mönstren nedan bedöms mot publicerad data snarare än leverantörsdiagram.

• Sju mönster spelar roll: sekventiell, routing, parallellisering, orchestrator-workers, reflektion, ReAct, plan-and-execute.
• Uppgiftens uppdelbarhet avgör vinnaren. Parallelliserbart arbete vinner; sekventiellt arbete försämras.
• Börja med en agent. Lägg till en andra först när en ensam agent stannar under cirka 85 % träffsäkerhet.

Arbetsflödesmönster för AI-agenter i korthet: vad data säger

De sju AI-agentmönstren är sekventiell (prompt-kedjning), routing (överlämning), parallellisering (fan-out/fan-in), orchestrator-workers, reflektion (evaluator-optimizer), ReAct och plan-and-execute. Fem leverantörsdokument döper dem olika, men dessa sju former täcker varje taxonomi som Anthropic, OpenAI, Vercel, Microsoft och Google Cloud publicerar idag. Human-in-the-loop är inte ett av de sju: det är ett kontrollager som omsluter vilket som helst av dem.

Läs kolumnen med mätdata skeptiskt. Tre rader har riktiga siffror; fyra har "ingen publicerad mätning", vilket är teknikområdets ärliga tillstånd 2026. Fem leverantörer publicerar fem olika namn för det som i grunden är tre eller fyra former. Sista kolumnen finns där för att du ska kunna översätta valfritt av dessa namn tillbaka till formen under, vilket resten av artikeln går igenom en familj i taget.

Två kolumner som ingen på SERP:en diskuterar är tokenkostnad och latensbudget. Sekventiell och routing spenderar minst av båda; orchestrator-workers spenderar mest av båda; parallellisering byter tokenkostnad mot väggklockstid. Välj mönster efter den resurs din uppgift faktiskt begränsar, inte efter diagrammet som ser imponerande ut.

Vad är arbetsflödesmönster för AI-agenter (och vad är de 4 stegen i ett AI-arbetsflöde)?

Designmönster för AI-agentarbetsflöden är återanvändbara former för att ordna LLM-anrop, verktygsanvändning och kontrolllogik till ett system. De sju som återkommer i varje leverantörstaxonomi är sekventiell, routing, parallellisering, orchestrator-workers, reflektion, ReAct och plan-and-execute. Varje mönster byter av tokenkostnad, latens och träffsäkerhet på olika sätt, så rätt val beror på uppgiftens struktur snarare än det framework du råkar använda.

Ett typiskt AI-agentarbetsflöde löper genom fyra steg, i en loop:

1. Planera: modellen bestämmer vad som ska göras härnäst, givet målet och historiken så här långt.
2. Agera: den anropar ett verktyg, vilket 2026 oftast betyder en MCP-server eller ett funktionsanrop. Model Context Protocol (MCP) standardiserar det verktygslagret över modeller.
3. Observera: verktygsresultatet går tillbaka in i kontexten som ett nytt meddelande.
4. Reflektera / loopa: modellen bedömer om resultatet är tillräckligt bra, och loopar eller stannar.

Varje mönster i den här artikeln är ett olika sätt att koppla ihop dessa fyra steg. Sekventiell låser ordningen i kod. ReAct låter modellen välja nästa steg varje tur. Orchestrator-workers delar upp loopen över flera modeller.

En åtskillnad spelar roll innan katalogen. Ett arbetsflöde är förutbestämda kodvägar; en agent lämnar kontrollen till modellen. Anthropic drar gränsen så här i Building Effective Agents: "Arbetsflöden ger förutsägbarhet och konsistens för väldefinierade uppgifter, medan agenter är det bättre valet när flexibilitet och modelldrivna beslut behövs i stor skala."

Om du kom hit och letade efter de klassiska agenttyperna inom AI (enkel reflex, modellbaserad, målbaserad, lärande) så föregår den taxonomin LLM:erna; det är de sju mönstren ovan som avgör om ditt system når produktion.

De deterministiska mönstren: sekventiell, routing och parallellisering

Tre mönster behåller kontrollen i din kod snarare än i modellen. De är billigast att köra och lättast att felsöka, och Claude-teamets råd från mars 2026 är rakt på sak om var man ska börja: "Börja med det enklaste mönster som löser ditt problem. Välj sekventiell som standard."

Sekventiell (prompt-kedjning)

Ett anrop matar nästa. Du delar upp en svår uppgift i ordnade steg, och varje steg får föregående stegs utdata som indata. Vinsten är läsbarhet: du kan inspektera varje delresultat och cacha varje steg. Undvik det när deluppgifterna är oberoende, eftersom du betalar latens för en ordning du inte behöver. Om tillstånd måste överleva mellan steg eller över sessioner är det ett minnesproblem, inte ett kedjningsproblem; se vår guide om agentminne för gränsdragningen. Dess enda publicerade rekommendation är en standardinställning: ingen studie mäter en vinst av kedjning i sig, eftersom den är baslinjen som alla andra mönster betalar extra för att slå.

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

Routing (överlämning)

En billig klassificerare läser indata och skickar den till en specialistprompt eller modell. OpenAI beskriver det i Agents SDK-dokumentationen: "En triage-agent dirigerar konversationen till en specialist, och den specialisten blir den aktiva agenten under resten av turen." Undvik routing när klassificeraren är mindre tillförlitlig än att bara köra en generell väg, eftersom varje feldirigering är ett tyst felaktigt svar. Det namngivna felfallet här är kontextförlust över överlämningen: specialisten ser bara vad routern vidarebefordrar. Att bära med sig hela spåret är ett beslut om kontextteknik, och att få det fel är anledningen till att routade system känns glömska. Tokenmatten gynnar routing ändå: klassificeraren körs på en liten modell (gpt-4o-mini ovan), så en router lägger till några hundra billiga tokens per anrop snarare än ett andra dyrt anrop.

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

Parallellisering (fan-out/fan-in)

Oberoende deluppgifter körs samtidigt, sedan slår ett sammanslagningssteg ihop dem. Anthropic delar upp detta i sectioning (dela upp arbetet) och voting (kör samma uppgift flera gånger och jämför). Det här är formen som Google Research mätte till +80,9 % över en ensam agent på parallelliserbart finansiellt resonemang i januari 2026, just för att uppgiften delade upp sig rent. Undvik det i samma ögonblick som steg n+1 beror på steg n:s utdata; att parallellisera en beroendekedja ordnar bara om de felaktiga svaren snabbare. Latensen är andra halvan av vinsten: oberoende anrop körs samtidigt, så väggklockstiden sjunker ungefär med antalet arbetare medan den totala tokenkostnaden ligger kvar.

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct vs plan-and-execute: vilket resonemangsmönster ska du använda?

ReAct flätar samman resonemang med handling: modellen tänker, anropar ett verktyg, observerar resultatet och bestämmer först då nästa steg. Plan-and-execute skriver hela planen innan något verktyg körs och exekverar sedan stegen i ordning. ReAct anpassar sig efter överraskningar mitt i körningen; plan-and-execute betalar för ett stort planeringsanrop i förväg och litar på vägen.

ReAct bestämmer nästa steg efter varje observation; plan-and-execute bestämmer sig för hela vägen innan det första verktygsanropet.

ReAct kommer från Yao et al. (arXiv 2210.03629, v1 oktober 2022, v3 mars 2023), som rapporterade +34 % absolut framgång på ALFWorld och +10 % på WebShop jämfört med baslinjer från imitation och förstärkningsinlärning, med bara ett eller två in-context-exempel. Det är standardloopen bakom de flesta verktygsanvändande agenter, och det är en lucka i SERP-resultatet på plats 3: Microsoft Learns 7 133 ord långa orkestreringsdokument utelämnar ReAct helt. Den där observera-bestäm-kadensen är varför ReAct hanterar öppna uppgifter ("surfa tills du hittar X") bättre än någon förhandsplan: planen skulle behöva gissa vad sidorna innehåller innan den läst dem.

Plan-and-execute kommer från Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), som först lägger upp en plan som delar uppgiften i deluppgifter och sedan utför dem. Artikeln rapporterar att den slår zero-shot chain-of-thought över alla tio utvärderade dataset; vi citerar ingen enskild siffra eftersom artikelns abstract inte publicerar någon. Använd den när vägen är förutsägbar och omplanering efter varje steg skulle slösa tokens. Avvägningen är skörhet: om steg tre misslyckas behöver en plan-and-execute-loop en uttrycklig omplaneringshook, medan ReAct omplanerar till sin konstruktion.

Raden med uppmätta belägg är den ärliga signalen. ReAct har en artikel från 2022 med siffror på uppgiftsnivå; plan-and-execute har ett tio-dataset-svep och ingen rubriksiffra, vilket är en anledning till att den citeras oftare än den benchmarkas.

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

Den iterationsgränsen är inte valfri. En ReAct-loop utan avslut bränner tokens tills budgeten tar slut; max_steps är det billigaste skyddsräcket i hela den här artikeln. Plan-and-execute behöver samma skydd en nivå upp: sätt tak för omplaneringarna, inte bara stegen, annars kommer en misslyckad plan att regenerera sig själv i oändlighet.

Kvalitetsmönstren: reflektion, evaluator-optimizer och human-in-the-loop

Kvalitetsmönster spenderar extra tokens för att höja utdatakvaliteten, och de lönar sig bara när kvaliteten är mätbar. Reflektion (Anthropic kallar det evaluator-optimizer) kör en generator och en kritiker i en loop: en modell gör utkastet, en annan kritiserar, utkastet förbättras. Om du inte kan sätta betyg på utdata med ett test, en bedömningsmall eller en bedömarmodell är kritikern bara extra tokens som grälar med sig själv. Att bygga den bedömaren är den svåra delen; vår guide om att utvärdera agenter i produktion täcker vad en användbar betygsfunktion kräver. Där förutsättningen håller är mönstret en billig försäkring: Anthropic beskriver evaluator-optimizer som två LLM-anrop i en loop, ett som genererar och ett som kritiserar, vilket köper en mätbar kvalitetslyft för några extra sekunders latens.

Felfallet som ingen ritar upp är skenande reflektion: kritikern och generatorn loopar för evigt, eller värre, oscillerar. Lösningen är en hård iterationsgräns plus ett avbrott vid utebliven förbättring, skrivet i kod snarare än begärt i prompten:

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

Human-in-the-loop är ett kontrollager, inte ett åttonde mönster. Det omsluter vilket som helst av de sju: en människa godkänner innan ett oåterkalleligt steg körs. Bara 2 av de 6 bästa SERP-resultaten täcker det alls. Placera grinden vid oåterkalleliga åtgärder, riktiga utgifter och allt som lämnar ditt system som extern kommunikation. Allt annat bör köra obevakat eller inte alls. Själva grinden ska vara dum kod, inte ännu en LLM: en godkändekö, en utgiftströskel, en domänallowlista. Att sätta en modell att bestämma om en människa ska titta besegrar syftet.

Är multi-agent värt 15× tokens? Vad benchmarkdata faktiskt säger

Orchestrator-workers är det sjunde mönstret: en ledaragent delar upp en uppgift, delegerar delar till arbetaragenter och slår ihop det de returnerar. "Multi-agent" är det här mönstret drivet till sin spets, inte en separat form, så frågan är egentligen när orkestreraren tjänar in sin overhead.

När ska du använda multi-agent istället för en ensam agent? Bara när en ensam agent stannar under cirka 85 % träffsäkerhet på uppgiften. Den tumregeln cirkulerade på r/AI_Agents (2026-04-23) tillsammans med Google Research-studien, och den matchar mätdata: över den ribban tillför extra agenter kostnad och felförstärkning utan att tillföra träffsäkerhet.

Här är alla publicerade siffror vi kunde verifiera, sida vid sida:

En brasklapp innan du klickar vidare: varje Google Research-siffra ovan kommer från blogginlägget 2026-01-28, och artikeln bakom (arXiv 2512.08296) har reviderats sedan dess, så dess nuvarande version rapporterar 260 konfigurationer och R² = 0,373 snarare än bloggens 180 och 0,513. Riktningen håller hur som helst; de exakta siffrorna beror på vilken version du läser.

Två av dessa rader citeras rutinmässigt fel, så här är uträkningen. Anthropics 15×-siffra mäts mot en chattinteraktion, och dess siffra för ensam agent är 4×. Så multi-agent kostar ungefär 15 / 4 = 3,75× en ensam agents tokens, inte 15×. Och Google Researchs felförstärkning på 17,2× för fristående agenter mot 4,4× för centraliserade betyder att en orkestrerare innehåller ungefär 17,2 / 4,4 = 3,9× mindre felförstärkning än att låta agenter köra utan tillsyn.

Läser vi Anthropics beskrivning mot Google Researchs siffror är vår slutsats att uppdelbarhet, inte antalet agenter, är variabeln som avgör. Anthropics forskningsuppgift delade upp sig rent i parallella delsökningar, så fler agenter hjälpte. Googles sekventiella planeringsuppgifter delade sig inte, så fler agenter stod i vägen för varandra.

Det matchar vad utövare säger när system når produktion. På r/AI_Agents kom en tråd med titeln "Multi agent systems are a total nightmare in production" (2026-04-23, 56 poäng, 68 kommentarer) från en OP som skeppat 20+ kundsystem: "De som faktiskt fortsätter köra… är nästan pinsamt enkla", och "varje gång en agent pratar med en annan förlorar du kontext. Det är som viskleken." Toppkommentaren kokar ner hela avsnittet: "försök lösa ditt problem med en ensam agent. Om den agenten har >85 % träffsäkerhet kommer ett multi-agent-system inte att tillföra något värde."

Innan du lägger till en agent, prova de billiga fix som Anthropic mätte: en förbättrad verktygsbeskrivning gav en 40 % minskning av tiden till uppgiftsslutförande, och parallella verktygsanrop kortade forskningstiden med upp till 90 %. Båda slår en andra agent på kostnad. Om du ändå kör multi-agent i ett riktigt verktyg är Claude Code-subagenter orchestrator-workers som du kan inspektera rad för rad.

Samma mönster, fem namn: en Rosetta-tabell för framework

Samma fyra former dyker upp under olika namn i varje leverantörs dokumentation, och namnen överförs inte mellan framework. Microsofts "magentic" och "group chat" betyder ingenting i OpenAI SDK:t förrän du översätter dem, och den översättningsskatten är en riktig kostnad som den här tabellen tar bort.

Fem leverantörer, fem vokabulär, tre eller fyra riktiga former. Den praktiska kostnaden dyker upp när du byter framework: ett team som flyttar från Microsofts Agent Framework till OpenAI SDK:t måste översätta "magentic" till agents-as-tools och "group chat" till en handoff-graf innan en enda rad kod flyttas. Google Clouds elvanamn-taxonomi är längst, Anthropics sjuanamn-lista är mest citerad, och Claude-bloggens tre namn är de du implementerar först. Läs formen, läs sedan SDK:t. Kolumnrubrikerna är själva dokumenten: Anthropic, Claude-bloggen, OpenAI Agents SDK, Vercel AI SDK, Microsoft Learn och Google Cloud. När du väl ser formerna är valet av framework ett separat beslut; vår genomgång av de bästa AI-agent-frameworks 2026 och jämförelsen LangGraph vs CrewAI vs OpenAI Agents SDK täcker det.

När ska du INTE använda ett agentarbetsflöde alls?

Ofta ska du inte det. Den mest uppröstade beslutstegen på r/AI_Agents (2026-03-09) säger det rakt ut: "Fungerar if…then-satser så använd det. Fungerar sedan traditionella arbetsflöden så använd det. Annars, använd agentisk AI." Två av de tre bästa SERP-resultaten är molndokumentation som strukturellt inte kan säga åt dig att bygga mindre. Det kan vi. Datan i den här artikeln pekar åt samma håll: de två största uppmätta vinsterna (+80,9 % och +90,2 %) kom båda från uppgifter som delade upp sig rent, och den värsta uppmätta förlusten (−70 %) kom från att tvinga in agenter på en uppgift som inte gjorde det.

Felfallen har namn, och varje har nu en siffra på sig:

• Kontextförlust vid överlämningar: varje agent-till-agent-meddelande tappar tillstånd (r/AI_Agents-klagomålet om "viskleken", 2026-04-23).
• Felförstärkning: 17,2× för fristående agenter mot 4,4× centraliserat (Google Research, 2026-01-28).
• Skenande reflektionsloopar: sätt tak för iterationer och bryt vid utebliven förbättring, som i koden ovan.
• Försämring av sekventiella uppgifter: 39–70 % sämre när du parallelliserar arbete som inte kan delas upp (Google Research, 2026-01-28).
• Kostnadsexplosion: ungefär 15× chatt-tokens för ett multi-agent-system (Anthropic, 2025-06-13).

Var och ett av dessa felfall har en gräns du kan skriva på tio rader kod, och gränsen är alltid billigare än agenten du var på väg att lägga till.

Cognitions Walden Yan framförde samma sak från byggarhållet i Don't Build Multi-Agents (2025-06-12): "Dela kontext, och dela fullständiga agentspår, inte bara enskilda meddelanden", och "Åtgärder bär på implicita beslut, och motstridiga beslut ger dåliga resultat." r/AI_Agents-jämförelsen är den vi ständigt återkommer till: "multi-agent börjar påminna mycket om mikrotjänster. kraftfullt när gränserna är riktiga, smärtsamt när de är påhittade."

Hur Techsy väljer mönster

Stegen nedan är vår läsning av Google Researchs och Anthropics resultat plus utövartrådarna, inte ett eget uppmätt resultat. Vi kör den uppifrån och ner och stannar vid första raden som passar:

Tre saker följer av datan i den här artikeln. Börja sekventiellt, eftersom Anthropic säger det och ingenting på SERP:en motbevisar det. Parallellisera bara det som kan delas upp, eftersom samma koordineringsförändring som mättes till +80,9 % också mättes till −70 %. Och behandla en andra agent som en sista utväg, eftersom tokennotan är verklig och felförstärkningen är uppmätt. Den röda tråden är att lägga till agenter är en skalningsåtgärd, inte en kvalitetsåtgärd: benchmark belönar det bara där arbetet delar sig, och utövartrådarna bekräftar det överallt annars. Om du vill ha ett second opinion på en arkitektur innan du bygger den, boka en gratis konsultation.

Vanliga frågor

Vad är de 7 AI-agentmönstren?

De sju är sekventiell (prompt-kedjning), routing (överlämning), parallellisering (fan-out/fan-in), orchestrator-workers, reflektion (evaluator-optimizer), ReAct och plan-and-execute. De återkommer under olika namn i varje leverantörstaxonomi, från Anthropic till Google Cloud. Human-in-the-loop diskuteras vid sidan av dem men är ett kontrollager som omsluter vilket som helst av de sju, inte ett åttonde mönster.

Vad är de 4 stegen i ett AI-agentarbetsflöde?

Planera, agera, observera, reflektera. Modellen planerar ett nästa steg, agerar genom att anropa ett verktyg, observerar verktygets resultat komma in i kontexten och reflekterar sedan över om målet är uppnått och loopar eller stannar. Varje mönster i den här artikeln är ett olika sätt att koppla ihop dessa fyra steg.

Vad är skillnaden mellan ett AI-arbetsflöde och en AI-agent?

Ett arbetsflöde följer förutbestämda kodvägar; en agent låter modellen styra sitt eget kontrollflöde. Anthropics regel: arbetsflöden för förutsägbarhet på väldefinierade uppgifter, agenter för flexibilitet när modelldrivna beslut behövs i stor skala. De flesta produktionssystem är arbetsflöden med några agentsteg inuti.

ReAct vs plan-and-execute: vilken ska jag använda?

Använd ReAct när nästa steg beror på vad det senaste verktyget returnerade och vägen kan ändras under körning. Använd plan-and-execute när vägen är förutsägbar i förväg och omplanering efter varje steg skulle slösa tokens. ReAct mätte +34 % på ALFWorld (Yao et al., 2022); plan-and-execute slog zero-shot CoT på tio dataset (Wang et al., 2023).

Behöver jag ett framework som LangGraph för att använda dessa mönster?

Nej. Varje kodblock i den här artikeln är ett vanligt SDK-anrop, och mönstren föregår de framework som döper dem. Ett framework tjänar in sig på tillståndsbeständighet, omförsök och spårning, inte på själva mönstret. Om du väljer ett täcker vår framework-jämförelse avvägningarna.

Hur stoppar jag en reflektionsloop från att köra för evigt?

Två skydd, båda i kod: en hård iterationsgräns (vi använder 4 rundor) och ett avbrott vid utebliven förbättring som stoppar i samma ögonblick som kritikerns omskrivning inte får bättre betyg än det aktuella utkastet. Lita inte på att prompten avslutar loopen; modellen har ingen aning om vad saker kostar.

När räcker en ensam agent?

När den klarar ungefär 85 % träffsäkerhet på uppgiften. Den tumregeln, som cirkulerade på r/AI_Agents (2026-04-23) tillsammans med Google Research-studien, matchar benchmark: över den ribban tillför extra agenter kostnad och felförstärkning utan att tillföra träffsäkerhet. Mät baslinjen för en ensam agent innan du designar något större.

Var hittar jag exempel på arbetsflödesmönster för AI-agenter med kod?

De fem Python-blocken ovan täcker sekventiell, routing, parallellisering, ReAct och reflektion, alla som vanliga SDK-anrop som du kan lyfta direkt. För leverantörsfärgade exempel skeppar Vercel AI SDK körbar TypeScript per mönster och OpenAI Agents SDK-dokumentationen täcker handoffs och agents-as-tools. Länkar till båda finns i källlistan nedan.

Källor

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Google Research, Towards a science of scaling agent systems (2026-01-28); artikel: arXiv 2512.08296
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang et al., Plan-and-Solve Prompting (ACL 2023)
• Claude av Anthropic, Common workflow patterns for AI agents (2026-03-05)
• OpenAI Agents SDK, Orchestrating multiple agents
• Vercel AI SDK, Workflow Patterns
• Microsoft Learn, AI Agent Orchestration Patterns (uppdaterad 2026-05-12)
• Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
• Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23); Wait, are workflows actually better than multi-agent systems? (2026-03-09)