Arbeidsflytmønstre for AI-agenter: 7 mønstre og når hvert mønster faktisk vinner (2026)

Arbeidsflytmønstre for AI-agenter: 7 mønstre og når hvert mønster faktisk vinner (2026)

Arbeidsflytmønstre for AI-agenter har endelig fått tall festet til seg: I januar 2026 evaluerte Google Research 180 agentkonfigurasjoner og fant at den samme koordineringsendringen løftet parallelliserbar finansiell resonnering med 80,9 %, mens den knuste sekvensiell planlegging med opptil 70 % på PlanCraft. Samme spak, motsatt utfall. Variabelen som avgjør, er oppgavens delelighet, ikke antall agenter, og de syv mønstrene nedenfor dømmes opp mot publiserte data, ikke leverandørdiagrammer.

• Syv mønstre betyr noe: sekvensiell, ruting, parallellisering, orchestrator-workers, refleksjon, ReAct og plan-and-execute.
• Oppgavens delelighet avgjør vinneren. Parallelliserbart arbeid vinner; sekvensielt arbeid forringes.
• Start med én agent. Legg til en andre først når én enkelt agent stopper under ~85 % nøyaktighet.

Arbeidsflytmønstre for AI-agenter på ett blikk: hva dataene sier

De syv AI-agentmønstrene er sekvensiell (prompt-kjeding), ruting (håndovering), parallellisering (fan-out/fan-in), orchestrator-workers, refleksjon (evaluator-optimizer), ReAct og plan-and-execute. Fem leverandørdokumenter navngir dem forskjellig, men disse syv formene dekker enhver taksonomi som Anthropic, OpenAI, Vercel, Microsoft og Google Cloud publiserer i dag. Human-in-the-loop er ikke et av de syv: det er et kontrollag som legges utenpå ethvert av dem.

Les målt-kolonnen skeptisk. Tre rader har reelle tall; fire har «ingen publisert måling», som er den ærlige tilstanden i faget i 2026. Fem leverandører publiserer fem forskjellige navn for det som egentlig er tre eller fire underliggende former. Siste kolonne finnes slik at du kan oversette hvilket som helst av disse navnene tilbake til formen under, som resten av innlegget pakker ut én familie om gangen.

To kolonner ingen på SERP-en diskuterer, er tokenkostnad og latensbudsjett. Sekvensiell og ruting bruker minst av begge; orchestrator-workers bruker mest av begge; parallellisering bytter tokenforbruk mot reell kjøretid. Velg mønster etter ressursen oppgaven din faktisk begrenser, ikke etter diagrammet som ser imponerende ut.

Hva er arbeidsflytmønstre for AI-agenter (og hva er de fire stadiene i en AI-arbeidsflyt)?

Arbeidsflytmønstre for AI-agenter er gjenbrukbare former for å sette sammen LLM-kall, verktøybruk og kontrolllogikk til et system. De syv som går igjen i alle leverandørtaksonomier, er sekvensiell, ruting, parallellisering, orchestrator-workers, refleksjon, ReAct og plan-and-execute. Hvert mønster veier tokenkostnad, latens og nøyaktighet forskjellig, så det riktige valget avhenger av oppgavens struktur, ikke av rammeverket du tilfeldigvis bruker.

En typisk AI-agentarbeidsflyt kjører fire stadier, i en løkke:

1. Planlegg: modellen bestemmer hva den skal gjøre videre, gitt målet og historikken så langt.
2. Handle: den kaller et verktøy, som i 2026 vanligvis betyr en MCP-server eller et funksjonskall. Model Context Protocol (MCP) standardiserer det verktøylaget på tvers av modeller.
3. Observere: verktøyresultatet går tilbake til konteksten som en ny melding.
4. Reflektere / løkke: modellen vurderer om resultatet er godt nok, og løkker eller stopper.

Hvert mønster i dette innlegget er en måte å koble sammen disse fire stadiene på. Sekvensiell låser rekkefølgen i kode. ReAct lar modellen velge neste stadium hver runde. Orchestrator-workers fordeler løkken over flere modeller.

Én distinksjon betyr noe før katalogen. En arbeidsflyt er forhåndsbestemte kodebaner; en agent gir kontrollen til modellen. Anthropic trekker grensen slik i Å bygge effektive agenter: «Arbeidsflyter gir forutsigbarhet og konsistens for veldefinerte oppgaver, mens agenter er det bedre valget når fleksibilitet og modellstyrt beslutningstaking trengs i stor skala.»

Hvis du kom hit på jakt etter de klassiske agenttypene i AI (enkel refleks, modellbasert, målbasert, lærende), så er den taksonomien eldre enn LLM-ene; de syv mønstrene over er de som avgjør om bygget ditt faktisk lanseres.

De deterministiske mønstrene: sekvensiell, ruting og parallellisering

Tre mønstre holder kontrollen i koden din, ikke i modellen. De er billigst å kjøre og lettest å feilsøke, og Claude-teamets veiledning fra mars 2026 er kontant om hvor du skal starte: «Start med det enkleste mønsteret som løser problemet ditt. Velg sekvensiell som standard.»

Sekvensiell (prompt-kjeding)

Ett kall mater det neste. Du deler en vanskelig oppgave i ordnede steg, og hvert steg får forrige stegs output som input. Gevinsten er lesbarhet: du kan inspisere hvert delresultat og mellomlagre hvert steg. Unngå det når deloppgavene er uavhengige, for da betaler du latens for en ordning du ikke trenger. Hvis tilstand må overleve mellom steg eller på tvers av sesjoner, er det et hukommelsesproblem, ikke et kjedeproblem; se guiden vår om agent-hukommelse for skillet. Den eneste publiserte anbefalingen er at det er standardvalget: ingen studie måler gevinst av selve kjedingen, fordi det er baseline alle andre mønstre betaler ekstra for å 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.",
])

Ruting (håndovering)

En billig klassifiserer leser inputen og sender den videre til en spesialist-prompt eller -modell. OpenAI beskriver det i Agents SDK-dokumentasjonen: «En triage-agent ruter samtalen til en spesialist, og den spesialisten blir den aktive agenten resten av runden.» Unngå ruting når klassifisereren er mindre pålitelig enn å kjøre én generell bane, for hver feilruting er et stille feil svar. Den navngitte feilmodusen her er konteksttap over håndoveringen: spesialisten ser bare det ruteren videresender. Å bære med seg hele sporet er et valg innen context engineering, og å få det galt er grunnen til at rutete systemer virker glemske. Tokenregnestykket favoriserer uansett ruting: klassifisereren kjører på en liten modell (gpt-4o-mini over), så en ruter legger til noen hundre billige tokens per forespørsel i stedet for et andre dyrt kall.

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)

Uavhengige deloppgaver kjører samtidig, og et sammenslåingssteg kombinerer dem. Anthropic deler dette i seksjonering (del opp arbeidet) og avstemning (kjør samme oppgave flere ganger og sammenlign). Dette er formen Google Research målte til +80,9 % over én enkelt agent på parallelliserbar finansiell resonnering i januar 2026, nettopp fordi oppgaven lot seg dele rent opp. Unngå det i det øyeblikket steg n+1 avhenger av outputen fra steg n; å parallellisere en avhengighetskjede bare omorganiserer de feile svarene raskere. Latens er den andre halvparten av gevinsten: uavhengige kall kjører samtidig, så reell kjøretid faller omtrent med antall arbeidere mens det totale tokenforbruket holder seg flatt.

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 mot plan-and-execute: hvilket resonneringsmønster bør du bruke?

ReAct veksler mellom resonnering og handling: modellen tenker, kaller et verktøy, observerer resultatet og bestemmer først da neste steg. Plan-and-execute skriver hele planen før noe verktøy kjører, og utfører deretter stegene i rekkefølge. ReAct tilpasser seg overraskelser underveis; plan-and-execute betaler for ett stort planleggingskall på forhånd og stoler på løypen.

ReAct bestemmer neste steg etter hver observasjon; plan-and-execute binder seg til hele løypen før det første verktøykallet.

ReAct kommer fra Yao et al. (arXiv 2210.03629, v1 oktober 2022, v3 mars 2023), som rapporterte +34 % absolutt suksess på ALFWorld og +10 % på WebShop over baselinjer med imitasjons- og forsterkningslæring, med bare ett eller to konteksteksempler. Det er standardløkken bak de fleste verktøybrukende agenter, og det er et gap i SERP-resultatet på tredjeplass: Microsoft Learns orkestreringsdokument på 7.133 ord utelater ReAct fullstendig. Den observer-beslutte-kadensen er grunnen til at ReAct håndterer åpne oppgaver («bla til du finner X») bedre enn noen forhåndsplan: planen måtte i så fall gjette hva sidene inneholder før den leser dem.

Plan-and-execute kommer fra Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), som først legger en plan som deler oppgaven i deloppgaver, og deretter utfører dem. Paperet rapporterer at det slår zero-shot chain-of-thought på alle ti evaluerte datasett; vi siterer ingen enkelttall fordi abstractet ikke publiserer noen. Bruk det når løypen er forutsigbar og replanlegging etter hvert steg ville kaste bort tokens. Avveiningen er skjørhet: hvis steg tre feiler, trenger en plan-and-execute-løkke en eksplisitt replanleggingskrok, mens ReAct replanlegger av seg selv.

Målt-bevis-raden er det ærlige kjennetegnet. ReAct har et 2022-paper med tall på oppgavenivå; plan-and-execute har en ti-datasett-gjennomgang og ikke noe overskriftstall, som er én grunn til at det siteres oftere enn 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."

Den iterasjonsgrensen er ikke valgfri. En ReAct-løkke uten avslutning brenner tokens til budsjettet ditt tar slutt; max_steps er det billigste sikkerhetsgjerdet i hele dette innlegget. Plan-and-execute trenger det samme gjerdet ett nivå opp: sett tak på replanleggingene, ikke bare stegene, ellers vil en feilende plan regenerere seg selv i det uendelige.

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

Kvalitetsmønstre bruker ekstra tokens på å heve outputkvaliteten, og de lønner seg bare når kvaliteten er målbar. Refleksjon (Anthropic kaller det evaluator-optimizer) kjører en generator og en kritiker i en løkke: én modell skriver utkast, en annen kritiserer, utkastet blir bedre. Hvis du ikke kan skåre outputen med en test, en vurderingsmatrise eller en grader-modell, er kritikeren bare ekstra tokens som krangler med seg selv. Å bygge den skåreren er den vanskelige delen; guiden vår om evaluering av agenter i produksjon dekker hva en brukbar skårefunksjon krever. Der forutsetningen holder, er mønsteret billig forsikring: Anthropic beskriver evaluator-optimizer som to LLM-kall i en løkke, ett som genererer og ett som kritiserer, noe som kjøper et målbart kvalitetsløft for noen ekstra sekunder latens.

Feilmodusen ingen tegner opp, er løpsk refleksjon: kritikeren og generatoren løkker evig, eller verre, de oscillerer. Fiksen er en hard iterasjonsgrense pluss et brudd ved manglende forbedring, skrevet i kode i stedet for bedt om 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 åttende mønster. Det legges utenpå ethvert av de syv: et menneske godkjenner før et irreversibelt steg kjører. Bare 2 av de 6 øverste SERP-resultatene dekker det i det hele tatt. Plasser porten ved irreversible handlinger, reell pengebruk og alt som forlater systemet ditt som ekstern kommunikasjon. Alt annet bør kjøre uten tilsyn, eller ikke kjøre. Selve porten bør være dum kode, ikke enda en LLM: en godkjenningskø, en kostnadsgrense, en tillatelsesliste for domener. Å sette en modell til å avgjøre om et menneske skal se på, motarbeider hele poenget.

Er multi-agent verdt 15× tokensene? Hva benchmarkene faktisk sier

Orchestrator-workers er det syvende mønsteret: en hovedagent bryter ned en oppgave, delegerer biter til arbeideragenter og slår sammen det de returnerer. «Multi-agent» er dette mønsteret drevet til sin ytterkant, ikke en egen form, så spørsmålet er egentlig når orkestratoren tjener inn overheaden sin.

Når bør du bruke multi-agent i stedet for én enkelt agent? Bare når én enkelt agent stopper under omtrent 85 % nøyaktighet på oppgaven. Den tommelfingerregelen sirkulerte på r/AI_Agents (2026-04-23) sammen med Google Research-studien, og den stemmer med de målte dataene: over den grensen legger ekstra agenter til kostnad og feilforsterkning uten å legge til nøyaktighet.

Her er alle publiserte tall vi klarte å verifisere, side om side:

Én advarsel før du klikker deg videre: alle Google Research-tallene over kommer fra blogginnlegget av 2026-01-28, og paperet bak (arXiv 2512.08296) er revidert siden, så den nåværende versjonen rapporterer 260 konfigurasjoner og R² = 0,373 i stedet for bloggens 180 og 0,513. Retningen holder uansett; de nøyaktige tallene avhenger av hvilken versjon du leser.

To av disse radene siteres jevnlig feil, så her er regnestykket. Anthropics 15×-tall er målt mot en chat-interaksjon, og enkelt-agent-tallet deres er 4×. Så multi-agent koster omtrent 15 / 4 = 3,75× tokensene til én enkelt agent, ikke 15×. Og Google Research sin feilforsterkning på 17,2× for uavhengige agenter mot 4,4× for sentraliserte betyr at en orkestrator inneholder omtrent 17,2 / 4,4 = 3,9× mindre feilforsterkning enn å la agentene kjøre uten tilsyn.

Leser vi Anthropics gjennomgang opp mot Google Research-tallene, er vår tolkning at delelighet, ikke antall agenter, er variabelen som avgjør. Anthropics research-oppgave delte seg rent i parallelle delsøk, så flere agenter hjalp. Googles sekvensielle planleggingsoppgaver lot seg ikke dele, så flere agenter sto i veien for hverandre.

Det stemmer med det praktikere sier når systemene treffer produksjon. På r/AI_Agents kom en tråd med tittelen «Multi agent systems are a total nightmare in production» (2026-04-23, 56 poeng, 68 kommentarer) fra en OP som har levert over 20 klientsystemer: «De som faktisk fortsetter å kjøre … er nesten pinlig enkle», og «hver gang én agent snakker med en annen, mister du kontekst. Det er som hviskeleken.» Toppkommentaren koker sammen hele seksjonen: «prøv å løse problemet ditt med én enkelt agent. Hvis denne agenten har >85 % nøyaktighet, vil et multi-agent-system ikke tilføre noe mer verdi.»

Før du legger til en agent, prøv de billige fiksene Anthropic målte: én forbedret verktøybeskrivelse ga 40 % reduksjon i tid til oppgavefullføring, og parallelle verktøykall kuttet research-tiden med opptil 90 %. Begge slår en andre agent på kostnad. Går du først multi-agent i et reelt verktøy, er Claude Code-subagenter orchestrator-workers du kan inspisere linje for linje.

Samme mønster, fem navn: en Rosetta-tabell for rammeverk

De samme fire formene dukker opp under forskjellige navn i dokumentasjonen til alle leverandørene, og navngivningen overføres ikke mellom rammeverk. Microsofts «magentic» og «group chat» betyr ingenting i OpenAI SDK før du oversetter dem, og den oversettelsesskatten er en reell kostnad denne tabellen fjerner.

Fem leverandører, fem vokabularer, tre eller fire reelle former. Den praktiske kostnaden viser seg når du bytter rammeverk: et team som flytter fra Microsofts Agent Framework til OpenAI SDK, må oversette «magentic» til agents-as-tools og «group chat» til en håndoveringsgraf før én eneste linje kode er overført. Google Clouds elleve navn store taksonomi er den lengste, Anthropics syv navn store liste er den mest siterte, og Claude-bloggens tre navn er de du implementerer først. Les formen, les deretter SDK-en. Kolonneoverskriftene er selve dokumentasjonen: Anthropic, Claude-bloggen, OpenAI Agents SDK, Vercel AI SDK, Microsoft Learn og Google Cloud. Når du først ser formene, er valg av rammeverk en egen beslutning; gjennomgangen vår av de beste AI-agent-rammeverkene i 2026 og sammenligningen LangGraph mot CrewAI mot OpenAI Agents SDK dekker den.

Når bør du IKKE bruke en agentarbeidsflyt i det hele tatt?

Ofte bør du ikke det. Den mest oppstemte beslutningsstigen på r/AI_Agents (2026-03-09) sier det rett ut: «Hvis hvis…så-setninger fungerer, bruk det. Hvis tradisjonelle arbeidsflyter fungerer, bruk det. Ellers bruk agentisk AI.» To av de tre øverste SERP-resultatene er skydokumentasjon som strukturelt sett ikke kan be deg bygge mindre. Det kan vi. Dataene i dette innlegget peker i samme retning: de to største målte gevinstene (+80,9 % og +90,2 %) kom begge fra oppgaver som lot seg dele rent, og det verste målte tapet (−70 %) kom fra å tvinge agenter inn på en oppgave som ikke lot seg dele.

Feilmodusene er navngitt, og hver av dem har nå et tall festet til seg:

• Konteksttap over håndoveringer: hver agent-til-agent-melding mister tilstand (r/AI_Agents-klagen om hviskeleken, 2026-04-23).
• Feilforsterkning: 17,2× for uavhengige agenter mot 4,4× sentralisert (Google Research, 2026-01-28).
• Løpske refleksjonsløkker: sett tak på iterasjonene og bryt ved manglende forbedring, som i koden over.
• Forringelse på sekvensielle oppgaver: 39–70 % verre når du parallelliserer arbeid som ikke lar seg dele (Google Research, 2026-01-28).
• Kostnadseksplosjon: omtrent 15× chat-tokens for et multi-agent-system (Anthropic, 2025-06-13).

Hver eneste av disse feilmodusene har en grense du kan skrive på ti linjer kode, og grensen er alltid billigere enn agenten du var i ferd med å legge til.

Cognitions Walden Yan tok det samme oppgjøret fra byggersiden i Ikke bygg multi-agenter (2025-06-12): «Del kontekst, og del hele agentspor, ikke bare enkeltmeldinger», og «Handlinger bærer implisitte beslutninger, og motstridende beslutninger gir dårlige resultater.» r/AI_Agents-sammenligningen er den vi stadig kommer tilbake til: «multi-agent begynner å ligne mye på mikrotjenester. kraftfullt når grensene er reelle, smertefullt når de er oppfunnet.»

Slik går Techsy frem ved mønstervalg

Stigen under er vår lesning av Google Research- og Anthropic-funnene pluss praktikertrådene, ikke et målt resultat fra oss selv. Vi kjører den topp til bunn og stopper på den første raden som passer:

Tre ting følger av dataene i dette innlegget. Start sekvensielt, fordi Anthropic sier det og ingenting på SERP-en motbeviser det. Parallelliser bare det som lar seg dele, fordi den samme koordineringsendringen som ble målt til +80,9 %, også ble målt til −70 %. Og behandle en andre agent som en siste utvei, for tokenregningen er reell og feilforsterkningen er målt. Rødtråden er at det å legge til agenter er et skaleringsgrep, ikke et kvalitetsgrep: benchmarkene belønner det bare der arbeidet lar seg dele, og praktikertrådene bekrefter det overalt ellers. Hvis du vil ha en second opinion om en arkitektur før du bygger den, Få en gratis konsultasjon.

Ofte stilte spørsmål

Hva er de syv AI-agentmønstrene?

De syv er sekvensiell (prompt-kjeding), ruting (håndovering), parallellisering (fan-out/fan-in), orchestrator-workers, refleksjon (evaluator-optimizer), ReAct og plan-and-execute. De går igjen under forskjellige navn i alle leverandørtaksonomier, fra Anthropic til Google Cloud. Human-in-the-loop diskuteres ofte sammen med dem, men er et kontrollag som legges utenpå ethvert av de syv, ikke et åttende mønster.

Hva er de fire stadiene i en AI-agentarbeidsflyt?

Planlegg, handle, observere, reflektere. Modellen planlegger et neste steg, handler ved å kalle et verktøy, observerer at verktøyets resultat kommer inn i konteksten, og reflekterer deretter over om målet er nådd, og løkker eller stopper. Hvert mønster i dette innlegget er en måte å koble disse fire stadiene sammen på.

Hva er forskjellen på en AI-arbeidsflyt og en AI-agent?

En arbeidsflyt følger forhåndsbestemte kodebaner; en agent lar modellen styre sin egen kontrollflyt. Anthropics regel: arbeidsflyter for forutsigbarhet på veldefinerte oppgaver, agenter for fleksibilitet når modellstyrte beslutninger trengs i stor skala. De fleste produksjonssystemer er arbeidsflyter med noen få agentsteg inni seg.

ReAct mot plan-and-execute: hvilken bør jeg bruke?

Bruk ReAct når neste steg avhenger av hva det forrige verktøyet returnerte, og løypen kan endre seg underveis. Bruk plan-and-execute når løypen er forutsigbar på forhånd, og replanlegging etter hvert steg ville kaste bort tokens. ReAct målte +34 % på ALFWorld (Yao et al., 2022); plan-and-execute slo zero-shot CoT på ti datasett (Wang et al., 2023).

Trenger jeg et rammeverk som LangGraph for å bruke disse mønstrene?

Nei. Hver kodeblokk i dette innlegget er et vanlig SDK-kall, og mønstrene er eldre enn rammeverkene som navngir dem. Et rammeverk tjener seg inn på tilstandsvedvarelse, retry-er og sporing, ikke på selve mønsteret. Hvis du velger ett, dekker rammeverk-sammenligningen vår avveiningene.

Hvordan hindrer jeg at en refleksjonsløkke kjører evig?

To vern, begge i kode: en hard iterasjonsgrense (vi bruker 4 runder) og et brudd ved manglende forbedring som stopper i det øyeblikket kritikerens omskrivning ikke skårer bedre enn gjeldende utkast. Ikke stol på at prompten avslutter løkken; modellen har ingen anelse om hva ting koster.

Når er én enkelt agent nok?

Når den klarer omtrent 85 % nøyaktighet på oppgaven. Den heuristikken, som sirkulerte på r/AI_Agents (2026-04-23) sammen med Google Research-studien, stemmer med benchmarkene: over den grensen legger ekstra agenter til kostnad og feilforsterkning uten å legge til nøyaktighet. Mål enkelt-agent-baselinjen før du designer noe større.

Hvor finner jeg eksempler på arbeidsflytmønstre for AI-agenter med kode?

De fem Python-blokkene over dekker sekvensiell, ruting, parallellisering, ReAct og refleksjon, alle som vanlige SDK-kall du kan løfte direkte. For leverandørspesifikke eksempler leverer Vercel AI SDK kjørbar TypeScript per mønster, og OpenAI Agents SDK-dokumentasjonen dekker håndoveringer og agents-as-tools. Lenker til begge ligger i Kilder-listen under.

Kilder

• Anthropic, Å bygge effektive agenter (2024-12-19)
• Anthropic, Slik bygde vi det multi-agent-baserte research-systemet vårt (2025-06-13)
• Google Research, Mot en vitenskap for skalering av agentsystemer (2026-01-28); paper: arXiv 2512.08296
• Yao et al., ReAct: Å samkjøre resonnering og handling i språkmodeller (v3 2023-03-10)
• Wang et al., Plan-and-Solve-prompting (ACL 2023)
• Claude fra Anthropic, Vanlige arbeidsflytmønstre for AI-agenter (2026-03-05)
• OpenAI Agents SDK, Orkestrering av flere agenter
• Vercel AI SDK, Arbeidsflytmønstre
• Microsoft Learn, Orkestreringsmønstre for AI-agenter (oppdatert 2026-05-12)
• Google Cloud, Velg et designmønster for det agentiske AI-systemet ditt (2026-05-28)
• Cognition (Walden Yan), Ikke bygg multi-agenter (2025-06-12)
• r/AI_Agents, Multi-agent-systemer er et totalt mareritt i produksjon (2026-04-23); Vent, er arbeidsflyter faktisk bedre enn multi-agent-systemer? (2026-03-09)