Cuprins
Pe 9 octombrie 2026, Anthropic a adăugat în Claude Managed Agents o funcție numită dynamic workflows. Un agent poate acum să scrie singur un program care pornește mulți alți agenți, îi organizează în faze, le adună rezultatele și le combină. Serverul rulează acest program în fundal, în timp ce agentul principal continuă să lucreze sau să răspundă utilizatorului.
Funcția este în beta și se adresează lucrărilor cu multe bucăți: analiza a sute de documente, audituri, migrări, cercetare sau verificarea încrucișată a mai multor surse. Mai jos găsești cum funcționează, ce limite are și de ce o rulare marcată completed nu înseamnă automat că munca a reușit. Sursa: notele de lansare Anthropic.
Ce este Claude Managed Agents
Claude Managed Agents este platforma în care Anthropic rulează bucla agentului și găzduiește, pentru fiecare sesiune, containerul în care rulează uneltele: comenzi, fișiere, execuție de cod. Dezvoltatorul definește o singură dată agentul (model, instrucțiuni, unelte), apoi pornește sesiuni cu el.
Până acum, un agent putea împărți munca în două feluri: delega sarcini unor subagenți sau consulta un model advisor. Dynamic workflows este a treia variantă:
| Variantă | Ce se întâmplă | Când se potrivește |
|---|---|---|
| Subagenți | Agentul delegă sarcini și citește ce raportează fiecare subagent. | Câteva sarcini bine delimitate, la care agentul revine cu întrebări suplimentare. |
| Dynamic workflows | Agentul scrie un program care rulează mulți agenți în faze și le combină rezultatele. | Lucrări cu multe bucăți, lucru în paralel sau sarcini lungi care trebuie terminate mai repede. |
| Advisor | Agentul lucrează singur, dar consultă un model mai puternic la momentele importante. | Un singur agent face munca, iar planificarea sau revizia finală cer o a doua părere. |
Diferența practică față de subagenți ține de scară. O sesiune poate avea cel mult 25 de fire copil deschise în același timp, iar delegarea are un singur nivel. Firele unei rulări de workflow nu intră în această limită. Sursa: Multiagent orchestration.
Cum funcționează un workflow
Documentația definește workflow-ul ca un program pe care agentul îl scrie ca să ruleze mulți agenți și să combine ce returnează aceștia. Execuția unui workflow se numește workflow run și are trei niveluri:
- Rularea: serverul execută programul în fundal. O sesiune poate avea mai multe rulări deschise în același timp.
- Fazele: programul își poate împărți munca în etape cu nume, de exemplu „Citește contractele”. Progresul se urmărește după fazele începute și încheiate.
- Firele de agent: în fiecare fază, programul pornește agenți. Fiecare lucrează în propriul fir al sesiunii, pe un prompt scris de program.
Programul poate rula agenți în paralel și poate transmite rezultatul unui agent altuia. Tot el decide singur ce agenți urmează și ce prompt primesc. Poate repeta un pas, de exemplu poate revizui o ciornă până trece o verificare sau până se termină un număr fix de runde. Poate trata și un agent care a eșuat sau poate lăsa eșecul să oprească rularea.
Rezultatele agenților ajung la program, nu la agentul principal. Acesta rămâne liber să comunice cu utilizatorul și să verifice progresul rulărilor. Când o rulare se încheie, agentul principal primește o tură în care citește ce a făcut rularea, apoi poate răspunde sau poate porni o rulare nouă. Sursa: Workflow runs.
Agenții unei rulări pot fi de două feluri:
- Agenți inline, definiți chiar de program, care folosesc modelul, uneltele și serverele MCP ale agentului principal.
- Agenți predefiniți, creați dinainte și puși într-o listă de cel mult 20. Ei își păstrează configurația proprie, deci pot folosi, de exemplu, un model mai ieftin pentru sarcinile simple.
Cum se activează
Funcția se pornește în definiția agentului, prin blocul multiagent:
{
"multiagent": {
"type": "multiagent_20261001",
"workflows": { "type": "enabled" }
}
}
Pe acest tip, workflow-urile și subagenții sunt activate implicit. Pentru workflow-uri fără subagenți, se adaugă "subagents": {"type": "disabled"}. Ca toată platforma Managed Agents, funcția cere antetul beta managed-agents-2026-04-01.
Nu există un apel API care pornește o rulare. Utilizatorul descrie munca într-un mesaj, iar agentul decide dacă merită o rulare. De aceea, documentația recomandă să-i spui agentului, în instrucțiunile de sistem, când să folosească un workflow și când să lucreze singur. Exemplul oficial, tradus:
Analizezi contracte. Când ți se cere să analizezi mai mult de câteva contracte,
pornește un workflow run care le citește în paralel și combină concluziile.
Analizează singur unul sau două contracte, fără un run.
Tot prin instrucțiuni se poate stabili cum lucrează rularea: câte un agent pe document și un al doilea agent care verifică fiecare document, ce se întâmplă când un agent eșuează și cât poate dura rularea.
Limitele unei rulări
| Limită | Valoare | Ce se întâmplă la limită |
|---|---|---|
| Agenți care lucrează simultan într-o rulare | 64 | Rularea nu mai pornește alți agenți până nu termină unul. Anthropic precizează că numărul nu e garantat și se poate schimba. |
| Agenți porniți pe toată durata unei rulări | 1.000 | Rularea se încheie cu eroarea thread_limit_error. |
| Durata unei rulări | 24 de ore implicit sau cât stabilește agentul | Rularea se încheie cu eroarea timeout_error. |
| Rulări deschise simultan într-o sesiune | 10 implicit | Serverul refuză pornirea unei rulări noi. Rulările puse pe pauză intră și ele la socoteală. |
Limita de 1.000 se referă la agenții ceruți de program. Serverul poate relua un agent eșuat pe un fir nou, așa că o rulare poate avea, în total, mai mult de 1.000 de fire.
O rulare nu are un preț separat. Tokenii consumați de agenți se facturează ca restul sesiunii, la tariful fiecărui model, și intră în bugetul sesiunii. Când bugetul se epuizează, toate rulările deschise se opresc temporar și pornesc din nou dacă bugetul e mărit sau eliminat. Cererile către model contează și la limitele de rată ale organizației. Sursa: Workflow runs, „Budgets and limits”.
„Completed” nu înseamnă „reușit”
La final, fiecare rulare primește un rezultat: completed, stopped (oprită de agent sau la arhivarea sesiunii) sau error, cu un tip precis, de exemplu timeout_error sau program_error. Detaliul important pentru cine construiește sisteme cu agenți este definiția lui completed. Documentația spune explicit (în traducere):
Workflow-ul a terminat de rulat. Rezultatul nu spune dacă munca a reușit. O rulare se poate încheia
completedchiar dacă munca de pe firele ei a eșuat sau un fir nu a putut fi creat.
Cu alte cuvinte, completed descrie programul, nu calitatea rezultatului. Ca să afli ce nu a mers, trebuie citite evenimentele fiecărui fir al rulării. Nici evenimentul de final al unei faze nu spune dacă munca din acea fază s-a încheiat cu succes.
Documentația mai face o precizare cu efect direct asupra designului: o rulare poate crea mai multe fire pentru aceeași bucată de muncă, deci uneltele apelate de agenți trebuie să suporte să fie apelate de două ori. O unealtă care trimite un e-mail, plătește o factură sau scrie o înregistrare într-o bază de date trebuie să recunoască o cerere repetată și să nu o execute din nou.
Este aceeași lecție ca în studiul despre agenții AI care opresc crash-ul fără să repare vulnerabilitatea: un indicator de stare nu ține locul unei verificări a rezultatului.
Un exemplu: verificarea unei liste de componente
Exemplul următor este ipotetic. O echipă vrea să verifice o listă de componente (BOM) cu 400 de poziții, comparând valorile din listă cu foile de catalog încărcate în sesiune. Pornind de la recomandările din documentație, instrucțiunile agentului ar putea arăta astfel:
Verifici liste de componente (BOM) pentru proiecte electronice.
Când primești o listă cu mai mult de câteva componente, pornește un workflow run:
un agent pentru fiecare componentă compară valorile din BOM cu foaia de catalog,
apoi un al doilea agent verifică fiecare componentă, nu doar pe cele semnalate.
Un agent care eșuează nu trebuie să oprească rularea: trece componenta la „neverificată”.
Dă rulării o limită de o oră.
Verifică singur listele cu una sau două componente.
Cu un agent și un verificator pentru fiecare poziție, rularea ar porni circa 800 de agenți, deci aproape de limita de 1.000. Pentru o listă mai mare, fiecare agent ar trebui să primească mai multe poziții. Rândul cu componentele „neverificate” face ca un rezultat completed să vină cu o listă explicită a ce lipsește, în loc să ascundă eșecurile.
Ce merită reținut
- Folosește rulări doar unde este nevoie de ele. Fiecare agent consumă tokeni. Sarcinile mici și întrebările simple le rezolvă mai ieftin un singur agent.
- Setează un buget de sesiune și o limită de timp. Bugetul se stabilește la crearea sesiunii și acoperă și rulările. Durata implicită de 24 de ore poate fi scurtată doar de agent, prin instrucțiuni.
- Tratează
completedca „programul s-a terminat”. Cere în instrucțiuni o listă a elementelor neacoperite și verifică firele eșuate. - Fă uneltele sigure la apeluri repetate. O rulare poate relua aceeași bucată de muncă pe un fir nou.
- Măsoară efectul. Compară rezultatele, costul și durata față de un singur agent, pe aceleași sarcini, cum am descris în articolul despre reguli explicite și gestionarea contextului.
Funcția este în beta, iar unele comportamente, de exemplu ordinea fazelor sau limita de 64 de agenți simultan, sunt descrise de Anthropic ca valabile acum, dar negarantate. Merită verificată documentația înainte de a construi pe ele. Sursa: Multiagent orchestration, „Dynamic workflows”.
