Straturi de control agentic: tipare de fiabilitate în producție pentru agenții LLM

Majoritatea demo-urilor de AI agentic se termină la fel: un video fin al unui LLM care citește un calendar, rezervă un zbor și trimite un email de confirmare. Demo-urile rar arată ce se întâmplă când agentul alege calendarul greșit, rezervă un zbor la aeroportul greșit sau — favorita noastră personală — politicos trimite un email de confirmare pentru ceva ce nu a putut face efectiv.

Rularea agenților LLM în producție nu este o problemă a modelului. Modelul este bine. Este o problemă de control. Pattern-urile de mai jos sunt cele pe care le rulăm pentru clienții care pun agenți LLM în fața clienților reali, a banilor reali și a datelor reale. Niciuna nu este teoretică.

Modurile de eșec ale agenților pe care chiar le vezi

Înainte de pattern-uri, modurile de eșec. În doi ani de rulare a agenților în producție pentru clienți, aceleași cinci probleme reprezintă ~90% din incidente:

1. Tool greșit, apelat încrezător. Agentul invocă deleteUser când utilizatorul a cerut "scoate asta din dashboard-ul meu".
2. Tool corect, argumente greșite. Agentul apelează transferFunds cu destinatarul și expeditorul schimbate.
3. Tool halucinat. Agentul inventează un tool care nu există, apoi raportează succesul când nu s-a întâmplat nimic.
4. Bucle infinite de apeluri de tool. Agentul apelează în mod repetat același tool cu argumente ușor diferite până când ceva oprește bugetul.
5. Eșec tăcut. Un tool eșuează, agentul fabrică un rezultat plauzibil, utilizatorul vede un check verde.

Fiecare pattern de mai jos adresează una sau mai multe dintre acestea. Niciunul nu se bazează pe ca modelul să devină mai inteligent.

Stratul 1: Whitelisting de tool-uri și scope per sesiune

Modelul nu ar trebui să vadă niciodată tool-uri pe care nu este de presupus să le folosească în această sesiune. "Filtrarea la nivel de prompt" — spunându-i modelului "nu folosi deleteUser" — nu este control. Este o sugestie.

Control real:

• Orchestratorul construiește setul de tool-uri per sesiune, pe baza rolului utilizatorului autentificat.
• Tool-urile pentru care utilizatorul nu este autorizat sunt fizic absente din payload-ul cererii.
• O sesiune read-only vede doar tool-uri read-only.
• O sesiune "guest" vede un set drastic redus, chiar dacă contul de bază are tehnic mai multe permisiuni.

Implementarea este banală: o funcție getToolsForSession(user, context) care returnează definițiile JSON ale tool-urilor de atașat la apelul API. Motivul pentru a o face ceremonial este auditul — fiecare acțiune a agentului poate fi urmărită înapoi la "aceste tool-uri erau disponibile, acest utilizator era autentificat, acesta era promptul".

Stratul 2: Validarea argumentelor înainte de execuție

Fiecare apel de tool de la LLM trece printr-un validator de schemă înainte să atingă un sistem real. Zod, Pydantic, JSON Schema — alege-ți aroma. Validatorul ar trebui:

• Să respingă argumente malformate cu o eroare structurată din care modelul poate citi și relua.
• Să impună invarianții de business pe care schema îi poate exprima (amount > 0, recipient != sender, date in future).
• Să respingă tipurile care arată corect dar sunt greșite ("userId": "user_42" când schema cere un UUID).

Am prins mai multe bug-uri la acest strat decât la oricare alt. LLM-ul va emite încrezător {"amount": "100 USD"} când tool-ul se așteaptă la {"amount": 100, "currency": "USD"}. Un validator de 5 linii îl prinde; un validator lipsă îl lasă să treacă la o funcție care face ceva neașteptat.

Stratul 3: Limite de buget — tokeni, apeluri de tool, ceas

Fiecare sesiune are trei limite care sunt impuse de orchestrator, nu de model:

• Limită de tokeni. Numărul maxim de tokeni input + output per sesiune. Odată depășită, sesiunea se termină cu o eroare structurată.
• Limită de apeluri de tool. Numărul maxim de invocări de tool per sesiune. Previne modul de eșec buclă-până-explodează-bugetul.
• Limită de timp pe ceas. Numărul maxim de secunde per sesiune. Prinde apeluri de tool blocate și bucle dezlănțuite în timp real.

Acestea nu sunt "ar trebui să adăugăm acestea cândva". Sunt non-negociabile pentru orice agent de producție. Am văzut sesiuni să meargă de la $0.02 de utilizare normală la $400 de utilizare blocată-în-buclă în 90 de secunde. Limitele previn asta.

Limitele trebuie să fie configurabile per rută. O sesiune "rezumează acest email" ar putea limita la 8K tokeni și 3 apeluri de tool. O sesiune "investighează această plângere a clientului" ar putea limita la 100K tokeni și 50 de apeluri de tool. Alege limita care se potrivește cu cea mai gravă rulare plauzibilă a workflow-ului.

Stratul 4: Lanțuri de fallback și degradare grațioasă

Agenții reali apelează API-uri reale care eșuează. Rate limits, timeout-uri, întreruperi parțiale, token-uri expirate. Agentul nu trebuie doar să se oprească — trebuie să se degradeze.

Pattern-uri pe care le folosim:

• Retry cu backoff la stratul de tool, nu la stratul de model. Modelul nu ar trebui să reia propriile sale apeluri de tool; wrapper-ul tool-ului ar trebui să reia transparent.
• Expune eșecurile de tool către model ca rezultate de tool structurate, nu ca excepții. {"error": "rate_limited", "retry_after_seconds": 30} este ceva despre care modelul poate raționa. Un stack trace brut nu este.
• Au o cale de fallback "uman în buclă" pentru acțiuni cu miză mare. Agentul nu reia un transfer eșuat; aduce eșecul la suprafață și cere intervenție umană.
• Definește stări terminale explicite. "Nu am putut finaliza această sarcină pentru că X" este un răspuns valid al agentului și ar trebui tratat ca o sesiune cu succes, nu ca un eșec de reluare.

Cea mai mare victorie aici este formatul de eroare structurat. Când erorile tool-ului sunt bine formate, modelul le gestionează grațios. Când sunt excepții sau rezultate goale, modelul inventează ceea ce nu poate face.

Stratul 5: Telemetrie — loghează tot, alertează pe ce trebuie

Fiecare sesiune de agent emite log-uri structurate care acoperă:

• Utilizatorul, ID-ul sesiunii, ruta, setul de tool-uri.
• Fiecare apel de model: tokeni input, tokeni output, versiunea modelului, latență.
• Fiecare apel de tool: numele tool-ului, argumente (cu redactare PII), rezultat, latență, succes/eșec.
• Starea finală a sesiunii: completată, terminată de limita de buget, terminată de eroare, terminată de utilizator.

Acestea curg în orice stack de observabilitate pe care îl ai — Honeycomb, Datadog, Grafana, ClickHouse-pe-buget. Pattern-ul contează mai mult decât tool-ul.

Alerte care se plătesc:

• Spike al ratei de eșec a apelurilor de tool pe un singur tool (upstream-ul tool-ului este stricat)
• Spike al ratei de atingere a limitei de buget pe o rută (ruta se comportă greșit sau este sub atac)
• p95 al latenței sesiunii peste prag (modelul sau un tool se degradează)
• Același utilizator atingând limita de buget repetat (potențial abuz)

Alerte care sunt zgomot:

• Eșecuri individuale ale tool-urilor (gestionate de retry/fallback)
• Terminări individuale de buget (așteptate)
• Utilizare de tokeni peste un anumit prag absolut (neinformativ fără context)

Stratul 6: Garduri de output

Ultima linie de apărare este output-ul agentului. Chiar dacă fiecare strat de mai sus a trecut, mesajul final al agentului către utilizator poate conține PII pe care nu ar trebui să-l aibă, afirmații pe care nu le poate susține sau instrucțiuni care încalcă politica.

Pattern-uri:

• Redactare PII pe output, în special pentru contextele partajate/multi-utilizator. Agentul a aflat despre salariile angajaților dintr-un tool CRM? Scoate acele numere din mesaj înainte de a-l arăta solicitantului, cu excepția cazului în care este autorizat.
• Impunerea citărilor pentru răspunsuri factuale. Dacă agentul face o afirmație, orchestratorul verifică că afirmația referențiază un chunk recuperat sau un rezultat de tool. Afirmațiile necitate sunt eliminate sau semnalizate.
• Filtre de profanitate / politică la graniță, chiar și pentru agenți interni "de încredere". Prind cazurile limită pe care promptul tău nu le-a anticipat.

Acestea nu sunt straturi de cenzură. Sunt straturi de corectitudine. Modelul este excelent la a suna corect; gardurile verifică dacă efectiv este.

Ce nu ai nevoie

Câteva lucruri care sunt vândute ca "infrastructură de agent" și pe care le-am găsit că nu mișcă acul pentru cazurile de utilizare tipice de producție:

• Framework-uri grele de orchestrare multi-agent. Un singur agent cu design bun de tool-uri bate un echipaj de cinci agenți pentru aproape orice workflow de business. Multi-agentul este la modă; agentul unic livrează.
• Magazine de "memorie agentică" dincolo de istoricul conversației. O conversație curată + recuperare peste datele tale de domeniu sunt suficiente pentru majoritatea cazurilor de utilizare. Memoria agentică pe termen lung este o gaură de iepure.
• Bucle de auto-îmbunătățire a prompt-urilor. Agentul care își rescrie propriile prompt-uri sună inteligent și produce comportament instabil în producție.

Dacă construiești, concentrează-te pe cele șase straturi de mai sus. Dacă le faci corect, agentul este fiabil. Dacă le sari, calitatea modelului încetează să mai conteze.

O arhitectură de referință

Punându-le împreună, un sistem agentic de producție arată astfel:

[Cererea utilizatorului]
      │
      ▼
[Orchestrator: sesiune, auth, limite de buget]
      │
      ├─► [getToolsForSession()] ──► whitelist de tool-uri
      │
      ▼
[Apel API LLM cu definiții de tool]
      │
      ▼
[Apel de tool de la model]
      │
      ▼
[Validator de argumente]
      │
      ▼
[Wrapper de tool: retry, timeout, erori structurate]
      │
      ▼
[Execuția tool-ului real]
      │
      ▼
[Rezultat → înapoi la LLM, cu emisie de telemetrie]
      │
      ▼
[Buclează până la terminare sau buget atins]
      │
      ▼
[Garduri de output: PII, citare, politică]
      │
      ▼
[Răspuns către utilizator]

Acest lucru nu este nou. Este versiunea inginerită pentru producție a ceea ce omite fiecare tutorial "construiește un agent în 50 de linii". Fiecare casetă din diagramă corespunde unei clase reale de incidente pe care le-am văzut în sistemele clienților.

Rezumatul onest

Agenții în producție sunt o problemă de inginerie cu o gaură în formă de LLM la mijloc. Modelul este o componentă, nu sistemul. Sistemul este tot ce este în jurul lui: granița de autentificare, suprafața de tool, validatoarele, limitele de buget, lanțurile de fallback, telemetria, gardurile.

Când clienții întreabă "care este secretul pentru a face agenții să funcționeze?", răspunsul este genuin plictisitor: construiește straturile. Echipele ai căror agenți funcționează sunt cele care tratează sistemele agentice ca probleme de sisteme distribuite cu invarianți stricți — iar echipele ai căror agenți nu funcționează sunt cele care încă speră că următoarea lansare de model îi va salva.

Nu o va face. Următoarea lansare de model va fi mai bună la apelarea tool-ului greșit mai încrezător. Straturile sunt munca.