Arhitectura propose-then-act: de ce un agent AI trebuie să ceară voie înainte să acționeze

Multe demo-uri de agenți AI arată captivant: utilizatorul cere ceva, agentul plănuiește, agentul execută, rezultatul apare. În producție, acest flux este inacceptabil. Dacă agentul rulează pe infrastructură reală — face deploy, modifică DNS, schimbă configurări de firewall, deschide tranzacții cu impact financiar — execuția fără confirmare devine, statistic, o sursă de incidente.

IRIS, agentul orchestrator pe care CAI Technology îl operează intern pentru data center și operațiuni, este construit pe arhitectura propose-then-act. În acest articol explicăm de ce am ales acest pattern, ce ne-a costat să-l implementăm corect și ce surpriză economică a apărut: structura propose-then-act, combinată cu cost-aware routing între modele, ne-a redus costul de invocare cu aproximativ 70% față de o variantă naivă „un model mare face totul”.

TL;DR

• Un agent AI care execută în producție fără confirmare este o liability legală și operațională, indiferent cât de bun este modelul.
• Patternul propose-then-act separă cele două activități: agentul propune un plan textual, omul aprobă, abia apoi se execută acțiunea concretă.
• Suprafața de aprobare este unde apare valoarea: omul vede ce ar face agentul înainte ca acțiunea să se petreacă, nu după.
• Cost-aware routing: modelul scump este folosit doar pentru fază de proiectare a planului; modelul ieftin face execuția repetitivă; un model local foarte mic face polling-ul de stare.
• În producție internă, această structură ne-a redus costul de inferență cu aproximativ 70% comparativ cu o arhitectură mono-model.

De ce execuția fără confirmare este greșită

În demo, un agent care „repară un alert” în 15 secunde fără intervenție umană pare miraculos. Pe infrastructură reală, scenariul are trei probleme:

Probleme de risc. Un model lingvistic poate interpreta greșit cererea, poate hală cina contextul, poate combina două operațiuni distincte într-una singură. Pe demo, o eroare costă 15 secunde de re-rulare. În producție, o eroare poate însemna un down-time de oră, un firewall blocat, o tranzacție duplicată.

Probleme de audit. Un proces fără confirmare lasă o întrebare deschisă în orice incident: „cine a decis această acțiune?” Răspunsul „agentul” nu este satisfăcător pentru o comisie de audit, pentru un client cu cerințe SOC 2 sau ISO 27001, sau pentru un manager care răspunde de operațiuni. Aprobarea umană la momentul deciziei lasă o urmă cu nume, date și raționament.

Probleme de încredere organizațională. Un agent AI care „face singur” se erodează rapid în acceptarea echipei de ops. Prima dată când agentul greșește, încrederea este ruptă; sustenabilitatea proiectului depinde de asta. Un agent care propune și așteaptă păstrează autonomia echipei și o amplifică.

Ce înseamnă concret propose-then-act

Patternul are trei faze rigid separate.

Faza 1: Propose. Agentul primește cererea utilizatorului, analizează contextul (citind din baze de date, surse de inventar, logs), și produce un plan textual. Planul descrie ce se va face, în ce ordine, cu ce precondiții, ce risc are fiecare pas. Planul nu execută nimic.

Faza 2: Approve. Planul este prezentat utilizatorului prin canal asincron (Telegram, web UI, email). Utilizatorul răspunde cu aprobare, modificare sau respingere. Aprobarea este înregistrată în baza de date de audit cu timestamp, ID-ul utilizatorului, ID-ul planului. Dacă utilizatorul cere modificări, agentul revine la Faza 1 cu contextul actualizat.

Faza 3: Act. Doar după aprobare explicită, agentul execută planul. Execuția este pas cu pas, cu verificare după fiecare pas. Dacă un pas eșuează în mod neașteptat, execuția se oprește și revine la Faza 2 cu raportul de eroare.

Această separare are o consecință importantă: utilizatorul nu trebuie să fie expert tehnic pentru a aproba sau respinge. Planul este descris în limbaj natural cu detalii tehnice opționale. Un manager de operațiuni care nu citește comenzile bash poate înțelege „voi adăuga un nou DNS record pentru subdomeniul X cu IP Y și TTL 300” și poate spune da sau nu cu cunoștință de cauză.

Diagrama flow-ului IRIS

User scrie pe Telegram → 
  Iris (agent orchestrator pe model premium) primește mesajul →
  Recunoaște intent și clasifică complexitatea →
  Cere context din baza de date (inventar, configurări existente) →
  Produce plan textual cu pași, precondiții, risc →
  Trimite plan în Telegram pentru aprobare inline →
  Așteaptă răspuns utilizator →

  Dacă APROBAT:
    Iris (acum cu model de execuție mai ieftin) execută plan pas cu pas →
    Fiecare pas: comandă subprocess controlată, validare ieșire →
    La eroare: oprește, raportează utilizatorului, întreabă ce să facă →
    La succes total: confirmă în Telegram, scrie în audit DB →

  Dacă RESPINS:
    Iris cere context suplimentar utilizatorului →
    Reformulează plan și revine la pasul de aprobare

Polling de stare în background:
  Model local foarte mic citește status servere, alertează utilizatorul
  doar pentru anomalii, nu generează planuri

Detaliul important: un singur agent nu rulează pe un singur model. Diferite faze folosesc modele diferite, alese pentru raportul cost/calitate al sarcinii respective.

Cost-aware routing: de ce ne-a redus factura

Naiv, am putea rula tot pe un model premium puternic. Costul ar fi proporțional cu numărul de invocări per zi. Pentru un agent ops care răspunde la zeci de cereri pe zi și polling continuu, factura crește repede.

Cost-aware routing exploatează observația că diferite faze ale workflow-ului au cerințe cognitive diferite:

Faza de proiectare (propose). Necesită gândire reală: înțelegerea cererii ambigue, navigare în documentație, inferență asupra stării sistemului, generare de plan structurat. Aici un model premium puternic merită costul. Apel rar (zeci de invocări pe zi).

Faza de execuție. Odată planul aprobat, execuția este o secvență de comenzi structurate cu validare la fiecare pas. Logica este largely deterministă; modelul lingvistic e folosit doar pentru parsarea ieșirilor, recunoașterea condițiilor de eroare și formatarea rapoartelor. Aici un model mediu este perfect adecvat. Apel frecvent (sute de invocări pe execuție).

Polling de stare. Background, citește status, decide dacă trebuie alertat utilizatorul. Cerință cognitivă mică. Aici un model local foarte mic, rulând pe infrastructură proprie, fără cost per invocare, este suficient. Apel constant (mii de invocări pe oră).

Pe configurația noastră internă, distribuția costului se schimbă astfel:

• Mono-model premium: 100% volum, cost 100% (referință)
• Cost-aware routing: 5% volum pe premium, 25% pe mediu, 70% pe local; cost agregat ~30%

Reducerea de aproximativ 70% nu este o estimare proiectată; este măsurată pe trei luni de operare internă. Calitatea agregată (rata de succes a planurilor aprobate, rata de erori la execuție, satisfacția utilizatorilor interni măsurată calitativ) este indistinguibilă de varianta mono-model.

Trei capcane în implementare

Capcană 1: Confirmarea automatizată. După câteva săptămâni, utilizatorii încep să aprobe automat tot ce trimite agentul, fără să citească planul. Atunci aprobarea devine o etapă goală. Soluția noastră: pentru acțiuni cu impact ridicat (DNS, firewall, deploy), agentul refuză aprobarea „ok” simplă și cere o frază specifică care confirmă acțiunea. Pentru acțiuni cu impact mic, „ok” este suficient. Categorisirea este pe acțiune, nu pe agent.

Capcană 2: Plan prea detaliat. Primele iterații produceau planuri de 40 de linii cu fiecare comandă bash. Utilizatorii nu citeau. Le-am restrâns la 5–10 linii cu nivel de abstracție acțiune-utilizator („voi adăuga un DNS record”), cu detaliile tehnice disponibile la cerere. Aprobarea se face pe înțelesul acțiunii, nu pe sintaxa comenzii.

Capcană 3: Modelul ieftin face propose. O tentație evidentă: dacă modelul ieftin poate executa, poate și planifica? Răspuns: nu. Calitatea planului determină calitatea execuției. Un plan vag sau greșit consumă timp uman la aprobare/respingere și introduce risc operațional. Plata pentru un model premium la propose se amortizează imediat.

Întrebări pentru un CTO care evaluează un agent AI

Trei verificări înainte de a accepta un agent AI în producție:

1. „Cere voie înainte de execuție pentru acțiuni cu impact?” Dacă răspunsul implică „trust the model”, reevaluați. Auditul cere semnătură umană, nu probabilitate de model.

2. „Aveți audit log per acțiune executată?” Cine a aprobat, când, pe baza căror date. Nu este suficient să existe logs operaționale; trebuie să existe legătura între acțiune și aprobator uman.

3. „Cum gestionați costul la scară?” Un agent care răspunde rar și pe model premium funcționează în pilot. La scale 10x, factura devine vizibilă. Cost-aware routing este o practică de maturitate.

Concluzie operațională

Patternul propose-then-act nu este o restricție a capacității unui agent AI. Este forma corectă în care un agent AI participă la operațiuni reale. Echipa rămâne în control, agentul accelerează, auditul este intact. Avantajul economic — costul redus prin cost-aware routing — este un side-effect plăcut, nu motivul principal.

IRIS rulează intern de luni de zile. Echipa noastră preferă să lucreze cu el față de fără el; auditul nostru intern este mai detaliat decât înainte; cererile umane care nu au impact (status, info, lookup) sunt servite instant fără a consuma timpul orchestratorului. Decizia de a păstra omul în loop nu a încetinit operațiunile; le-a consolidat.

Articole conexe

• Anti-halucinare în chatbot juridic românesc
• De ce engine-ul de devize HG907 nu folosește deloc LLM
• Pillar IRIS — agentul orchestrator CAI Technology

Surse externe

• NIST AI Risk Management Framework — Govern function — guvernanța deciziilor automate
• Anthropic Constitutional AI — context de design pentru agenți cu constrângeri
• OWASP Top 10 for LLM Applications — riscuri în aplicații LLM, inclusiv „LLM06: Sensitive Information Disclosure” și „LLM08: Excessive Agency”
• ISO/IEC 42001:2023 — AI Management Systems — standardul recent pentru guvernanță AI

Următorul pas

Dacă echipa dumneavoastră evaluează cum să introducă un agent AI în operațiuni fără să piardă controlul, vă oferim o consultație tehnică de 30 de minute fără cost.