Pattern-uri workflow pentru agenți AI: 7 pattern-uri și când câștigă fiecare (2026)

Pattern-uri workflow pentru agenți AI: 7 pattern-uri și când câștigă fiecare (2026)

Pattern-urile workflow pentru agenți AI au în sfârșit numere atașate: în ianuarie 2026, Google Research a evaluat 180 de configurații de agenți și a constatat că aceeași schimbare de coordonare a ridicat raționamentul financiar paralelizabil cu 80,9%, în timp ce a prăbușit planificarea secvențială cu până la 70% pe PlanCraft. Același levier, rezultate opuse. Variabila care decide este descompunabilitatea sarcinii, nu numărul de agenți, iar cele șapte pattern-uri de mai jos sunt judecate după date publicate, nu după diagrame de vendor.

• Șapte pattern-uri contează: secvențial, rutare, paralelizare, orchestrator-workers, reflecție, ReAct, plan-and-execute.
• Descompunabilitatea sarcinii decide câștigătorul. Munca paralelizabilă câștigă; munca secvențială se degradează.
• Pornește cu un singur agent. Adaugă un al doilea doar când un agent unic se blochează sub ~85% acuratețe.

Pattern-uri workflow pentru agenți AI dintr-o privire: ce spun datele

Cele șapte pattern-uri pentru agenți AI sunt secvențial (prompt chaining), rutare (handoff), paralelizare (fan-out/fan-in), orchestrator-workers, reflecție (evaluator-optimizer), ReAct și plan-and-execute. Cinci documentații de vendor le numesc diferit, dar aceste șapte forme acoperă fiecare taxonomie pe care Anthropic, OpenAI, Vercel, Microsoft și Google Cloud o publică în prezent. Human-in-the-loop nu este unul dintre cele șapte: este un strat de control care învăluie oricare dintre ele.

Citește coloana măsurată cu scepticism. Trei rânduri poartă numere reale; patru poartă „nicio măsurare publică", ceea ce este starea onestă a domeniului în 2026. Cinci vendori publică cinci denumiri diferite pentru ceea ce sunt de fapt trei sau patru forme subiacente. Ultima coloană există ca să poți mapa oricare dintre acele denumiri înapoi la forma de dedesubt, iar restul articolului desfășoară câte o familie pe rând.

Două coloane pe care nimeni din SERP nu le discută sunt costul de tokeni și bugetul de latență. Secvențial și rutare cheltuiesc cel mai puțin din ambele; orchestrator-workers cheltuiește cel mai mult din ambele; paralelizarea schimbă cheltuiala de tokeni pe timp de execuție. Alege pattern-ul după resursa pe care sarcina ta o constrânge de fapt, nu după diagrama care arată impresionant.

Ce sunt pattern-urile workflow pentru agenți AI (și care sunt cele 4 etape ale unui workflow AI)?

Pattern-urile de design pentru workflow-uri de agenți AI sunt forme reutilizabile de aranjare a apelurilor LLM, a utilizării instrumentelor și a logicii de control într-un sistem. Cele șapte care revin în fiecare taxonomie de vendor sunt secvențial, rutare, paralelizare, orchestrator-workers, reflecție, ReAct și plan-and-execute. Fiecare schimbă diferit costul de tokeni, latența și acuratețea, așa că alegerea corectă depinde de structura sarcinii, nu de framework-ul pe care se întâmplă să-l folosești.

Un workflow tipic de agent AI rulează patru etape, în buclă:

1. Planifică: modelul decide ce face în continuare, dat fiind obiectivul și istoricul de până acum.
2. Acționează: apelează un instrument, ceea ce în 2026 înseamnă de obicei un server MCP sau un function call. Model Context Protocol (MCP) standardizează acel strat de instrumente între modele.
3. Observă: rezultatul instrumentului se întoarce în context ca mesaj nou.
4. Reflectă / buclă: modelul judecă dacă rezultatul este suficient de bun, apoi buclează sau se oprește.

Fiecare pattern din acest articol este un mod diferit de a conecta aceste patru etape. Secvențial fixează ordinea în cod. ReAct lasă modelul să aleagă etapa următoare la fiecare tură. Orchestrator-workers împarte bucla între mai multe modele.

O distincție contează înainte de catalog. Un workflow este căi de cod predeterminate; un agent predă controlul modelului. Anthropic trasează linia astfel în 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."

Dacă ai ajuns aici căutând tipurile clasice de agenți din AI (reflex simplu, bazat pe model, bazat pe obiectiv, care învață), acea taxonomie este anterioară LLM-urilor; cele șapte pattern-uri de mai sus sunt cele care decid dacă build-ul tău ajunge în producție.

Pattern-urile deterministe: secvențial, rutare și paralelizare

Trei pattern-uri păstrează controlul în codul tău, nu în model. Sunt cele mai ieftine de rulat și cele mai ușor de depanat, iar recomandarea echipei Claude din martie 2026 este tranșantă în privința punctului de plecare: „Start with the simplest pattern that solves your problem. Default to sequential."

Secvențial (prompt chaining)

Un apel îl alimentează pe următorul. Împarți o sarcină grea în pași ordonați, iar fiecare pas primește ieșirea pasului anterior ca intrare. Câștigul este lizibilitatea: poți inspecta fiecare rezultat intermediar și poți pune în cache fiecare pas. Evită-l când subsarcinile sunt independente, pentru că plătești latență pentru o ordonare de care nu ai nevoie. Dacă starea trebuie să supraviețuiască între pași sau între sesiuni, aceea este o problemă de memorie, nu de înlănțuire; vezi ghidul nostru despre memoria agenților pentru împărțire. Singura sa recomandare publicată este una implicită: niciun studiu nu măsoară un câștig din înlănțuire în sine, pentru că este linia de bază pe care orice alt pattern plătește în plus ca să o bată.

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.",
])

Rutare (handoff)

Un clasificator ieftin citește intrarea și o trimite către un prompt sau un model specialist. OpenAI îl încadrează în documentația Agents SDK: „A triage agent routes the conversation to a specialist, and that specialist becomes the active agent for the rest of the turn." Evită rutarea când clasificatorul este mai puțin fiabil decât rularea unei singure căi generale, pentru că orice rutare greșită este un răspuns greșit silențios. Modul de eșec numit aici este pierderea contextului la handoff: specialistul vede doar ce îi înaintează routerul. Transportul întregii urme este o decizie de context engineering, iar greșeala aici este motivul pentru care sistemele rutate par uitate. Matematica tokenilor favorizează oricum rutarea: clasificatorul rulează pe un model mic (gpt-4o-mini mai sus), deci un router adaugă câteva sute de tokeni ieftini per cerere, nu un al doilea apel scump.

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

Paralelizare (fan-out/fan-in)

Subsarcinile independente rulează simultan, apoi un pas de îmbinare le combină. Anthropic împarte asta în sectioning (împarte munca) și voting (rulează aceeași sarcină de mai multe ori și compară). Aceasta este forma pe care Google Research a măsurat-o la +80,9% față de un agent unic pe raționament financiar paralelizabil în ianuarie 2026, tocmai pentru că sarcina se descompunea curat. Evită-l în momentul în care pasul n+1 depinde de ieșirea pasului n; paralelizarea unui lanț de dependențe doar reordonează mai repede răspunsurile greșite. Latența este cealaltă jumătate a câștigului: apelurile independente rulează concurent, deci timpul de execuție scade aproximativ cu numărul de workeri, în timp ce cheltuiala totală de tokeni rămâne plată.

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: ce pattern de raționament ar trebui să folosești?

ReAct intercalează raționamentul cu acțiunea: modelul gândește, apelează un instrument, observă rezultatul și abia apoi decide pasul următor. Plan-and-execute scrie planul complet înainte ca orice instrument să ruleze, apoi execută pașii în ordine. ReAct se adaptează la surprize în timpul rulării; plan-and-execute plătește de la început pentru un apel mare de planificare și are încredere în rută.

ReAct își decide pasul următor după fiecare observare; plan-and-execute se angajează la toată ruta înainte de primul apel de instrument.

ReAct vine de la Yao et al. (arXiv 2210.03629, v1 octombrie 2022, v3 martie 2023), care a raportat +34% succes absolut pe ALFWorld și +10% pe WebShop față de bazele de imitație și învățare prin recompensă, folosind doar unul sau două exemple în context. Este bucla implicită din spatele majorității agenților care folosesc instrumente și este o lacună în rezultatul SERP #3: documentul de orchestrare Microsoft Learn de 7.133 cuvinte omite ReAct complet. Cadența observă-decide este motivul pentru care ReAct gestionează sarcinile deschise („navighează până găsești X") mai bine decât orice plan de la început: planul ar trebui să ghicească ce conțin paginile înainte să le citească.

Plan-and-execute vine de la Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), care mai întâi concepe un plan ce împarte sarcina în subsarcini, apoi le execută. Lucrarea raportează că bate zero-shot chain-of-thought pe toate cele zece dataset-uri evaluate; nu cităm nicio cifră unică pentru că abstractul lucrării nu publică niciuna. Folosește-l când ruta este predictibilă și replanificarea după fiecare pas ar risipi tokeni. Compromisul este fragilitatea: dacă pasul trei eșuează, o buclă plan-and-execute are nevoie de un cârlig explicit de replanificare, pe când ReAct replanifică prin construcție.

Rândul dovezilor măsurate este semnalul onest. ReAct are o lucrare din 2022 cu numere la nivel de sarcină; plan-and-execute are o trecere prin zece dataset-uri și nicio cifră de titlu, ceea ce este un motiv pentru care este citat mai des decât este benchmark-uit.

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

Acel plafon de iterații nu este opțional. O buclă ReAct fără ieșire arde tokeni până când bugetul tău o face; max_steps este cel mai ieftin parapet din tot acest articol. Plan-and-execute are nevoie de același parapet cu un nivel mai sus: plafonază replanificările, nu doar pașii, altfel un plan care eșuează se va regenera la nesfârșit.

Pattern-urile de calitate: reflecție, evaluator-optimizer și human-in-the-loop

Pattern-urile de calitate cheltuiesc tokeni în plus ca să ridice calitatea ieșirii și se plătesc doar când calitatea este măsurabilă. Reflecția (Anthropic o numește evaluator-optimizer) rulează un generator și un critic într-o buclă: un model schițează, altul critică, schița se îmbunătățește. Dacă nu poți puncta ieșirea cu un test, o grilă sau un model evaluator, criticul este doar tokeni în plus care se ceartă cu ei înșiși. Construirea acelui evaluator este partea grea; ghidul nostru despre evaluarea agenților în producție acoperă ce presupune o funcție de punctare utilizabilă. Acolo unde precondiția se menține, pattern-ul este o asigurare ieftină: Anthropic descrie evaluator-optimizer ca două apeluri LLM într-o buclă, unul care generează și unul care critică, ceea ce cumpără un spor măsurabil de calitate pentru câteva secunde în plus de latență.

Modul de eșec pe care nimeni nu-l diagramează este reflecția scăpată de sub control: criticul și generatorul buclează la nesfârșit sau, mai rău, oscilează. Repararea este un plafon dur de iterații plus o oprire la lipsă de îmbunătățire, scrise în cod, nu cerute în prompt:

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 este un strat de control, nu un al optulea pattern. Învăluie oricare dintre cele șapte: un om aprobă înainte ca un pas ireversibil să ruleze. Doar 2 din cele 6 rezultate SERP de top îl acoperă cât de cât. Plasează poarta la acțiuni ireversibile, cheltuieli reale și orice părăsește sistemul tău ca comunicare externă. Tot restul ar trebui să ruleze nesupravegheat sau să nu ruleze deloc. Poarta însăși ar trebui să fie cod prost, nu un alt LLM: o coadă de aprobare, un prag de cheltuială, o listă de domenii permise. A pune un model să decidă dacă un om ar trebui să se uite anulează scopul.

Merită multi-agent 15× mai mulți tokeni? Ce spun de fapt benchmark-urile

Orchestrator-workers este al șaptelea pattern: un agent principal descompune o sarcină, delegă bucăți către agenți workeri și îmbină ce returnează aceștia. „Multi-agent" este acest pattern dus la extrem, nu o formă separată, deci întrebarea este de fapt când își câștigă orchestratorul overhead-ul.

Când ar trebui să folosești multi-agent în loc de un singur agent? Doar când un agent unic se blochează sub aproximativ 85% acuratețe pe sarcină. Acea regulă practică a circulat pe r/AI_Agents (2026-04-23) alături de studiul Google Research și se potrivește cu datele măsurate: peste acea bară, agenții adăugați adaugă cost și amplificare de erori fără să adauge acuratețe.

Iată fiecare număr publicat pe care l-am putut verifica, puse cap la cap:

O avertizare înainte să dai click: fiecare cifră Google Research de mai sus vine din postarea de blog din 2026-01-28, iar lucrarea din spatele ei (arXiv 2512.08296) a fost revizuită între timp, așa că versiunea ei curentă raportează 260 de configurații și R² = 0,373, nu 180 și 0,513 cât are blogul. Direcția se menține în ambele cazuri; cifrele exacte depind de versiunea pe care o citești.

Două dintre aceste rânduri sunt citate greșit în mod obișnuit, deci iată aritmetica. Cifra Anthropic de 15× este măsurată față de o interacțiune de chat, iar cifra lor pentru agent unic este 4×. Deci multi-agent costă aproximativ 15 / 4 = 3,75× tokenii unui agent unic, nu 15×. Iar amplificarea de erori Google Research de 17,2× pentru agenți independenți față de 4,4× pentru cei centralizați înseamnă că un orchestrator conține aproximativ 17,2 / 4,4 = 3,9× mai puțină amplificare de erori decât lăsarea agenților să ruleze nesupravegheați.

Citind analiza Anthropic pe lângă numerele Google Research, lectura noastră este că descompunabilitatea, nu numărul de agenți, este variabila care decide. Sarcina de cercetare Anthropic se împărțea curat în sub-căutări paralele, deci mai mulți agenți au ajutat. Sarcinile de planificare secvențială Google nu se împărțeau, deci mai mulți agenți și-au stat în cale unii altora.

Asta se potrivește cu ce spun practicienii odată ce sistemele ajung în producție. Pe r/AI_Agents, un fir numit „Multi agent systems are a total nightmare in production" (2026-04-23, 56 de puncte, 68 de comentarii) venea de la un OP care a livrat peste 20 de sisteme pentru clienți: „The ones that actually stay running… are almost embarrassingly simple" și „every time one agent talks to another, you lose context. It's like that game of Telephone." Comentariul de top distilează toată secțiunea: „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."

Înainte să adaugi un agent, încearcă reparările ieftine pe care Anthropic le-a măsurat: o descriere de instrument îmbunătățită a produs o scădere de 40% a timpului de finalizare a sarcinii, iar apelarea paralelă a instrumentelor a tăiat timpul de cercetare cu până la 90%. Ambele bat un al doilea agent la cost. Dacă totuși treci la multi-agent într-un instrument real, subagenții Claude Code sunt orchestrator-workers pe care îi poți inspecta linie cu linie.

Același pattern, cinci denumiri: un tabel Rosetta al framework-urilor

Aceeași patru forme apar sub denumiri diferite în documentația fiecărui vendor, iar denumirile nu se transferă între framework-uri. „magentic" și „group chat" ale Microsoft nu înseamnă nimic în OpenAI SDK până nu le traduci, iar acea taxă de traducere este un cost real pe care acest tabel îl elimină.

Cinci vendori, cinci vocabulare, trei sau patru forme reale. Costul practic apare când schimbi framework-ul: o echipă care trece de la Agent Framework de la Microsoft la OpenAI SDK trebuie să remapeze „magentic" pe agents-as-tools și „group chat" pe un graf de handoff înainte ca o singură linie de cod să se transfere. Taxonomia cu unsprezece denumiri a Google Cloud este cea mai lungă, lista cu șapte denumiri Anthropic este cea mai citată, iar cele trei denumiri din blogul Claude sunt cele pe care le vei implementa primele. Citește forma, apoi citește SDK-ul. Anteturile coloanelor sunt documentațiile însele: Anthropic, blogul Claude, OpenAI Agents SDK, Vercel AI SDK, Microsoft Learn și Google Cloud. Odată ce vezi formele, alegerea unui framework este o decizie separată; trecerea noastră în revistă a celor mai bune framework-uri de agenți AI în 2026 și comparația LangGraph vs CrewAI vs OpenAI Agents SDK acoperă acea decizie.

Când NU ar trebui să folosești deloc un workflow cu agenți?

Adesea, nu ar trebui. Cea mai votată scară de decizie de pe r/AI_Agents (2026-03-09) spune răspicat: „If if…then statements will work use that. Then if traditional workflows will work use that. Otherwise use agentic AI." Două din cele trei rezultate SERP de top sunt documentație cloud care structural nu îți poate spune să construiești mai puțin. Noi putem. Datele din acest articol arată în aceeași direcție: cele două mari câștiguri măsurate (+80,9% și +90,2%) au venit ambele din sarcini care se descompuneau curat, iar cea mai mare pierdere măsurată (−70%) a venit din forțarea agenților pe o sarcină care nu se descompunea.

Modurile de eșec sunt numite și fiecare are acum un număr atașat:

• Pierderea contextului la handoff: fiecare mesaj agent-către-agent pierde stare (plângerea „Telephone" de pe r/AI_Agents, 2026-04-23).
• Amplificare de erori: 17,2× pentru agenți independenți față de 4,4× centralizat (Google Research, 2026-01-28).
• Bucle de reflecție scăpate de sub control: plafonază iterațiile și oprește la lipsă de îmbunătățire, ca în codul de mai sus.
• Degradarea sarcinilor secvențiale: cu 39–70% mai rău când paralelizezi muncă ce nu se descompune (Google Research, 2026-01-28).
• Explozie de cost: aproximativ 15× tokeni de chat pentru un sistem multi-agent (Anthropic, 2025-06-13).

Fiecare dintre acele moduri de eșec are un plafon pe care îl poți scrie în zece linii de cod, iar plafonul este întotdeauna mai ieftin decât agentul pe care erai gata să-l adaugi.

Walden Yan de la Cognition a făcut același caz din partea constructorilor în Don't Build Multi-Agents (2025-06-12): „Share context, and share full agent traces, not just individual messages" și „Actions carry implicit decisions, and conflicting decisions carry bad results." Comparația de pe r/AI_Agents este cea la care ne întoarcem mereu: „multi agent starts looking a lot like microservices. powerful when the boundaries are real, painful when they're invented."

Cum abordează Techsy alegerea pattern-urilor

Scara de mai jos este lectura noastră a constatărilor Google Research și Anthropic plus firele practicienilor, nu un rezultat măsurat al nostru. O parcurgem de sus în jos și ne oprim la primul rând care se potrivește:

Trei lucruri decurg din datele din acest articol. Pornește secvențial, pentru că Anthropic spune să faci asta și nimic din SERP nu contrazice. Paralelizează doar ce se descompune, pentru că aceeași schimbare de coordonare măsurată la +80,9% a fost măsurată și la −70%. Și tratează un al doilea agent ca ultimă soluție, pentru că factura de tokeni este reală și amplificarea de erori este măsurată. Firul roșu este că adăugarea de agenți este o mișcare de scalare, nu una de calitate: benchmark-urile o recompensează doar acolo unde munca se împarte, iar firele practicienilor o confirmă peste tot în rest. Dacă vrei o a doua opinie despre o arhitectură înainte să o construiești, Obține o consultație gratuită.

Întrebări frecvente

Care sunt cele 7 pattern-uri pentru agenți AI?

Cele șapte sunt secvențial (prompt chaining), rutare (handoff), paralelizare (fan-out/fan-in), orchestrator-workers, reflecție (evaluator-optimizer), ReAct și plan-and-execute. Ele revin sub denumiri diferite în fiecare taxonomie de vendor, de la Anthropic la Google Cloud. Human-in-the-loop este discutat alături de ele, dar este un strat de control care învăluie oricare dintre cele șapte, nu un al optulea pattern.

Care sunt cele 4 etape ale unui workflow de agent AI?

Planifică, acționează, observă, reflectă. Modelul plănuiește pasul următor, acționează apelând un instrument, observă rezultatul instrumentului intrând în context, apoi reflectă dacă obiectivul este atins și buclează sau se oprește. Fiecare pattern din acest articol este un mod diferit de a conecta aceste patru etape.

Care este diferența dintre un workflow AI și un agent AI?

Un workflow urmează căi de cod predeterminate; un agent lasă modelul să-și conducă propriul flux de control. Regula Anthropic: workflow-uri pentru predictibilitate pe sarcini bine definite, agenți pentru flexibilitate când deciziile conduse de model sunt necesare la scară. Majoritatea sistemelor din producție sunt workflow-uri cu câțiva pași de agent în interior.

ReAct vs plan-and-execute: pe care să-l folosesc?

Folosește ReAct când pasul următor depinde de ce a returnat ultimul instrument și ruta se poate schimba în timpul rulării. Folosește plan-and-execute când ruta este predictibilă de la început și replanificarea după fiecare pas ar risipi tokeni. ReAct a măsurat +34% pe ALFWorld (Yao et al., 2022); plan-and-execute a bătut zero-shot CoT pe zece dataset-uri (Wang et al., 2023).

Am nevoie de un framework ca LangGraph pentru a folosi aceste pattern-uri?

Nu. Fiecare bloc de cod din acest articol este un apel SDK simplu, iar pattern-urile sunt anterioare framework-urilor care le numesc. Un framework își câștigă locul la persistența stării, reîncercări și trasare, nu la pattern în sine. Dacă alegi unul, comparația noastră de framework-uri acoperă compromisurile.

Cum opresc o buclă de reflecție să ruleze la nesfârșit?

Două garduri, ambele în cod: un plafon dur de iterații (folosim 4 runde) și o oprire la lipsă de îmbunătățire care se declanșează în momentul în care rescrierea criticului nu punctează mai bine decât schița curentă. Nu te încrede în prompt să încheie bucla; modelul nu are nicio idee cât costă lucrurile.

Când este suficient un singur agent?

Când depășește aproximativ 85% acuratețe pe sarcină. Acea euristică, circulată pe r/AI_Agents (2026-04-23) alături de studiul Google Research, se potrivește cu benchmark-urile: peste acea bară, agenții în plus adaugă cost și amplificare de erori fără să adauge acuratețe. Măsoară linia de bază a agentului unic înainte să proiectezi ceva mai mare.

Unde găsesc exemple de pattern-uri workflow pentru agenți AI cu cod?

Cele cinci blocuri Python de mai sus acoperă secvențial, rutare, paralelizare, ReAct și reflecție, toate ca apeluri SDK simple pe care le poți prelua direct. Pentru exemple cu aromă de vendor, Vercel AI SDK livrează TypeScript rulabil pentru fiecare pattern, iar documentația OpenAI Agents SDK acoperă handoff-uri și agents-as-tools. Linkuri către ambele sunt în lista de Surse de mai jos.

Surse

• 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); lucrare: 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 (actualizat 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)