Ce înseamnă, de fapt, Agentic AI Architecture?

Expresia englezească este ambiguă. Citită superficial, ea poate sugera o „arhitectură agentică” — poate chiar o arhitectură inteligentă —, ca și cum arhitectura însăși ar poseda inteligență, autonomie sau capacitatea de a acționa. Nu acesta este sensul pe care îl folosesc aici. Formula trebuie desfăcută ca architecture of agentic AI systems: arhitectura unor sisteme de inteligență artificială ale căror componente decisive sunt agenți evoluați.

O arhitectură nu devine inteligentă numai pentru că include componente inteligente. Ea poate fi adaptabilă, reconfigurabilă, context-aware sau capabilă să susțină autonomie, dar acestea sunt proprietăți arhitecturale care trebuie definite și verificate separat. Inteligența aparține comportamentului sistemului și, în primul rând, agenților săi: ei interpretează obiective, construiesc planuri, aleg unelte, consultă memorie și cunoaștere, evaluează rezultate și își modifică traseul în timpul execuției.

Diferența față de arhitecturile cu agenți pe care le-am studiat în urmă cu cincisprezece sau douăzeci de ani nu constă în simpla prezență a agenților. Nici autonomia limitată, cooperarea, negocierea, organizarea multi-agent, obiectivele ori contextul nu sunt idei noi. Noutatea este tipul de componentă introdus în arhitectură: un agent construit în jurul unui model generativ capabil să lucreze cu limbaj natural, să combine cunoștințe eterogene, să genereze dinamic planuri și cod, să folosească instrumente externe și să-și revizuiască deciziile pe baza rezultatelor intermediare.

O simplă constatare: interoperabilitatea (fie ea cea semantică, securitatea, autorizarea sau încrederea), care ne dădea atâtea bătăi de cap în urmă cu douăzeci de ani, pare astăzi aproape absorbită în însăși definiția agentului. Acesta trebuie să-și declare capabilitățile, să poată descoperi și utiliza unelte și să comunice cu alți agenți prin interfețe și protocoale comune. Problemele nu au dispărut, dar s-au mutat la un alt nivel.

Acest nou agent nu anulează istoria sistemelor multi-agent; o continuă pe o bază tehnologică radical diferită. Tocmai această diferență justifică apariția unei noi familii în lunga succesiune a arhitecturilor software. Nu pentru că arhitectura ar fi devenit ea însăși inteligentă, ci pentru că trebuie să organizeze, limiteze și facă inteligibil comportamentul unor componente care dispun de capacități cognitive incomparabil mai mari și mai puțin previzibile decât agenții programați prin reguli, planuri sau modele BDI explicite.

O corecție adusă propriului meu pesimism

În paginile despre istoria și viitorul Ingineriei Software am vorbit despre declinul formei sale clasice. Nu software-ul era în declin, ci imaginea unei discipline autonome, cu granițe relativ clare, cu metode prescrise și cu un traseu ideal de la specificație la implementare. Agile a slăbit prestigiul metodologiilor grele, DevOps a absorbit dezvoltarea în operare, cloud-ul a transformat aplicația în serviciu permanent, iar inteligența artificială generativă a părut să reducă programarea la formularea unei intenții în limbaj natural.

Lectura despre Agentic AI Architecture nu anulează această interpretare, dar o completează. Forma clasică a disciplinei se dizolvă, însă problema inginerească revine mai dificilă decât înainte. Un model lingvistic poate propune un plan, poate alege un instrument, poate genera cod și poate evalua un rezultat. Dar tocmai pentru că toate acestea se produc probabilistic și, uneori, imprevizibil, sistemul care îl înconjoară trebuie proiectat cu o rigoare sporită. Doamne ferește să dezvoltăm, cu o asemenea arhitectură, o aplicație pentru ghidarea rachetelor spațiale!

Se schimbă astfel locul în care se află dificultatea. Nu mai este suficient să proiectăm algoritmul și structura datelor. Trebuie să proiectăm spațiul în care un sistem poate lua decizii, poate folosi unelte, își poate modifica strategia și poate învăța din rezultate fără a ieși din limitele acceptabile ale siguranței, costului și responsabilității.

De la descompunerea funcționalității la descompunerea deciziilor

Ideea cea mai fertilă a numărului InfoQ mi se pare distincția dintre microservicii și agenți. Microserviciile au descompus funcționalitatea: fiecare serviciu primea o responsabilitate, controla anumite date și comunica prin interfețe bine definite. Oricât de complex devenea ansamblul, traseul unei cereri era, în principiu, cunoscut și codificat dinainte.

Sistemul de IA agentică descompune altceva: decizia. Nu i se prescrie întregul drum de urmat. În funcție de scop, context, rezultate intermediare și evaluări, el hotărăște la execuție ce agent sau ce unealtă trebuie folosită, în ce ordine, dacă este nevoie de o nouă încercare și când rezultatul poate fi acceptat.

Aceasta este o schimbare profundă a obiectului proiectării. În sistemele clasice proiectam fluxuri de control; în sistemele de IA agentică proiectăm condițiile în care fluxul de control poate fi construit dinamic. Arhitectul nu mai trasează fiecare drum posibil, ci definește spațiul drumurilor permise, instrumentele disponibile, criteriile de evaluare și granițele dincolo de care agentul nu poate trece.

Ce se schimbă față de microservicii?

Noua arhitectură nu înlocuiește microserviciile și cloud-ul. Agenții continuă să folosească ca instrumente (micro)servicii, baze de date, cozi de mesaje, API-uri și infrastructuri de observabilitate. Noutatea este stratul decizional adăugat peste acestea. De aceea tranziția nu va fi o ruptură bruscă, ci o suprapunere: aceste arhitecturi vor crește pe fundațiile sistemelor distribuite deja existente.

Un nucleu probabilistic într-un înveliș determinist

Un model lingvistic nu este un serviciu determinist. Aceeași solicitare poate produce răspunsuri diferite, iar un rezultat convingător lingvistic poate fi fals, incomplet sau incompatibil cu regulile sistemului. Din acest motiv, ieșirea LLM-ului trebuie tratată nu ca un adevăr și nici ca o comandă executabilă direct, ci ca o intrare într-un verificator.

Abordarea susținută de autorii eMag-ului este inginerească: modelul probabilistic trebuie încadrat într-un mecanism controlat. Agentul poate propune un plan, dar execuția trebuie realizată prin unelte cu interfețe explicite, permisiuni limitate și rezultate verificabile. Codul generat trebuie executat într-un mediu izolat; rezultatele trebuie testate; fiecare pas important trebuie înregistrat; încercările trebuie limitate; iar atunci când încrederea scade, sistemul trebuie să revină la un traseu determinist sau la un operator uman.

În această formulă recunosc o revenire a spiritului Ingineriei Software. Nu îi cerem modelului să devină determinist, ceea ce ar însemna să-i anulăm avantajul. Îi folosim flexibilitatea acolo unde este utilă și înconjurăm nedeterminismul cu structuri care fac sistemul testabil, auditabil, recuperabil și, pe cât posibil, previzibil.

De la lanțuri la grafuri și apoi la cod

Evoluția mecanismelor care înconjoară agenții este ea însăși o mică istorie a maturizării inginerești. Primele aplicații legau mai multe prompturi într-un lanț liniar: clasificare, recuperare de informație, generare. Erau ușor de construit, dar fragile. O eroare timpurie se transmitea până la capăt fără mecanisme reale de recuperare.

Grafurile au introdus ramificații, reluări, paralelism, stări explicite și validări. Fluxul a devenit inspectabil și modificabil, iar agenții specializați au putut fi coordonați de un orchestrator. Dar, pe măsură ce scenariile au crescut, grafurile au riscat să devină ele însele complicate, rigide și greu de întreținut.

Următoarea etapă tratează codul ca mecanism de raționament și verificare. Agentul poate genera SQL, Python sau alte forme executabile, le poate rula într-un sandbox, poate observa eșecul și poate corecta soluția. Nu înseamnă că orice cod corect sintactic este și corect semantic. Dar compilarea, testele, aserțiunile și simularea oferă bucle de feedback mult mai stricte decât evaluarea unui text liber.

Patru elemente ale unui mecanism robust

• Sandbox de execuție: un spațiu izolat în care codul poate fi rulat fără a compromite sistemul real.
• Instrumentare și jurnalizare: înregistrarea pașilor, rezultatelor, erorilor și stărilor intermediare.
• Mecanism de validare: teste, aserțiuni, reguli de business, constrângeri de securitate și conformitate.
• Buclă de rafinare: corectarea controlată a soluției, cu limite de timp, cost și număr de încercări.

Este semnificativ că maturizarea agenților nu conduce de la Ingineria Software spre magie, ci de la improvizația prompturilor spre arhitectură, stări, protocoale, validare și mecanisme de recuperare. Meseria se deplasează de la prompt designer către system architect.

Contextul ca nucleu al stării universului agentului

În numărul InfoQ, contextul este tratat ca infrastructură pentru raționament: informația selectată, filtrată, ordonată și actualizată înainte de a ajunge la model. Această formulare îmi este familiară, dar legătura cu propriile mele cercetări este mai puternică decât am spus inițial. În proiectarea bazată pe agenți, contextul este nucleul stării universului pe care agentul trebuie să îl perceapă, să îl interpreteze și asupra căruia să poată acționa. Agentul nu operează asupra realității integrale, ci asupra unei reprezentări relevante a acesteia.

În lucrările din 2003 despre Agent-Based Modeling of Virtual Environments și despre agenții bazați pe percepție virtuală, problema era deja aceea a construirii lumii accesibile agentului. Câmpul de percepție, nimbul entităților, degradarea informației cu distanța și transformarea percepțiilor în concepte de acțiune delimitau universul efectiv al agentului. Nu tot ceea ce exista în mediul virtual ca oglindă a realității devenea automat parte din starea sa internă.

Mai târziu, în Strengthening Context-Awareness of Virtual Species in Digital Ecosystems, contextul a fost extins la mai multe fațete ale realității modelate — clinică, ambientală, emoțională/BDI și socială — și a fost obținut prin agenți de colectare și un agent de integrare. Astfel, contextul nu mai era doar o anexă informațională, ci o construcție distribuită, produsă și întreținută de mecanismele prevăzute de arhitectură.

Context adaptabil și spațiu de stare mutabil

Adaptarea nu înseamnă numai actualizarea valorilor unor variabile de stare într-o schemă fixă. Realitatea se modifică, dar se modifică și obiectivele agentului. Când obiectivul se schimbă, unele informații devin inutile, altele devin indispensabile, iar spațiul variabilelor de stare trebuie el însuși reconfigurat. Aceasta este o adaptare structurală, nu doar parametrică.

În Supporting Adaptability in Agent-Based Digital Healthcare Ecosystem, adaptabilitatea era legată de relația continuă dintre realitate și reprezentarea ei digitală, în paradigma R2V2R, precum și de evoluția organismelor virtuale într-un ecosistem multi-agent. În Evolution of Digital Species by Using Mutable Contexts, ideea devine explicită chiar în titlu: speciile dintr-un ecosistem digital pot să evolueze folosind contexte mutabile.

Această distincție este importantă pentru arhitectura actuală a sistemelor de IA agentică. Un context engine care doar înlocuiește date vechi cu date noi rămâne insuficient. El trebuie să poată modifica modelul contextului: să adauge surse, variabile, relații și constrângeri cerute de noul obiectiv și să elimine elementele care nu mai contribuie la decizie. Altfel, agentul rămâne prizonierul unei ontologii a problemei stabilite prea devreme.

Cine modifică universul relevant al agentului?

Întrebarea arhitecturală decisivă este cine realizează această restructurare. Prima posibilitate este agentul adaptabil: el își observă propriile rezultate, detectează insuficiența contextului, caută surse noi, își modifică reprezentarea internă și își procură uneltele necesare noului univers. Această soluție oferă autonomie, dar face mai dificilă trasabilitatea, deoarece agentul devine simultan utilizator și proiectant al propriei sale lumi informaționale.

A doua posibilitate este un context manager, situat la un nivel arhitectural superior. Acesta cunoaște obiectivele, politicile, drepturile de acces, sursele disponibile și regulile de expirare; construiește contextul adecvat pentru fiecare agent și îl modifică atunci când se schimbă realitatea sau scopurile. Într-o arhitectură multi-agent, context managerul poate fi el însuși un meta-agent ori un serviciu comun al ecosistemului.

Soluția realistă va fi probabil hibridă. Agentul poate propune modificări ale contextului, dar un nivel superior le validează, le autorizează și păstrează memoria transformării. Se regăsește aici separarea dintre controlul strategic și cel operațional din cercetările mele asupra procesului software: agentul decide în interiorul unui cadru, în timp ce nivelul arhitectural superior controlează modul în care cadrul însuși poate evolua.

De la agent la ecosistem digital

O altă legătură directă cu lucrările mele este ideea de ecosistem digital. Un sistem de IA agentică nu este doar un program împărțit în mai multe module inteligente. Agenții formează o populație de entități autonome, cu roluri, obiective, resurse și contexte proprii. Ei cooperează, se sprijină, negociază, își deleagă activități, pot intra în conflict și pot produce soluții diferite pentru aceeași situație.

În Conceptual Modeling of the Healthcare Ecosystem și în Towards an Agent-Oriented Architecture of the Digital Healthcare Ecosystem, trecerea de la sistem la ecosistem însemna tocmai renunțarea la o infrastructură rigidă și centralizată în favoarea unui mediu dinamic de cooperare între actori, servicii, organizații și resurse digitale.

În Agentification of Electronic Healthcare Record Systems, această idee a fost continuată prin organizații virtuale create în jurul proceselor de îngrijire a pacienților, cu un manager capabil să le constituie, să le coordoneze și să le dizolve. Agenții deveneau context-aware și goal-oriented, iar avatarurile actorilor umani puteau participa la cooperare, negociere, mediere și adaptare.

Arhitectura actuală a sistemelor de IA agentică reia aceeași problemă la o scară tehnologică nouă. Un orchestrator nu trebuie să fie numai dispecerul unor apeluri de model, ci guvernatorul temporar al unei organizații de agenți. El trebuie să gestioneze colaborarea, contradicția, consensul, reputația, competențele, autoritatea și răspunderea agenților. În acest sens, noțiunea de ecosistem este mai expresivă decât aceea de simplă arhitectură multi-agent.

Instrumentarul integrat: de la mediu software la agentic framework

A treia continuitate privește instrumentarul. În cartea Integrating Tools for Software Development, procesul software era modelat ca un univers coerent de obiecte, activități, agenți și unelte. Integrarea nu însemna doar posibilitatea de a lansa mai multe programe din aceeași interfață. Ea cerea limbaje comune de descriere, stări și relații explicite, control strategic și operațional, biblioteci de unelte, reguli de activare, mecanisme de excepție și o mașină capabilă să execute procesul.

INTERFORM era tocmai încercarea de a transforma modelarea într-un sistem executiv configurabil: vedea obiectele prin fațete, executa activități, aloca agenți, lansa unelte, modifica stări și trata excepții. Privită din această perspectivă, actuala noțiune de agentic harness este prea modestă atunci când desemnează numai o succesiune de prompturi sau un graf de apeluri. Pentru aplicațiile serioase este necesar un framework integrat pentru execuția și controlul agenților de IA.

Un asemenea framework nu trebuie să integreze numai uneltele, ci și memoria, cunoașterea, contextul, evaluarea și regulile organizaționale. El devine infrastructura în care nedeterminismul modelului este transformat într-un proces observabil și controlabil. Aceasta este, cred, legătura cea mai directă dintre cartea mea din 1992 și problema actuală: nu integrarea unor instrumente izolate, ci integrarea întregului univers de execuție al procesului.

Când sistemul funcționează, dar decide mai prost

Sistemele distribuite clasice ne-au obișnuit cu eșecuri relativ vizibile: un serviciu nu răspunde, o operație expiră, un răspuns întârzie, datele devin inconsistente. Într-un sistem de IA agentică bazat pe LLM-uri, infrastructura poate rămâne perfect sănătoasă, iar calitatea rezultatului să se degradeze.

Un agent poate alege o sursă mai slabă, poate interpreta greșit un rezultat intermediar sau poate transmite altui agent un context incomplet. Decizia inițială eronată influențează pașii următori, iar degradarea se propagă fără să producă neapărat o excepție tehnică. Latența rămâne normală, rata erorilor este redusă, dar sistemul răspunde mai prost.

Noi moduri de eșec

• Degradarea în cascadă a deciziilor: o alegere greșită timpurie reduce calitatea tuturor etapelor următoare.
• Amplificarea reluărilor: mecanismul de evaluare cere noi încercări, crescând costul și latența fără garanția convergenței.
• Degradarea tăcută: metricile infrastructurii rămân bune, dar utilitatea pentru utilizator scade.
• Deriva stării și a contextului: agenții lucrează cu versiuni diferite sau contradictorii ale realității.
• Coordonarea excesivă: numărul agenților și al interacțiunilor produce cost, latență și noi puncte de eșec.

În consecință, observabilitatea trebuie să urmărească nu numai sănătatea infrastructurii, ci și sănătatea deciziei: ce unelte au fost selectate, ce informații au fost folosite, ce alternative au fost respinse, câte reluări s-au produs și prin ce evaluare a fost acceptat rezultatul.

Autonomie limitată și observabilitate extinsă

Termenul „agent autonom” poate crea impresia unei libertăți totale. În aplicațiile reale, autonomia utilă trebuie să fie limitată. Agentul primește un spațiu în care poate alege, nu dreptul de a face orice. Bugetele de timp și cost, numărul maxim de reluări, adâncimea raționamentului, permisiunile asupra uneltelor și datele accesibile trebuie definite arhitectural.

Numărul InfoQ propune o evoluție prudentă a întreprinderii: mai întâi infrastructura de control, apoi autonomia structurată a fluxurilor și numai la sfârșit agenții capabili să-și construiască singuri strategia. Este o idee cu care sunt de acord. Autonomia nu trebuie să preceadă guvernanța. Securitatea, trasabilitatea, protecția datelor, evaluarea continuă și intervenția umană trebuie să existe înainte de a extinde libertatea sistemului.

Această prudență este cu atât mai necesară în medicină, finanțe, industrie, infrastructuri și administrație. În aceste domenii, agentul poate sprijini decizia și poate automatiza părți ale procesului, dar extinderea autonomiei trebuie să urmeze dovezile acumulate, nu fascinația tehnologică.

Un fir propriu de cercetare, nu o analogie retrospectivă

Continuitatea cu lucrările mele nu se reduce la coincidența câtorva termeni. Ea poate fi urmărită într-o succesiune de probleme care au evoluat timp de aproape patru decenii:

• 1981–1992 — procesul și mediul integrat: proiectarea sistematică, interforma, INTERFORM și apoi Integrating Tools for Software Development, cu obiecte, activități, agenți, unelte, stări și două niveluri de control.
• 2003 — agentul și universul perceput: modelarea mediilor virtuale bazată pe agenți, câmpuri de percepție și transformarea percepțiilor în decizie și acțiune.
• 2008 — obiectivele și preocupările actorilor: Concern-Driven Design, unde interesele, riscurile, obligațiile și prioritățile organizează modelul și arhitectura.
• 2011–2013 — adaptabilitate, context și ecosistem: organisme virtuale, R2V2R, ecosisteme digitale, contexte multifacetate și agenți de colectare și integrare.
• 2015 — agentificarea infrastructurii: trecerea graduală de la servicii la organizații virtuale de agenți și avataruri context-aware, goal-oriented.
• 2019 — contextul mutabil: evoluția speciilor digitale prin modificarea nu numai a stării, ci și a structurii contextului.

InfoQ descrie o nouă generație tehnologică, bazată pe LLM-uri, dar întrebările arhitecturale nu apar din nimic. Ce informații constituie lumea agentului? Cum se modifică această lume când se schimbă scopul? Cine coordonează colectivitatea de agenți? Cum sunt integrate uneltele? Cum se păstrează starea și memoria procesului? Cum sunt tratate excepțiile și conflictele? Aceste întrebări traversează în mod real opera mea, chiar dacă răspunsurile tehnologice de astăzi sunt altele.

De la agenții BDI la agenții construiți peste LLM-uri

În reflecțiile mele despre viitorul tehnologiei am revenit la modelul BDI — Beliefs, Desires, Intentions. În lucrările despre agenți virtuali și, mai târziu, despre avatarurile din ecosistemele digitale, agentul nu era doar un executant: avea o reprezentare explicită a lumii, urmărea obiective și își selecta acțiunile potrivit unor reguli, planuri, protocoale și modele ale stării interne. Autonomia sa era reală, dar se desfășura în interiorul unei structuri conceptuale proiectate în prealabil.

Agenții actuali sunt diferiți nu fiindcă ar fi descoperit pentru prima dată obiectivele, contextul sau cooperarea, ci fiindcă centrul lor decizional este un model generativ. Ei pot interpreta o cerință incomplet formalizată, pot produce reprezentări și planuri care nu au fost enumerate de proiectant, pot genera cod, pot utiliza unelte descrise în limbaj natural și pot revizui strategia în funcție de rezultate. Această capacitate le lărgește enorm spațiul de acțiune, dar reduce proporțional predictibilitatea.

De aceea nu sunt pur și simplu agenți BDI modernizați. „Credințele” lor sunt distribuite între contextul activ, memoria persistentă, cunoașterea domeniului, sursele externe și parametrii modelului; „dorințele” provin din obiectivele utilizatorului, ale organizației sau ale altor agenți; „intențiile” apar sub forma planurilor generate, evaluate și revizuite dinamic. Modelul BDI rămâne totuși util pentru că obligă arhitectul să separe ce consideră agentul adevărat, ce urmărește și la ce plan s-a angajat.

Introducerea contextelor mutabile adaugă însă o problemă pe care schema BDI simplă nu o rezolvă: schimbarea obiectivului poate modifica însăși structura „credințelor” relevante. Din acest motiv, arhitectura are nevoie fie de agenți capabili de auto-reconfigurare, fie de un nivel metacognitiv — context manager, supervisor sau organizație de guvernanță — care controlează evoluția universului informațional al agentului.

Când mai mulți agenți colaborează, se contrazic sau negociază, BDI-ul individual trebuie completat cu o teorie a organizației: roluri, autoritate, protocoale, norme, reputație, mecanisme de consens și rezolvare a conflictelor. Aici arhitectura sistemelor de IA agentică se întâlnește direct cu cercetările mele asupra organizațiilor virtuale și ecosistemelor digitale.

Ce trebuie adăugat educației în Software Engineering?

În pagina despre viitorul Ingineriei Software am susținut că studentul nu trebuie format nici ca simplu programator, nici ca operator al unui instrument IA. Arhitectura sistemelor de IA agentică întărește această concluzie, dar legătura cu vechiul nucleu al disciplinei trebuie făcută explicit.

• Modelarea universului agentului: stare, percepție, context, cunoaștere, memorie și relația lor cu obiectivele.
• Contexte mutabile: diferența dintre actualizarea valorilor și modificarea structurală a spațiului variabilelor de stare.
• Context management: auto-adaptare, meta-agenți, politici de selecție, expirare, revalidare și trasabilitatea schimbării.
• Arhitectura ecosistemelor digitale: cooperare, suport reciproc, negociere, conflict, consens, roluri și organizații virtuale.
• Framework-uri integrate: obiecte, activități, agenți și unelte; registre de capacități, protocoale, sandbox-uri, evaluatori și managementul excepțiilor.
• Arhitectura sistemelor de IA agentică: separarea planificării de execuție, agenți specializați, orchestrare și fluxuri dinamice.
• Evaluare în timpul execuției: criterii de calitate, teste, simulare, evaluatori și controlul convergenței.
• Observabilitatea deciziilor: trasarea alegerilor, a uneltelor, a contextului, a reluărilor și a motivelor acceptării rezultatului.
• Securitatea agenților: prompt injection, contaminarea rezultatelor uneltelor, permisiuni limitate și credențiale legate de sarcină.
• Autonomie guvernată: guardrails, fallback-uri deterministe, human-in-the-loop și lansare progresivă.
• Protocoale și integrare: API-uri, mesagerie asincronă, MCP, A2A și bounded contexts.
• Economia sistemului: costul tokenilor, latența, numărul apelurilor de model și alegerea celei mai simple abstracții suficiente.

Nu fiecare student trebuie să devină cercetător în modele fundamentale. Dar viitorul arhitect software trebuie să știe să integreze o componentă probabilistică într-un sistem verificabil și să proiecteze nu numai comportamentul agentului, ci și universul său relevant, colectivitatea din care face parte și infrastructura care îi limitează și îi explică acțiunile.

O nouă familie în istoria arhitecturilor software

Istoria Ingineriei Software poate fi citită și ca o succesiune de răspunsuri arhitecturale la creșterea complexității. Un reper timpuriu a fost volumul lui Mary Shaw și David Garlan, Software Architecture: Perspectives on an Emerging Discipline, publicat în 1996. Repertoriul arhitectural s-a extins apoi rapid: programele monolitice au fost urmate de organizarea pe straturi, de arhitecturile client–server, de componente, de sisteme distribuite, de SOA, microservicii, arhitecturi orientate pe evenimente și platforme cloud-native. Fiecare familie a schimbat unitatea de descompunere, forma interacțiunilor și locul în care era exercitat controlul.

Arhitectura sistemelor de IA agentică trebuie așezată în această istorie. Ea nu este doar o extensie de marketing a microserviciilor și nici redenumirea sistemelor multi-agent. Unitatea arhitecturală centrală devine agentul bazat pe un model generativ, iar obiectul descompunerii se mută de la funcționalități către capacități de decizie: planificare, căutare, interpretare, evaluare, execuție, memorie și supraveghere.

Totuși, aceasta nu înseamnă că fiecare aplicație trebuie transformată într-o colectivitate de agenți. Ca în orice etapă anterioară, noua abstracție este justificată numai acolo unde complexitatea problemei o cere. Un flux determinist, un serviciu obișnuit sau un algoritm bine cunoscut rămân preferabile atunci când rezolvă problema mai simplu, mai ieftin și mai sigur. Noua familie arhitecturală devine necesară atunci când traseul nu poate fi prescris complet, când scopurile trebuie interpretate, când informația relevantă se schimbă și când alegerea acțiunilor depinde de evaluări produse în timpul execuției.

Declin sau revenire?

Mai cred că forma clasică a Ingineriei Software este în declin. Nu mai există aceeași încredere în metodologii universale, în documentații exhaustive și în posibilitatea de a proiecta complet sistemul înainte de implementare. Dar arhitectura sistemelor de IA agentică arată că dispariția formei clasice nu înseamnă dispariția disciplinei.

Se poate produce chiar o revenire. Când generarea automată de cod părea să reducă rolul inginerului, accentul se muta spre utilizarea unui model gata construit. Acum, odată cu agenții, constatăm că modelul singur nu este produsul. Produsul este sistemul complet: modelele, serviciile, uneltele, memoria, contextul, evaluatorii, protocoalele, regulile de acces, mecanismele de revenire și oamenii care răspund pentru el.

Poate că numele disciplinei se va schimba sau va fi împărțit între AI Engineering, Platform Engineering, Systems Architecture și Governance. Dar preocuparea fondatoare rămâne: cum transformăm o capacitate de calcul impresionantă, aflată la dispoziția noastră, într-un sistem inteligibil, fiabil, întreținabil și responsabil?

De la programe care execută la sisteme care decid

Prima Inginerie Software s-a născut atunci când programele au devenit prea mari pentru a mai fi controlate prin talent individual. Arhitectura sistemelor de IA agentică apare când deciziile produse de sisteme devin prea complexe pentru a fi lăsate în seama unui model izolat.

Nu mai proiectăm numai programe care execută instrucțiuni. Proiectăm sisteme care interpretează scopuri, construiesc planuri, aleg unelte, își evaluează rezultatele și își modifică traseul. Această libertate aparentă nu reduce nevoia de inginerie. O amplifică.

Poate că aceasta este continuarea firească a reflecțiilor mele anterioare. Am început prin a mă teme că IA va face inutilă programarea și va dizolva Ingineria Software. Încep acum să văd și mișcarea inversă: tocmai pentru că IA poate produce cod și poate lua decizii, avem nevoie de o Inginerie Software capabilă să proiecteze libertatea mașinii fără a pierde controlul asupra consecințelor ei.

Repere de lectură și lucrări proprii

Reflecția pornește de la The InfoQ eMag, Issue #125, July 2026 — Agentic AI Architecture, în special de la următoarele articole:

• Mallika Rao, From Microservices to Agents: The Next Evolution of Distributed Systems.
• Karthik Ramgopal, The Evolution of Agentic Harnesses: From Chains to Graphs to Code.
• Adi Polak, Systemic Approach to Memory, Knowledge, and Context in Agentic AI Architectures.
• Subash Natarajan și Ahilan Ponnusamy, Agentic AI Architecture Framework for Enterprises.
• Rafał Gancarz, Agentic AI Architecture: Current Challenges and Future Opportunities.

Lucrări proprii aflate în continuitate conceptuală

• Integrating Tools for Software Development (1992)
  Modelarea procesului prin obiecte, activități, agenți și unelte; integrare, stare, control și arhitectura mediului INTERFORM.
• Agent-Based Modeling of Virtual Environments (2003)
  Percepție, stare internă și universul accesibil agentului virtual.
• Concern-Driven Design (2008)
  Interese, riscuri, obligații și priorități care organizează obiectivele și arhitectura.
• Conceptual Modeling of the Healthcare Ecosystem (2011)
  Trecerea de la sistem la ecosistem și cooperarea entităților autonome.
• Supporting Adaptability in Agent-Based Digital Healthcare Ecosystem (2011)
  Adaptabilitate, R2V2R, organisme virtuale și evoluția reprezentării digitale.
• Towards an Agent-Oriented Architecture of the Digital Healthcare Ecosystem (2012)
  Agenți specializați, organizații și infrastructura unui ecosistem digital.
• Strengthening Context-Awareness of Virtual Species in Digital Ecosystems (2013)
  Context multifacetat, agenți de colectare și integrarea stării relevante.
• Agentification of Electronic Healthcare Record Systems (2015)
  Organizații virtuale, manager organizațional, agenți goal-oriented și avataruri.
• Evolution of Digital Species by Using Mutable Contexts (2019)
  Evoluția agentului prin schimbarea structurală a contextului.

Legături interne

• Istoria ingineriei software
  Cronologia disciplinei, de la criza software la IA generativă.
• Viitorul Ingineriei Software
  Eseu-dialog despre profesie, educație și școala de Software Engineering de la FILS.
• Ordine în haos
  Mașina abstractă, interforma și proiectul INTERFORM.
• Reflecții
  Texte despre tehnologie, inteligență artificială, profesie și ceea ce rămâne.