Blueprint pentru agenți conversaționali care separă intenția probabilistică de execuția acțiunilor reale prin filtrare, rutare semantică, validare, permisiuni, fallback determinist și audit.
Modelul este reutilizabil pentru agenți conversaționali care transformă limbaj natural în intenții controlate și acțiuni verificabile. Exemplele din zona clinicilor sunt doar scenarii de aplicare, nu limitează modelul la domeniul medical.
Un agent conversațional poate interpreta corect o cerere și totuși poate declanșa o acțiune greșită dacă intenția extrasă ajunge direct în backend, fără verificare. Riscul nu apare doar în răspunsul generat de model, ci în momentul în care textul liber începe să producă efecte reale: programări, comenzi, modificări de status, notificări sau escaladări operaționale.
Într-o arhitectură fragilă, modelul este tratat ca decident final. Primește limbaj natural, estimează intenția și poate influența sistemul real înainte ca intenția, permisiunile, contextul și sursele autorizate să fie validate. Aici apar erorile greu de observat: acțiuni premature, rutare greșită, expunere de date, costuri inutile sau transfer întârziat către operator.
Blueprint-ul pornește de la o separare simplă: modelul poate ajuta la interpretare, dar execuția aparține arhitecturii. Orice acțiune cu efect real trebuie să treacă prin filtre, contracte, politici, surse autorizate și audit.
Un agent cu execuție verificată nu trimite textul liber direct către backend. Înainte ca o cerere să producă efecte reale, conversația este transformată într-o structură verificabilă: intenție clasificată, date minime necesare, context permis și reguli de continuare.
Această conversie este diferența dintre un chatbot care doar răspunde și un agent care poate participa controlat la operațiuni. Modelul poate interpreta limbajul și poate propune o intenție, dar sistemul decide dacă acea intenție poate deveni acțiune.
Cererea verificabilă nu este o comandă executată automat. Este o etapă intermediară, în care arhitectura verifică dacă există suficiente date, dacă utilizatorul sau contextul are permisiunea necesară și dacă acțiunea trebuie confirmată, blocată, redirecționată sau trimisă către un operator uman.
Text liber, posibil ambiguu, venit din conversație.
Cererea este încadrată într-o categorie permisă sau respinsă ca out-of-scope.
Sistemul păstrează doar informațiile necesare pentru următorul pas.
Permisiunile, contextul și sursele autorizate sunt verificate înainte de execuție.
Acțiunea continuă doar dacă este validă; altfel intră în fallback sau transfer către operator uman.
După clasificarea intenției, sistemul nu execută direct acțiunea. Cererea intră într-un gate de verificare: un strat care decide dacă poate continua, dacă trebuie clarificată, dacă intră în fallback sau dacă trebuie transferată către un operator uman.
O cerere verificabilă nu este validă pentru că modelul a produs un răspuns convingător. Ea poate avansa doar dacă arhitectura poate confirma intenția, datele necesare, contextul permis și traseul de audit.
Toate criteriile sunt îndeplinite. Cererea poate avansa către o acțiune controlată sau poate fi pregătită pentru confirmare finală.
Intenția pare permisă, dar lipsesc date sau există ambiguitate. Sistemul cere o completare punctuală, fără să declanșeze încă acțiunea.
Cererea nu are traseu sigur, este out-of-scope sau nu poate fi mapată într-o intenție permisă. Sistemul răspunde controlat, fără acces la backend.
Cererea este sensibilă, critică, neautorizată sau necesită judecată umană. Contextul este păstrat, dar execuția nu rămâne la model.
Această regulă mută responsabilitatea execuției din zona predicției lingvistice în zona controlului arhitectural. Modelul contribuie la interpretare, dar decizia de a produce efecte reale aparține unui strat verificabil: reguli, permisiuni, surse autorizate, fallback și audit.
După ce cererea trece prin criteriile de verificare, rolul interfeței se schimbă. Ea nu mai este doar un canal prin care utilizatorul trimite text, ci primul strat al unei arhitecturi care decide ce poate continua, ce trebuie clarificat și ce trebuie oprit.
În modelul pasiv, conversația produce context pentru un operator uman. În modelul cu execuție verificată, conversația produce o cerere structurată, iar arhitectura decide dacă acea cerere are voie să atingă sisteme reale.
În această paradigmă, modelul nu este eliminat din flux, dar nu mai este lăsat să fie punctul care decide efectul operațional. El poate ajuta la interpretarea limbajului, la clasificarea intenției și la formularea unui răspuns, însă acțiunea reală trece printr-un strat separat de control.
Linia de demarcație este simplă: modelul interpretează, arhitectura decide, iar sistemul execută doar după validare. Această separare reduce riscul ca un răspuns plauzibil, dar neverificat, să devină programare, comandă, modificare de status sau escaladare operațională.
Schimbarea nu este că modelul devine infailibil. Schimbarea este că modelul nu mai este lăsat să fie punctul final de decizie. El contribuie la interpretare, dar execuția este mutată într-un strat separat, unde regulile, permisiunile, sursele de date și auditul pot fi controlate explicit.
După ce cererea este verificată, conversația nu trebuie lăsată să evolueze liber până la execuție. Un agent cu acțiuni reale are nevoie de un flux conversațional controlat: un traseu explicit care stabilește unde se află cererea, ce date lipsesc, ce tranziții sunt permise și când sistemul trebuie să oprească fluxul.
Tehnic, acest control funcționează ca o mașină de stări. Rolul lui nu este să facă modelul infailibil, ci să reducă spațiul de acțiune. Modelul poate interpreta răspunsuri și poate propune următorul pas, dar nu poate sări peste stări critice precum validarea intenției, autorizarea contextului, confirmarea explicită sau transferul către operator uman.
Fiecare stare are o condiție de intrare, o condiție de ieșire și o listă limitată de tranziții permise. Dacă aceste condiții nu sunt îndeplinite, conversația nu continuă spre execuție.
Într-un flux controlat, conversația nu este reevaluată de la zero la fiecare mesaj. Sistemul păstrează o stare curentă și permite doar trecerea către următoarea stare validă. Fiecare etapă are condiții de intrare, condiții de ieșire și tranziții permise. Astfel, o cerere nu poate ajunge direct la execuție fără să treacă prin pașii de control.
Același flux include și ramura de protecție: atunci când intenția este ambiguă, datele lipsesc, contextul nu este autorizat sau cererea este sensibilă, conversația nu avansează automat. Sistemul cere clarificare, aplică fallback, refuză controlat sau transferă cazul către un operator uman.
Acest flux face diferența dintre o conversație generativă și un agent operațional. Într-un agent operațional, fiecare tranziție trebuie să poată fi explicată, reprodusă și auditată.
Fluxul conversațional stabilește traseul permis al cererii. Middleware-ul este stratul care aplică efectiv regulile înainte ca orice intenție extrasă din limbaj natural să ajungă la backend, baze de date, CRM, sistem de programări sau altă infrastructură operațională.
Într-un agent cu execuție verificată, middleware-ul nu este doar un proxy tehnic. El funcționează ca un filtru de control: normalizează inputul, limitează abuzul, validează intenția, reduce expunerea datelor și decide când cererea trebuie oprită, clarificată, trimisă în fallback sau transferată către un operator uman.
La ieșirea din middleware, cererea nu este încă o acțiune executată. Ea primește un verdict de continuare: poate fi trimisă către ruterul semantic, poate cere clarificare, poate intra în fallback sau poate fi transferată către un operator uman.
Scopul stratului middleware nu este să facă modelul perfect, ci să reducă suprafața în care o interpretare greșită poate produce efecte reale. Modelul poate propune; middleware-ul verifică dacă propunerea are voie să continue.
Acesta este rolul modelului defense-in-depth: fiecare strat prinde o clasă diferită de risc, astfel încât execuția să nu depindă de o singură decizie generativă.
După filtrare, normalizare și validare, sistemul nu trimite text liber către backend. Rezultatul este o cerere verificabilă: o structură intermediară care descrie ce a înțeles sistemul, ce date are, ce lipsește, ce riscuri există și ce traseu este permis mai departe.
Cererea verificabilă nu este o comandă executată automat. Ea este forma controlată în care conversația poate fi predată către ruterul semantic, către o clarificare, către fallback sau către un operator uman. În acest punct, modelul nu mai decide singur următorul efect operațional.
O cerere de programare poate ajunge în sistem cu serviciul și intervalul preferat deja extrase, dar fără datele de contact necesare pentru continuare. În această stare, intenția este permisă, dar cererea rămâne incompletă.
Verdictul de control nu este execuția, ci clarificarea. Sistemul solicită datele lipsă, păstrează backend-ul neatins și nu permite acțiunii să avanseze până când cererea nu devine suficient de completă și verificabilă.
Important este că această cerere nu acordă modelului dreptul de a executa. Ea descrie starea fluxului într-o formă pe care sistemul o poate valida, jurnaliza și direcționa. Dacă lipsesc date, dacă verdictul este neclar sau dacă politica nu permite continuarea, cererea nu ajunge la backend ca acțiune.
De aici, ruterul semantic poate decide traseul: flux permis, clarificare, fallback sau transfer către operator uman.
După ce cererea a trecut prin filtrare, normalizare și criteriile de verificare, ea nu trebuie trimisă direct către un model general sau către backend. Ruterul semantic este stratul care decide traseul: ce poate continua, ce trebuie clarificat, ce trebuie oprit și ce trebuie transferat către un canal sigur.
Rolul ruterului nu este să producă singur răspunsul final. Rolul lui este să transforme o cerere verificabilă într-o decizie de rutare: flux permis, clarificare, fallback, refuz controlat sau transfer către operator uman.
Text liber din conversație.
Boți, abuz, input suspect sau cereri care nu pot intra în flux.
Anti-abuz, normalizare, minimizare și igienă de prompt.
Clasifică intenția, contextul și verdictul de control.
Cererea poate ajunge la surse autorizate sau sisteme operaționale.
Sistemul cere clarificare înainte de execuție.
Fluxul merge către politici de siguranță, fallback sau transfer către operator uman.
Clarificare, refuz controlat, fallback sau acțiune pregătită pentru confirmare.
Ruterul semantic este punctul în care conversația devine traseu arhitectural. De aici, cererea poate continua doar pe una dintre rutele permise: execuție verificată, clarificare, fallback, refuz controlat sau transfer către operator uman.
După ce ruterul semantic stabilește traseul cererii, controlul accesului devine al doilea strat de control. Un traseu relevant nu înseamnă automat acces la date, drept de modificare a datelor sau permisiune de a pregăti o acțiune pentru confirmare.
Acest strat traduce decizia de rutare într-o decizie de permisiune. Verifică rolul actorului, contextul, perimetrul operațional, sensibilitatea datelor și tipul acțiunii înainte ca sistemul să citească, să modifice sau să expună informații.
Modelul poate formula intenția, iar ruterul poate alege traseul. Accesul efectiv aparține infrastructurii: politici server-side, reguli declarative, atribute / claims de sesiune, verificări API, mascare, limitare și audit.
Decizia stratului de acces poate permite cererea, o poate limita la date mascate sau acțiune pregătită pentru confirmare, o poate refuza controlat ori o poate transfera către un operator uman. Această decizie separă intenția validă de accesul efectiv: faptul că sistemul a înțeles cererea nu înseamnă că are voie să expună sau să modifice date.
Principiul de bază este least privilege: agentul primește doar minimul necesar pentru următorul pas. Dacă o cerere poate fi rezolvată cu date mascate, câmpuri reduse sau confirmare explicită, sistemul nu trebuie să expună mai mult context decât este necesar.
Controlul accesului face ca ruterul semantic să nu devină o poartă prea largă către date. Ruterul stabilește traseul, dar stratul de acces decide ce poate fi văzut, modificat, mascat, refuzat sau transferat.
După rutare și controlul accesului, cererea nu devine automat comandă executabilă. Interfața de acțiune este stratul care transformă o cerere verificabilă într-o operațiune controlată: pregătire, confirmare, execuție limitată, fallback sau transfer către operator uman.
Canalul de intrare poate fi conversațional, vocal, formular sau API. Diferența arhitecturală nu stă în canal, ci în faptul că niciun input natural nu controlează direct backend-ul. Toate cererile trec prin aceeași logică: intenție clasificată, date minime, permisiuni, context autorizat și decizie auditabilă.
Vocea, chatul sau formularul sunt doar moduri diferite de a exprima intenția. Arhitectura nu trebuie să acorde mai multă autoritate unui canal doar pentru că pare mai natural sau mai rapid. O comandă vocală, o solicitare scrisă sau un click asistat de AI trebuie să ajungă în același strat de validare înainte să producă efecte reale.
În acest model, interfața de acțiune nu extinde autonomia modelului, ci o încadrează în pași verificabili. Acțiunea reală apare doar când cererea, accesul, contextul și confirmarea sunt aliniate.
O cerere sensibilă nu trebuie rezolvată prin improvizație generativă. Dacă sistemul detectează ambiguitate, risc operațional, lipsă de date sau context care necesită judecată umană, execuția se oprește înainte să atingă backend-ul.
În acest punct, scopul arhitecturii nu este să forțeze un răspuns, ci să păstreze traseul deciziei: ce intenție a fost detectată, ce regulă a fost activată, de ce fluxul nu a continuat și către ce canal sigur trebuie transferat cazul.
Un utilizator formulează o cerere care pare urgentă, ambiguă sau sensibilă. Modelul poate recunoaște intenția generală, dar nu primește dreptul de a decide singur efectul operațional. Middleware-ul oprește execuția automată, păstrează contextul minim necesar și direcționează cazul către un operator uman sau către un protocol intern de clarificare.
Rezultatul nu este un răspuns inventat și nici o acțiune directă în backend. Rezultatul este o decizie controlată: fluxul este oprit, motivul este jurnalizat, iar următorul pas este tratat printr-un canal sigur.
Această trasabilitate face ca agentul să fie operabil în contexte reale: nu pentru că modelul devine infailibil, ci pentru că fiecare oprire, transfer sau continuare poate fi explicată și auditată.
Un agent operațional trebuie proiectat și pentru situațiile în care fluxul nu poate continua în forma ideală. Modelul poate răspunde incomplet, serviciile externe pot fi indisponibile, inputul poate fi ambiguu, iar contextul poate deveni sensibil. Arhitectura nu trebuie să presupună perfecțiunea modelului sau a infrastructurii.
Degradarea controlată înseamnă că sistemul are trasee sigure pentru aceste situații: clarificare, fallback determinist, refuz controlat, mod read-only sau transfer către operator uman. Scopul nu este să ascundă eroarea, ci să limiteze efectul operațional al unei decizii nesigure.
Mecanismele de siguranță nu sunt doar reguli de refuz. Ele sunt mecanisme de rutare care decid cum se păstrează controlul atunci când fluxul normal nu este sigur.
Prin degradare controlată, agentul rămâne util și atunci când nu poate executa. Valoarea arhitecturală nu stă în promisiunea că fluxul nu eșuează niciodată, ci în faptul că eșecul este limitat, explicabil și auditabil.
Un agent cu execuție verificată nu trebuie monitorizat doar prin numărul de conversații sau prin volumul de mesaje. Observabilitatea relevantă este despre decizii: de ce o cerere a continuat, de ce a fost oprită, ce regulă a fost activată, ce date au lipsit și unde a fost transferat cazul.
Fără observabilitate, fallback-ul, refuzul controlat și transferul uman devin imposibil de evaluat. Sistemul poate părea funcțional la nivel de interfață, dar echipa nu poate înțelege unde apar ambiguități, unde se pierd cereri valide sau unde regulile sunt prea permisive.
Volumul de chat nu este un indicator suficient pentru un agent operațional. O conversație lungă poate indica fricțiune, nu valoare. O rată mare de automatizare poate fi riscantă dacă acțiunile avansează fără validare. Observabilitatea trebuie să arate calitatea deciziei, nu doar cantitatea interacțiunilor.
În acest model, observabilitatea închide bucla arhitecturală: ceea ce sistemul decide trebuie să poată fi verificat, ajustat și auditat. Agentul devine mai controlabil nu prin promisiuni, ci prin capacitatea de a explica fiecare decizie operațională.
După ce agentul începe să proceseze cereri reale, arhitectura trebuie să poată învăța din propriile decizii fără ca modelul să se auto-ajusteze liber. Bucla de feedback operațional folosește evenimentele observate pentru a rafina reguli, clarificări, fallback-uri, permisiuni și trasee de transfer.
Scopul nu este să măsurăm volumul de conversații, ci să înțelegem unde fluxul este prea permisiv, prea restrictiv sau prea ambiguu. Fiecare continuare, clarificare, fallback, refuz sau transfer poate arăta dacă arhitectura are nevoie de reguli mai clare sau de limite mai bune.
Feedback-ul nu trebuie folosit pentru a crește autonomia agentului fără control. El trebuie să ducă la ajustări explicite în arhitectură: reguli mai bune, intenții mai clare, formulări de fallback mai utile, politici de acces mai precise și scenarii de transfer mai bine definite.
Bucla de feedback închide blueprint-ul operațional: agentul devine mai controlabil nu pentru că primește mai multă libertate, ci pentru că arhitectura înțelege mai bine unde trebuie să permită, să limiteze, să clarifice sau să oprească.
Un agent AI cu execuție verificată reduce riscul ca o intenție probabilistică să producă efecte operaționale necontrolate, dar nu înlătură ambiguitatea, erorile de clasificare sau nevoia de supraveghere umană. Arhitectura trebuie tratată ca un sistem de control, nu ca o promisiune că modelul devine infailibil.
Limitările sunt importante tocmai pentru că agentul operează aproape de date, permisiuni și acțiuni reale. Fiecare componentă - filtrare, rutare, acces, fallback, transfer și audit - trebuie verificată continuu în funcție de contextul operațional.
Un blueprint sigur nu încearcă să mute toate incertitudinile în model, ci să limiteze locurile în care incertitudinea poate produce efecte reale. Anti-pattern-ul central este autonomia fără control: un agent care poate interpreta, accesa și executa fără separarea clară dintre intenție, permisiune și acțiune.
