Arbejdsgangmønstre for AI-agenter: 7 mønstre, og hvornår de faktisk vinder (2026)

Arbejdsgangmønstre for AI-agenter: 7 mønstre, og hvornår de faktisk vinder (2026)

Arbejdsgangmønstre for AI-agenter har endelig fået tal på: I januar 2026 evaluerede Google Research 180 agentkonfigurationer og fandt, at den samme koordineringsændring løftede paralleliserbar finansiel ræsonnering med 80,9 %, mens den knuste sekventiel planlægning med op til 70 % på PlanCraft. Samme greb, modsat udfald. Den afgørende variabel er opgavens opdelbarhed, ikke antallet af agenter, og de syv mønstre nedenfor bedømmes mod publicerede data, ikke leverandørdiagrammer.

• Syv mønstre betyder noget: sekventiel, routing, parallelisering, orchestrator-workers, refleksion, ReAct og plan-and-execute.
• Opgavens opdelbarhed afgør vinderen. Paralleliserbart arbejde vinder; sekventielt arbejde taber.
• Start med én agent. Tilføj først en anden, når en enkelt agent går i stå under ~85 % nøjagtighed.

Arbejdsgangmønstre for AI-agenter på ét blik: hvad dataene siger

De syv AI-agentmønstre er sekventiel (prompt-kædning), routing (håndovering), parallelisering (fan-out/fan-in), orchestrator-workers, refleksion (evaluator-optimizer), ReAct og plan-and-execute. Fem leverandørers dokumenter navngiver dem forskelligt, men disse syv former dækker enhver taksonomi, som Anthropic, OpenAI, Vercel, Microsoft og Google Cloud publicerer i dag. Human-in-the-loop er ikke en af de syv: det er et kontrollag, der lægges uden på ethvert af dem.

Læs kolonnen med målinger skeptisk. Tre rækker har reelle tal; fire har "ingen offentlig måling", hvilket er feltets ærlige tilstand i 2026. Fem leverandører publicerer fem forskellige navne for det, der i virkeligheden er tre-fire underliggende former. Den sidste kolonne findes, så du kan oversætte ethvert af de navne tilbage til formen nedenunder, hvilket resten af indlægget folder ud én familie ad gangen.

To kolonner, som ingen på SERP'en diskuterer, er tokenomkostninger og latensbudget. Sekventiel og routing bruger mindst af begge; orchestrator-workers bruger mest af begge; parallelisering bytter tokenforbrug mod væg-ur-tid. Vælg mønster efter den ressource, din opgave faktisk begrænser, ikke efter det diagram, der ser imponerende ud.

Hvad er arbejdsgangmønstre for AI-agenter (og hvad er de 4 faser i en AI-arbejdsgang)?

Designmønstre for AI-agentarbejdsgange er genanvendelige former for at arrangere LLM-kald, værktøjsbrug og kontrollogik i et system. De syv, der går igen i alle leverandørers taksonomier, er sekventiel, routing, parallelisering, orchestrator-workers, refleksion, ReAct og plan-and-execute. Hvert mønster afvejer tokenomkostninger, latenstid og nøjagtighed forskelligt, så det rigtige valg afhænger af opgavens struktur, ikke af det framework, du tilfældigvis bruger.

En typisk AI-agentarbejdsgang kører fire faser i en løkke:

1. Planlæg: modellen bestemmer, hvad den skal gøre næste gang, givet målet og historikken indtil videre.
2. Handel: den kalder et værktøj, hvilket i 2026 som regel betyder en MCP-server eller et function call. Model Context Protocol (MCP) standardiserer det værktøjslag på tværs af modeller.
3. Observation: værktøjsresultatet ryger tilbage i konteksten som en ny besked.
4. Refleksion/løkke: modellen vurderer, om resultatet er godt nok, og kører så en ny løkke eller stopper.

Alle mønstre i dette indlæg er forskellige måder at forbinde de fire faser på. Sekventiel fastlægger rækkefølgen i kode. ReAct lader modellen vælge næste fase hver tur. Orchestrator-workers fordeler løkken over flere modeller.

Én skelnen betyder noget før kataloget. En arbejdsgang er forudbestemte kodestier; en agent overlader kontrollen til modellen. Anthropic trækker grænsen sådan i Building Effective Agents: "Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale."

Hvis du ledte efter de klassiske agenttyper i AI (simpel refleks, modelbaseret, målbaseret, lærende), så er den taksonomi ældre end LLM'er; de syv mønstre ovenfor er dem, der afgør, om dit build kommer i produktion.

De deterministiske mønstre: sekventiel, routing og parallelisering

Tre mønstre holder kontrollen i din kode i stedet for i modellen. De er billigst at køre og nemmest at fejlsøge, og Claude-teamets vejledning fra marts 2026 er kontant om, hvor du skal starte: "Start with the simplest pattern that solves your problem. Default to sequential."

Sekventiel (prompt-kædning)

Ét kald føder det næste. Du deler en svær opgave i ordnede trin, og hvert trin får det foregående trins output som input. Gevinsten er læsbarhed: du kan inspicere alle mellemresultater og cache hvert trin. Undgå det, når delopgaverne er uafhængige, for så betaler du latenstid for en rækkefølge, du ikke har brug for. Hvis tilstand skal overleve mellem trin eller på tværs af sessioner, er det et hukommelsesproblem, ikke et kædningsproblem; se vores guide til agenthukommelse for den opdeling. Den eneste publicerede anbefaling er en standard: ingen undersøgelse måler en gevinst ved selve kædningen, for det er den baseline, alle andre mønstre betaler ekstra for at 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 (håndovering)

En billig klassifikator læser inputtet og sender det videre til en specialist-prompt eller -model. OpenAI formulerer det i Agents SDK-dokumentationen: "A triage agent routes the conversation to a specialist, and that specialist becomes the active agent for the rest of the turn." Undgå routing, når klassifikatoren er mindre pålidelig end bare at køre én generel sti, for hver fejlrouting er et stiltiende forkert svar. Den navngivne fejltilstand her er konteksttab på tværs af håndoveringen: specialisten ser kun det, routeren videresender. At bære hele sporet med er en context engineering-beslutning, og at få det galt er grunden til, at routede systemer virker glemsomme. Tokenregnskabet taler alligevel for routing: klassifikatoren kører på en lille model (gpt-4o-mini ovenfor), så en router tilføjer nogle få hundrede billige tokens per forespørgsel i stedet for et ekstra dyrt kald.

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

Parallelisering (fan-out/fan-in)

Uafhængige delopgaver kører samtidigt, og et fletningstrin samler dem. Anthropic deler det op i sectioning (del arbejdet) og voting (kør den samme opgave flere gange og sammenlign). Det er den form, Google Research målte til +80,9 % over én enkelt agent på paralleliserbar finansiel ræsonnering i januar 2026, netop fordi opgaven lod sig dele rent op. Undgå det, i samme øjeblik trin n+1 afhænger af trin n's output; at parallelisere en afhængighedskæde omarrangerer bare de forkerte svar hurtigere. Latenstid er den anden halvdel af gevinsten: uafhængige kald kører samtidigt, så væg-ur-tiden falder nogenlunde med antallet af workers, mens det samlede tokenforbrug forbliver fladt.

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 mod plan-and-execute: hvilket ræsonneringsmønster skal du bruge?

ReAct vekselvirker ræsonnering med handling: modellen tænker, kalder et værktøj, observerer resultatet og beslutter først derefter næste trin. Plan-and-execute skriver hele planen, før noget værktøj kører, og eksekverer derefter trinene i rækkefølge. ReAct tilpasser sig overraskelser undervejs; plan-and-execute betaler for ét stort planlægningskald på forhånd og stoler på ruten.

ReAct bestemmer sit næste trin efter hver observation; plan-and-execute fastlægger hele ruten før det første værktøjskald.

ReAct stammer fra Yao et al. (arXiv 2210.03629, v1 oktober 2022, v3 marts 2023), som rapporterede +34 % absolut succes på ALFWorld og +10 % på WebShop over imitation og reinforcement-learning-baselines med blot ét eller to in-context-eksempler. Det er standardløkken bag de fleste værktøjsbrugende agenter, og det er et hul i SERP-resultatet nr. 3: Microsoft Learns 7.133 ord lange orkestreringsdokument udelader ReAct helt. Den observer-beslut-kadence er grunden til, at ReAct håndterer åbne opgaver ("browse, indtil du finder X") bedre end nogen forhåndsplan: planen ville skulle gætte, hvad siderne indeholder, før den læser dem.

Plan-and-execute stammer fra Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), som først udtænker en plan, der deler opgaven i delopgaver, og derefter udfører dem. Artiklen rapporterer, at den slår zero-shot chain-of-thought på alle ti evaluerede datasæt; vi citerer ikke ét enkelt tal, fordi artiklens abstract ikke publicerer noget. Brug den, når ruten er forudsigelig, og genplanlægning efter hvert trin ville spilde tokens. Tradeoff'en er skrøbelighed: hvis trin tre fejler, har en plan-and-execute-løkke brug for en eksplicit genplanlægningshook, hvorimod ReAct genplanlægger af konstruktion.

Rækken med målt evidens er det ærlige kendetegn. ReAct har en artikel fra 2022 med tal på opgaveniveau; plan-and-execute har en ti-datasæt-gennemgang og intet overskriftstal, hvilket er én grund til, at det oftere citeres, end det benchmarkes.

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."

Det iterationsloft er ikke valgfrit. En ReAct-løkke uden afslutning brænder tokens af, indtil budgettet gør; max_steps er det billigste sikkerhedsnet i hele dette indlæg. Plan-and-execute har brug for det samme net ét niveau oppe: sæt loft over genplanlægningerne, ikke kun trinnene, ellers regenererer en fejlslagen plan sig selv i det uendelige.

Kvalitetsmønstrene: refleksion, evaluator-optimizer og human-in-the-loop

Kvalitetsmønstre bruger ekstra tokens på at hæve outputkvaliteten, og de betaler sig kun, når kvalitet er målbar. Refleksion (Anthropic kalder det evaluator-optimizer) kører en generator og en kritiker i en løkke: én model udkaster, en anden kritiserer, udkastet forbedres. Hvis du ikke kan score outputtet med en test, en rubrik eller en grader-model, er kritikeren bare ekstra tokens, der skændes med sig selv. At bygge den scorer er den svære del; vores guide til evaluering af agenter i produktion dækker, hvad en brugbar scorefunktion kræver. Hvor forudsætningen holder, er mønsteret en billig forsikring: Anthropic beskriver evaluator-optimizer som to LLM-kald i en løkke, ét der genererer og ét der kritiserer, hvilket køber et målbart kvalitetsløft for nogle få ekstra sekunders latenstid.

Fejltilstanden, ingen tegner diagram over, er løbsk refleksion: kritiker og generator kører i løkke for evigt, eller værre, svinger frem og tilbage. Løsningen er et hårdt iterationsloft plus en afbrydelse ved manglende forbedring, skrevet i kode i stedet for anmodet 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 er et kontrollag, ikke et ottende mønster. Det lægges uden på ethvert af de syv: et menneske godkender, før et irreversibelt trin kører. Kun 2 af de 6 bedste SERP-resultater dækker det overhovedet. Placer porten ved irreversible handlinger, reelle udgifter og alt, der forlader dit system som ekstern kommunikation. Alt andet bør køre uden opsyn eller slet ikke køre. Selve porten bør være dum kode, ikke endnu en LLM: en godkendelseskø, en udgiftsgrænse, en allowliste over domæner. At sætte en model til at bestemme, om et menneske skal kigge, modvirker formålet.

Er multi-agent 15× tokens værd? Hvad benchmarks faktisk siger

Orchestrator-workers er det syvende mønster: en hovedagent opdeler en opgave, uddelegerer dele til worker-agenter og fletter det, de returnerer. "Multi-agent" er dette mønster ført til sin yderste konsekvens, ikke en separat form, så spørgsmålet er reelt, hvornår orkestratoren tjener sin overhead hjem.

Hvornår skal du bruge multi-agent i stedet for en enkelt agent? Kun når en enkelt agent går i stå under cirka 85 % nøjagtighed på opgaven. Den tommelfingerregel cirkulerede på r/AI_Agents (2026-04-23) sammen med Google Research-undersøgelsen, og den matcher de målte data: over den grænse tilføjer ekstra agenter omkostninger og fejlforstærkning uden at tilføje nøjagtighed.

Her er alle publicerede tal, vi kunne verificere, side om side:

Én advarsel, før du klikker videre: alle Google Research-tal ovenfor stammer fra blogindlægget af 2026-01-28, og artiklen bag (arXiv 2512.08296) er siden blevet revideret, så den nuværende version rapporterer 260 konfigurationer og R² = 0,373 i stedet for bloggens 180 og 0,513. Retningen holder uanset hvad; de præcise tal afhænger af, hvilken version du læser.

To af disse rækker citeres rutinemæssigt forkert, så her er regnestykket. Anthropics 15×-tal er målt mod en chatinteraktion, og dets enkelt-agent-tal er 4×. Så multi-agent koster cirka 15 / 4 = 3,75× en enkelt agents tokens, ikke 15×. Og Google Researchs fejlforstærkning på 17,2× for uafhængige agenter mod 4,4× for centraliserede betyder, at en orkestrator indeholder cirka 17,2 / 4,4 = 3,9× mindre fejlforstærkning end at lade agenter køre uden opsyn.

Læser man Anthropics gennemgang mod Google Research-tallene, er vores læsning, at opdelbarhed, ikke antallet af agenter, er den afgørende variabel. Anthropics research-opgave delte sig rent i parallelle delsøgninger, så flere agenter hjalp. Googles sekventielle planlægningsopgaver delte sig ikke, så flere agenter stod i vejen for hinanden.

Det matcher, hvad praktikere siger, når systemerne rammer produktion. På r/AI_Agents stammede en tråd med titlen "Multi agent systems are a total nightmare in production" (2026-04-23, 56 point, 68 kommentarer) fra en OP, der har leveret 20+ kundesystemer: "The ones that actually stay running… are almost embarrassingly simple," og "every time one agent talks to another, you lose context. It's like that game of Telephone." Topkommentaren koger hele afsnittet ned: "try to solve your problem with a single agent. If this agent has >85% accuracy a multi agent system will not add any more value."

Før du tilføjer en agent, så prøv de billige rettelser, Anthropic målte: én forbedret værktøjsbeskrivelse gav et 40 % fald i opgavegennemførelsestid, og parallelle værktøjskald skar researchtiden med op til 90 %. Begge slår en ekstra agent på omkostninger. Går du alligevel multi-agent i et rigtigt værktøj, er Claude Code-subagenter orchestrator-workers, du kan inspicere linje for linje.

Samme mønster, fem navne: en framework-rosetta-tabel

De samme fire former optræder under forskellige navne i alle leverandørers dokumenter, og navngivningen overføres ikke mellem frameworks. Microsofts "magentic" og "group chat" betyder intet i OpenAI SDK'en, før du oversætter dem, og den oversættelsesskat er en reel omkostning, som denne tabel fjerner.

Fem leverandører, fem ordforråd, tre-fire reelle former. Den praktiske omkostning viser sig, når du skifter framework: et team, der flytter fra Microsofts Agent Framework til OpenAI SDK'en, skal genoversætte "magentic" til agents-as-tools og "group chat" til en håndoveringsgraf, før én eneste linje kode overføres. Google Clouds elleve-navns-taksonomi er den længste, Anthropics syv-navns-liste er den mest citerede, og Claude-bloggens tre navne er dem, du implementerer først. Læs formen, og læs derefter SDK'en. Kolonneoverskrifterne er selve dokumenterne: Anthropic, Claude-bloggen, OpenAI Agents SDK, Vercel AI SDK, Microsoft Learn og Google Cloud. Når du først ser formerne, er framework-valget en separat beslutning; vores gennemgang af de bedste AI-agent-frameworks i 2026 og sammenligningen LangGraph mod CrewAI mod OpenAI Agents SDK dækker den.

Hvornår skal du slet ikke bruge en agentarbejdsgang?

Ofte skal du ikke. Den mest opstemte beslutningsstige på r/AI_Agents (2026-03-09) siger det rent ud: "If if…then statements will work use that. Then if traditional workflows will work use that. Otherwise use agentic AI." To af de tre bedste SERP-resultater er clouddokumentation, der strukturelt ikke kan fortælle dig, at du skal bygge mindre. Det kan vi. Dataene i dette indlæg peger i samme retning: de to største målte gevinster (+80,9 % og +90,2 %) kom begge fra opgaver, der delte sig rent, og det værste målte tab (−70 %) kom fra at tvinge agenter på en opgave, der ikke gjorde.

Fejltilstandene har navne, og hver enkelt har nu et tal på:

• Konteksttab på tværs af håndoveringer: hver agent-til-agent-besked taber tilstand (r/AI_Agents "Telephone"-klagen, 2026-04-23).
• Fejlforstærkning: 17,2× for uafhængige agenter mod 4,4× centraliseret (Google Research, 2026-01-28).
• Løbske refleksionsløkker: sæt loft over iterationer og afbryd ved manglende forbedring, som i koden ovenfor.
• Forringelse af sekventielle opgaver: 39–70 % værre, når du paralleliserer arbejde, der ikke kan deles (Google Research, 2026-01-28).
• Omkostningseksplosion: cirka 15× chat-tokens for et multi-agent-system (Anthropic, 2025-06-13).

Hver eneste af de fejltilstande har et loft, du kan skrive på ti linjer kode, og loftet er altid billigere end den agent, du var ved at tilføje.

Cognitions Walden Yan fremførte den samme sag fra byggerens side i Don't Build Multi-Agents (2025-06-12): "Share context, and share full agent traces, not just individual messages," og "Actions carry implicit decisions, and conflicting decisions carry bad results." r/AI_Agents-sammenligningen er den, vi bliver ved med at vende tilbage til: "multi agent starts looking a lot like microservices. powerful when the boundaries are real, painful when they're invented."

Hvordan Techsy griber mønstervalget an

Stigen nedenfor er vores læsning af Google Research- og Anthropic-fundene plus praktikertrådene, ikke et målt resultat af vores eget. Vi kører den top til bund og stopper ved den første række, der passer:

Tre ting følger af dataene i dette indlæg. Start sekventielt, for det siger Anthropic, og intet på SERP'en modbeviser det. Parallelisér kun det, der kan deles, for den samme koordineringsændring målt til +80,9 % blev også målt til −70 %. Og behandl en ekstra agent som en sidste udvej, for tokenregningen er reel, og fejlforstærkningen er målt. Den røde tråd er, at tilføjelse af agenter er et skaleringsgreb, ikke et kvalitetsgreb: benchmarks belønner det kun, der hvor arbejdet deler sig, og praktikertrådene bekræfter det alle andre steder. Hvis du vil have et second opinion på en arkitektur, før du bygger den, så få en gratis konsultation.

Ofte stillede spørgsmål

Hvad er de 7 AI-agentmønstre?

De syv er sekventiel (prompt-kædning), routing (håndovering), parallelisering (fan-out/fan-in), orchestrator-workers, refleksion (evaluator-optimizer), ReAct og plan-and-execute. De går igen under forskellige navne i alle leverandørers taksonomier, fra Anthropic til Google Cloud. Human-in-the-loop diskuteres sammen med dem, men er et kontrollag, der lægges uden på ethvert af de syv, ikke et ottende mønster.

Hvad er de 4 faser i en AI-agentarbejdsgang?

Planlæg, handl, observér, reflektér. Modellen planlægger et næste trin, handler ved at kalde et værktøj, observerer værktøjets resultat i konteksten og reflekterer derefter over, om målet er nået, og kører en ny løkke eller stopper. Alle mønstre i dette indlæg er forskellige måder at forbinde de fire faser på.

Hvad er forskellen på en AI-arbejdsgang og en AI-agent?

En arbejdsgang følger forudbestemte kodestier; en agent lader modellen styre sin egen kontrolflow. Anthropics regel: arbejdsgange for forudsigelighed på veldefinerede opgaver, agenter for fleksibilitet, når modeldrevne beslutninger kræves i skala. De fleste produktionssystemer er arbejdsgange med nogle få agenttrin indeni.

ReAct mod plan-and-execute: hvilken skal jeg bruge?

Brug ReAct, når næste trin afhænger af, hvad det seneste værktøj returnerede, og ruten kan ændre sig undervejs. Brug plan-and-execute, når ruten er forudsigelig på forhånd, og genplanlægning efter hvert trin ville spilde tokens. ReAct målte +34 % på ALFWorld (Yao et al., 2022); plan-and-execute slog zero-shot CoT på ti datasæt (Wang et al., 2023).

Har jeg brug for et framework som LangGraph for at bruge disse mønstre?

Nej. Alle kodeblokke i dette indlæg er almindelige SDK-kald, og mønstrene er ældre end de frameworks, der navngiver dem. Et framework tjener sig hjem på tilstandspersistens, retries og tracing, ikke på selve mønsteret. Hvis du vælger ét, dækker vores framework-sammenligning tradeoff'erne.

Hvordan forhindrer jeg en refleksionsløkke i at køre for evigt?

To sikkerhedsnet, begge i kode: et hårdt iterationsloft (vi bruger 4 runder) og en afbrydelse ved manglende forbedring, der stopper, i samme øjeblik kritikerens omskrivning ikke scorer bedre end det nuværende udkast. Stol ikke på, at prompten afslutter løkken; modellen aner ikke, hvad ting koster.

Hvornår er en enkelt agent nok?

Når den clearer cirka 85 % nøjagtighed på opgaven. Den tommelfingerregel cirkulerede på r/AI_Agents (2026-04-23) sammen med Google Research-undersøgelsen og matcher benchmarks: over den grænse tilføjer ekstra agenter omkostninger og fejlforstærkning uden at tilføje nøjagtighed. Mål enkelt-agent-baseline, før du designer noget større.

Hvor kan jeg finde eksempler på arbejdsgangmønstre for AI-agenter med kode?

De fem Python-blokke ovenfor dækker sekventiel, routing, parallelisering, ReAct og refleksion, alle som almindelige SDK-kald, du kan løfte direkte. For leverandørspecifikke eksempler leverer Vercel AI SDK kørbar TypeScript per mønster, og OpenAI Agents SDK-dokumentationen dækker håndoveringer og agents-as-tools. Links til begge findes i kildelisten nedenfor.

Kilder

• 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 by 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 (opdateret 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)