Agenți AI multi-agent: patterns pentru business real, nu pentru demo-uri

Un agent AI singular ajunge surprinzător de departe pentru o problemă bine delimitată. Devine fragil rapid când îi ceri să facă mai multe lucruri foarte diferite în același flux. Articolul ăsta tratează când și cum treci la o arhitectură multi-agent, ce pattern-uri funcționează în business real, și ce am învățat construind sisteme multi-agent cu memorii distribuite și soluții de analiză automată de transcrieri.

Când un singur agent ajunge la limită

Semnele care apar tipic:

• Promptul de sistem trece de 4.000 de tokens pentru că încerci să acoperi toate cazurile în el. Modelul devine mai puțin atent la fiecare regulă.
• Agentul are 12-15 tool-uri. Selecția corectă a tool-ului scade vizibil când lista crește.
• Aceeași sesiune trebuie să facă lucruri foarte diferite: să clasifice, să caute, să redacteze, să apeleze sisteme externe. Costurile cresc pentru că ultimul pas plătește pentru contextul tuturor pașilor anteriori.
• Vrei reuse-uri: aceeași logică de "rezumare a unei conversații" e folosită din mai multe locuri și ar trebui să fie un component, nu o secțiune din promptul fiecărui agent.

Când 2 sau mai multe din astea sunt adevărate, e momentul să faci pasul către multi-agent.

Pattern principal: coordinator plus specialiști

Cel mai comun pattern (și cel pe care îl folosim la Ran·AI ca punct de plecare pentru majoritatea sistemelor):

• Un coordinator primește cererea utilizatorului. Decide ce specialiști sunt relevanți, le trimite sarcini cu context curat, agregă răspunsurile, decide dacă mai e nevoie de un pas sau dacă răspunsul e gata.
• Specialiști: agenți cu prompt sistem scurt, tool-uri limitate, focus îngust. De exemplu un "summarizer", un "classifier", un "researcher", un "writer".

Avantajele față de single-agent monolitic:

• Prompturi mici, ușor de iterat per specialist.
• Modele diferite per rol. Haiku pentru clasificare, Sonnet pentru redactare, Opus pentru coordonare. Cost mai mic la calitate egală sau mai bună.
• Reuse: același "summarizer" e folosit din 5 fluxuri diferite. Modificare într-un loc, beneficiu peste tot.
• Testare izolată: poți testa specialiștii separat pe seturi de evaluări mici și focusate.

Memory lanes: pattern-ul pe care îl folosim la Ran·AI

Pattern-ul clasic single-agent presupune o singură memorie (context, plus poate un RAG). Pentru sisteme reale, asta nu ajunge.

Pattern-ul pe care îl folosim noi (și care e diferit de literatura standard din 2024): fiecare agent are acces la mai multe memory lanes. Un memory lane e o sursă cu reguli proprii de retrieval, prioritizare, și expirare. Exemple de lanes pe care le folosim:

• Memorie permanentă de companie (Obsidian la nivel de organizație, expusă prin MCP). Conține politici, decizii arhitecturale, lessons learned.
• Memorie de sesiune: ce s-a întâmplat în conversația curentă. Expiră la finalul sesiunii.
• Memorie de utilizator: preferințe, istoric de interacțiuni, contexte recurente. Persistă între sesiuni.
• Memorie operațională: date live din sisteme business (CRM, ticketing, ERP) accesate la momentul cererii.
• Memorie de știință: knowledge base cu fapte verificate (politici legale, ghiduri de produs, manuale).

Coordinator-ul decide ce lane e relevantă pentru un anumit pas. Specialistul primește contextul filtrat. Asta evită "context pollution" (un singur retrieval care amestecă toate tipurile de informație și diluează relevanța) și permite reguli diferite de prioritizare per tip de memorie.

Comunicarea între agenți

Trei opțiuni practice:

1. Coordinator invocă specialiști ca tool-uri. Modelul coordinator primește ca tool-uri funcții care în spate cheamă specialiști. E simplu, ușor de debug, latență previzibilă. E ce folosim cel mai des.

2. Message passing cu queue. Specialiștii rulează asincron, comunică prin mesaje într-un broker (Redis, NATS). Util când proces e lung sau ai nevoie de paralelism real. Adaugă complexitate operațională.

3. Multi-turn handoff. Coordinator-ul "predă" complet controlul unui specialist, care la rândul lui poate preda altcuiva. Util pentru fluxuri unde sub-tasks sunt foarte diferite. Atenție la pierderea de context la handoff.

Confirmare umană pentru acțiuni cu efect

Asta nu e opțional pentru orice sistem care modifică starea în mediu real.

• Specialistul care vrea să execute o acțiune (creează tichet, trimite email, postează tranzacție) construiește payload-ul, dar nu îl execută direct.
• Coordinator-ul primește payload-ul propus și îl prezintă utilizatorului ca preview.
• Utilizatorul confirmă sau editează.
• La confirmare, execuția merge mai departe. Audit log scrie cine a confirmat și ce s-a executat.

Pentru acțiuni reversibile cu impact mic (de exemplu o căutare în CRM), confirmarea nu e necesară. Pentru orice cu efect ireversibil sau cu impact financiar, e obligatorie.

Observabilitate

Fără asta, sistemele multi-agent devin imposibil de debug. Ce loghezi pentru fiecare sesiune:

• Cererea inițială a utilizatorului.
• Fiecare apel către un specialist: rol, input, output, model folosit, tokeni, latență, cost.
• Decizia coordinator-ului: ce specialiști a invocat, în ce ordine, cu ce context.
• Acțiunile propuse și ce a confirmat utilizatorul.
• Răspunsul final și satisfacția (din feedback explicit sau implicit prin continuare).

Unelte utile: OpenTelemetry pentru tracing distribuit (spans per agent), Langfuse sau Helicone pentru AI-specific. Costul de a adăuga observabilitate de la început e mic. Costul de a o adăuga după ce ai 10 specialiști deja în producție e mare.

Exemplu: analiza automată de transcrieri

Unul din sistemele pe care le construim la Ran·AI e o soluție multi-agent pentru analiza automată de transcrieri de apeluri. Procesul implică pași foarte diferiți: extragere de entități, clasificare a stărilor emoționale, identificare de acțiuni de urmat, compararea cu obiectivele apelului, redactarea unui raport pentru manager.

Arhitectura simplificată folosește un coordinator care recunoaște tipul de apel, invoacă specialiști relevanți (un classifier emoțional, un extractor de entități, un evaluator de criterii), agregă rezultatele, și un writer specializat redactează un raport consistent. Modelul ales per specialist e diferit. Costul total pe apel e o fracțiune din ce ar fi cu un singur Opus monolitic.

Lecția practică: pentru orice flux unde cererea utilizatorului trece prin etape calitativ diferite (clasificare, retrieval, redactare), multi-agent dă rezultat mai bun la cost mai mic decât single-agent încercând să facă tot.

Capcanele frecvente

Prea mulți specialiști de la început. Începe cu 2-3, adaugă pe parcurs bazat pe ce vezi în log-uri. 8 specialiști pentru 50 de utilizatori înseamnă debugging nefericit.

Coordinator prea complicat. Promptul lui ar trebui să fie scurt. Dacă crește peste 2.000 de tokens, probabil ai amestecat reguli care aparțin unor specialiști distincți.

Lipsa de context la handoff. Când coordinator-ul invoacă un specialist, trimite-i exact contextul de care are nevoie, nu toată istoria conversației. Specialistul merge mai bine cu prompt curat.

Lipsa de feedback pe deciziile coordinator-ului. Dacă utilizatorii spun "răspunsul a sărit peste pasul X", contextul vine din analiza log-urilor. Construiește sistem de feedback structurat.

Lipsa testelor per specialist. Fiecare specialist e o unitate testabilă. Set de evaluări mic, cu cazuri reprezentative. Schimbi specialistul, rulezi setul, vezi regresia. Fără asta, nu poți itera cu încredere.

Asume că Claude e suficient pentru toate. Pentru sarcini foarte specifice (de exemplu detecția de tonalitate vocală în audio brut, sau extracție din documente cu structură foarte specializată), modele dedicate sau combinații pot fi mai bune. Coordinator-ul orchestrează amestec de modele.

Cum începi practic

1. Identifică un flux cu pași calitativ diferiți. Dacă fluxul e omogen, rămâi la single-agent.
2. Sparge fluxul în 2-3 specialiști. Definește exact ce face fiecare, ce input primește, ce output produce.
3. Construiește un coordinator simplu. Tool-uri pentru fiecare specialist. Logică conditionată în prompt sistem.
4. Definește memory lanes. Care lane e relevantă pentru care specialist?
5. Adaugă observabilitate de la prima sesiune. Tracing distribuit, log pe fiecare apel.
6. Lansează la grup mic. Vezi unde coordinator-ul alege prost specialiști, vezi unde un specialist lipsește. Iterează.
7. Adaugă confirmare umană pentru toate acțiunile cu efect înainte de a extinde audiența.

Dacă vrei o discuție despre o arhitectură multi-agent pentru un proces concret, scrie-ne la contact@ranresults.com. Răspundem cu o opinie cinstită despre fezabilitate, plus o propunere de arhitectură.