# Nu construi un agent. Construiește fabrica de agenți.
Oricine poate construi un agent AI într-un weekend. Un model bun, câteva tool-uri, un prompt de sistem decent — și ai un demo care impresionează în ședința de luni. Am scris deja despre [diferența dintre un model și un agent](/ro/blog/ai-model-vs-agent) și despre [cum arată agenții în producție](/ro/blog/ai-agents-2026), așa că nu reiau partea aia.
Problema reală apare la a doua întrebare, cea pe care demo-ul de weekend nu o atinge niciodată: ce se întâmplă când **zece echipe** vor fiecare agentul lor? Fiecare cu acces la CRM, la tichete, la baze de date. Fiecare cu propriile chei API, propriile prompturi, propria idee despre ce înseamnă „merge". Fără un răspuns la întrebarea asta, obții ce văd acum în multe companii: o grămadă de agenți-pilot care nu ajung niciodată în producție, pentru că nimeni nu poate spune cine are voie la ce, cât de bine funcționează și ce se strică la următorul release.
Răspunsul la ea nu e „încă un agent", ci o **arhitectură de agenți** — fabrica internă prin care orice echipă poate lansa agenți guvernați, testați și cu acces controlat la sistemele companiei. Articolul ăsta descrie cele patru piese ale arhitecturii și de ce ai nevoie de fiecare.
## Cele două straturi
Prima clarificare, pentru că aici se încurcă majoritatea discuțiilor: agentul pe care îl vede utilizatorul și platforma de dedesubt sunt straturi diferite, cu probleme diferite.
Stratul de aplicație e ce construiești pentru un caz de folosință concret: orchestrare cu sub-agenți, RAG peste documentele relevante, porți de aprobare unde un om validează acțiunile sensibile. E stratul pe care l-am construit și noi în proiectele cu clienți și despre care se scriu 95% din articolele despre agenți.
Stratul de platformă e ce face ca **al doilea, al cincilea și al zecelea** agent să nu ia totul de la zero. El răspunde la trei întrebări pe care aplicația nu are cum să le rezolve singură: cine are voie la ce sistem, cât de bun e un agent înainte să-l lansezi și cum află echipa B că agentul echipei A există deja.
Restul articolului ia pe rând piesele stratului de jos.
## Catalogul de agenți: registru plus evaluări, nu wiki
Prima piesă sună banal și e cea mai subestimată: un **registru intern de agenți**. Fiecare agent are o intrare cu descriere, tool-urile la care are acces, echipa owner și versiunea curentă. Echipele îl consultă înainte să construiască ceva nou — exact ca un registru de servicii sau un catalog de API-uri interne.
| Câmp | Exemplu |
|---|---|
| Nume | `support-triage-agent` |
| Descriere | Triază tichetele de suport și propune un răspuns |
| Owner | Echipa Customer Platform |
| Versiune | 1.4.2 |
| Tool-uri (prin gateway) | `crm.search` · `tickets.update` · `kb.retrieve` |
| Scoruri evaluări | calitate 92 · corectitudine 96 · siguranță 100 |
| Ultima regresie | trecută · 27 august 2026 |
Diferența față de un wiki e ultimele două rânduri. Un catalog fără evaluări e o listă de promisiuni; un catalog cu evaluări e un contract. Pentru fiecare agent există **seturi de teste** — scenarii reale de intrare cu rezultate așteptate — și scoruri pe trei axe: calitate (cât de utile sunt răspunsurile), corectitudine (câte afirmații sunt factual adevărate, câte acțiuni sunt cele corecte) și siguranță (refuză ce trebuie să refuze, nu scurge date între clienți, nu execută acțiuni în afara mandatului).
Regula care leagă totul: **nu publici o versiune nouă în catalog dacă nu trece evaluările.** Inclusiv — mai ales — suita veche. Un agent care la v1.4 rezolvă un caz nou dar strică trei cazuri care mergeau la v1.3 nu se lansează. Asta e CI/CD, aplicat la agenți:
Partea nedeterministă e singura noutate reală. Un test de cod e binar; un răspuns de agent e „suficient de bun" sau nu. De aceea evaluările combină verificări exacte (a apelat tool-ul corect? a respectat formatul?) cu **LLM-as-judge** — un model care punctează răspunsul după o rubrică scrisă de oameni. Nu e perfect, dar e consistent, ieftin și rulează la fiecare release, ceea ce un review uman nu poate.
În AWS, piesa asta există ca serviciu — evaluările din Amazon Bedrock AgentCore — dar se construiește la fel de bine ca pipeline propriu: un set de scenarii în git, un job care rulează agentul pe ele și un judge care punctează. Important e gate-ul, nu unealta.
## Gateway: un singur loc prin care agenții ating lumea
A doua piesă rezolvă o problemă de aritmetică. Trei agenți care vorbesc direct cu cinci sisteme înseamnă cincisprezece integrări: cincisprezece locuri unde se gestionează credențiale, cincisprezece locuri de auditat, cincisprezece implementări de rate limiting — de obicei zero. Fiecare agent nou înmulțește problema.
Gateway-ul o transformă din N × M în N + M: agenții vorbesc cu un singur strat, iar stratul ăla știe **cine are voie la ce**.
Concret, gateway-ul centralizează patru lucruri pe care altfel le reimplementează fiecare echipă prost și diferit: **autentificarea** (agenții primesc identități, nu chei API copiate prin prompturi), **autorizarea** (agentul de suport vede tichetele, nu și salariile), **rate limiting-ul** (un agent intrat în buclă nu pune CRM-ul în genunchi) și **logging-ul** (fiecare apel de tool, cu identitatea agentului atașată — singurul mod în care răspunzi la „cine a modificat înregistrarea asta?").
A doua funcție, mai puțin evidentă dar enormă în practică: gateway-ul **traduce API-uri existente în tool-uri MCP fără să le rescrii**. Ai un REST API intern sau o funcție Lambda? O descrii la nivel de gateway și devine un tool pe care orice agent compatibil îl poate apela. În AWS, exact asta face AgentCore Gateway; același pattern se construiește și standalone.
## Serverele MCP: stratul care expune efectiv tool-urile
Sub gateway stau serverele care chiar expun tool-urile și datele: CRM, tichete, documente, baze de date. Am scris despre [MCP din perspectiva unui setup local](/ro/blog/mcp-lm-studio); la nivel enterprise logica e identică, doar miza crește — MCP e ce oprește platforma să devină o colecție de integrări proprietare.
Pentru că protocolul e standard, serverul MCP pentru tichete scris de o echipă e refolosibil de orice agent din companie, indiferent de framework-ul cu care e construit agentul. Iar când vendorii tăi expun ei înșiși servere MCP — tot mai frecvent — le pui în spatele aceluiași gateway și primesc aceleași reguli de acces și același audit ca tool-urile interne. Cuplul gateway + MCP e ce transformă „integrare" dintr-un proiect de trei săptămâni într-o înregistrare de configurare.
## RAG: partajat, nu reinventat per agent
Ultima piesă e cea pe care o știi deja — cu o singură corecție de poziționare. RAG apare în ambele straturi, dar altceva se construiește în fiecare: aplicația decide *ce întreabă și ce face cu răspunsul*; platforma deține *conductele* — ingestia documentelor, indexarea, embedding-urile, și mai ales **filtrarea pe permisiuni la momentul căutării**. Dacă fiecare echipă își face propriul pipeline de ingestie, obții cinci indexuri care îmbătrânesc în ritmuri diferite și cel puțin unul care servește documente confidențiale cui nu trebuie. Retrieval-ul e infrastructură, ca baza de date; rubrica de „ce documente are voie să vadă agentul ăsta" aparține platformei, nu bunelor intenții ale fiecărui prompt.
## De ce ai nevoie de o arhitectură de agenți
Pentru că niciuna dintre problemele de mai sus nu se rezolvă în interiorul unui agent. Poți scrie cel mai bun agent din lume și tot nu ai răspuns la „cine are voie la ce", „cât de bun e înainte de release" și „ce se strică la următorul" — astea sunt proprietăți ale sistemului din jurul agenților, nu ale vreunui agent anume.
Și dacă te uiți la cele patru piese împreună, observi că niciuna nu e despre AI în sens strict. Catalogul e governance. Evaluările sunt QA. Gateway-ul e securitate și networking. RAG-ul partajat e platformă de date. Modelul — partea „AI" — e o dependență, nu produsul. De-asta problema e una de arhitectură, nu de prompturi mai bune.
Asta e, cred, cea mai utilă lentilă pentru momentul de față: suntem cu agenții unde era software-ul înainte de DevOps. Toată lumea știe să scrie unul; aproape nimeni nu are pipeline-ul care îi dă drumul în producție în siguranță, îl măsoară și îl retrage când decade. Diferența dintre demo și producție nu e un model mai bun — e arhitectura din jurul lui.
Și ordinea practică, dacă pornești de la zero, e inversă față de entuziasm: întâi un gateway cu un singur server MCP în spate și logging pe fiecare apel. Apoi un set de evaluări pentru primul agent — chiar și 30 de scenarii bat zero. Catalogul vine al treilea, când ai ce pune în el. RAG-ul partajat, când a doua echipă cere aceleași documente ca prima.
Un agent care merge în demo e un weekend. O fabrică prin care zece echipe lansează agenți fără să-și dea foc una alteia e o arhitectură. Dacă ești în punctul în care primul există și a doua lipsește, [hai să vorbim](/contact).