spinny:~/writing $ cat agentic-infrastructure-stack.md

Infrastructura agentică și noul backend

2026-06-30 · 10 min read · Filippo Spinella · AI, Agents, Infrastructure, Developer Tools

Am vorbit adesea despre cadrele agentice. LangGraph, CrewAI, AutoGen, diverse SDK-uri, buclă, apelare instrumente, memorie, planificator, critic, supervizor. Toate cuvintele utile, pentru Dumnezeu. Dar cu cât mă uit mai mult la agenții folosiți efectiv, cu atât mai mult mi se pare că partea interesantă s-a mutat sub nivelul cadrului.

Întrebarea nu mai este doar: ce bibliotecă folosesc pentru a face un model pas să gândească?

Adevărata întrebare este: unde locuiește acest agent când încetează să mai fie un demo?

Pentru că un agent serios nu este o funcție care apelează un model și returnează text. Este un mic sistem distribuit. Trebuie să citească contextul, să folosească instrumente, să execute cod, să atingă fișiere, să-și amintească deciziile, să ceară permisiunea, să eșueze bine, să repornească, să lase jurnalele, să nu ardă bugetul și să nu se transforme într-un buldozer în interiorul depozitului de producție.

Cadrul este volanul. Infrastructura este drumul, franele, garajul, asigurarea si persoana care stie unde sunt cheile.

Pentru că acum se vorbește mult despre asta

În 2023 și 2024, conversația a fost foarte centrată pe model. Which LLM? How much context? Cât costã? Cât de bun este la programare?

În 2025 și 2026, conversația s-a schimbat. Modelele sunt suficient de bune pentru a face o muncă reală, dar de aceea devin vizibile biții plictisitoare: timp de rulare, securitate, conectori, identitate, observabilitate, execuție de cod, implementare, rollback.

Este tranziția naturală de la magie la inginerie.

Când un agent trebuie doar să genereze un răspuns, este suficient un chat. Când trebuie să deschideți o cerere de extragere, să interogați o bază de date, să apelați un CRM, să începeți un job, să navigați pe un site, să citiți Slack, să compilați cod și să actualizați un document, aveți nevoie de un sistem de operare în jurul acestuia.

Not in a literal sense. În sens organizatoric.

Prima piesă: un timp de execuție în care agentul poate dura

Un agent lucrează adesea în trepte. Privește starea, alege o acțiune, folosește un instrument, observă rezultatul, actualizează planul, repetă.

Dacă această buclă se află într-o singură solicitare HTTP, aveți imediat o problemă. Some actions are slow. Some await human input. Some fail and must be tried again. Unii trebuie să supraviețuiască unei implementări sau unui timeout.

Aici intră în joc fluxurile de lucru durabile, cozile de așteptare, fundalurile de lucru și mașinile de stat. They're not glamorous, but they're the difference between an agent who seems smart on demo and one you can leave working while you go get coffee.

Pentru mine, runtime-ul agentic trebuie să răspundă la întrebări foarte concrete:

unde salvez starea intre un pas si altul?
ce se întâmplă dacă procesul se stinge la jumătate?
can I pause and ask for approval?
Pot să repet o alergare ca să înțeleg de ce a făcut acea alegere?
can I limit duration, memory, tools and cost?

Vercel face eforturi în acest sens cu SDK-uri AI, funcții, fluxuri de lucru și instrumente pentru crearea de agenți în cadrul aplicațiilor web. Dar ideea nu este doar Vercel. Ideea este că agentul are nevoie de o casă operațională, nu de un singur punct final.

A doua piesa: sandbox, deoarece agentul trebuie sa se poata murdar fara sa se rupa

De îndată ce un agent scrie cod sau execută comenzi, este nevoie de un sandbox.

Pare un cuvânt tehnic, dar ideea este casnică: îi dai un banc de lucru. Poate deschide fișiere, poate instala dependențe, poate rula teste, poate face experimente, poate genera rezultate. Dacă înțelege greșit, ai limitat paguba. Dacă funcționează, promovați rezultatul.

Un sandbox agentic ar trebui să aibă câteva proprietăți:

sistem de fișiere izolat;
CPU, memorie și limite de timp;
retea controlata;
secrete montate doar la nevoie;
jurnalele complete;
posibilitatea de a exporta artefacte;
resetare curată între curse, când este necesar.

Vercel Sandbox merge exact în această direcție: medii izolate pentru a rula cod, a instala dependențe, a lucra cu fișiere și a produce artefacte fără a rula totul în timpul de rulare al aplicației principale.

Acest lucru este mai important decât pare. Multe prototipuri agentice sar direct de la model la sistemul real. Modelul poate apela instrument. Instrumentele pot face lucruri. Totul pare elegant până la prima comandă greșită, prima dependență instalată în locul greșit, primul token care ajunge într-un jurnal.

Cutia de nisip este modul adult de a spune: mergeți mai departe, dar aici.

A treia piesă: MCP și problema conectorului

Protocolul de context al modelului a devenit una dintre cele mai interesante părți ale ecosistemului, deoarece încearcă să standardizeze ceva care altfel devine rapid de negestionat: modul în care un model descoperă și folosește instrumente externe.

Fără un standard, fiecare integrare este o mică insulă. Un conector pentru GitHub făcut într-un fel, unul pentru Slack făcut altul, unul pentru baze de date cu semantică diferită, unul pentru automatizarea browserului care arată ca nimic.

MCP propune un limbaj comun între client și server: instrumente, resurse, prompturi, autorizații, transport, descoperire. Nu rezolvă în mod magic guvernarea și securitatea, dar oferă o gramatică.

Și gramatica contează. Când un agent se poate conecta la mai multe instrumente, întrebarea nu este doar „poate să o facă?”. Problema este „înțelege el ce poate face, cu ce limite, în numele cui și lasă ce urmă?”.

Pentru mine MCP nu este hype pentru că „face apeluri de instrumente”. Am făcut asta deja. Este hype pentru că schimbă centrul de greutate de la integrarea unică la catalogul operațional de instrumente.

Într-o arhitectură agentică bună, MCP devine un fel de panou de corecție:

GitHub pentru cod și probleme;
Slack pentru context conversațional;
Linear sau Jira pentru lucru planificat;
baza de date doar citire pentru analize;
browser sau scraper controlat pentru site-uri externe;
stocarea documentelor;
medii izolate de execuție;
sisteme interne expuse cu permisiuni stricte.

Partea dificilă este că un catalog de instrumente fără politici este doar o modalitate mai elegantă de a crea haos.

A patra piesă: identitate și permisiuni

Aceasta este zona în care multe demonstrații închid ochii.

Un agent acționează în numele cuiva. Deci trebuie să fie clar cine este subiectul acțiunii.

Folosește permisiunile utilizatorului? De un cont de serviciu? Un spațiu de lucru? Ai acces temporar sau permanent? Puteți citi totul sau doar câteva resurse? Poți să scrii? Poți anula? Can he text real people?

Daca nu raspunzi bine la aceste intrebari, mai devreme sau mai tarziu vei construi un asistent cu cheile de la casa si fara amintire cine i le-a dat.

Regula generală care îmi place este aceasta: agentul trebuie să poată face mai puțin decât omul, nu mai mult decât omul. Și când trebuie să facă ceva mai riscant, trebuie să se oprească și să întrebe.

Aceasta înseamnă OAuth, token scoped, secret management, audit log, tool policy, allowlist, step de aprobare. Chestii nu prea romantice. Lucruri necesare.

A cincea piesă: memorie și context, dar fără a acumula gunoi

Agenții au nevoie de memorie, dar memoria este periculoasă când devine mansardă.

Există cel puțin trei tipuri de memorie:

run memory: ce s-a întâmplat în această execuție;
memoria de proiect: convenții, decizii, constrângeri;
memorie personală sau de echipă: preferințe, ton, ritualuri, procese.

Punerea totul în prompt este scurtătura. Funcționează până nu mai funcționează. Trebuie avută grijă de memorie utilă: indexată, actualizată, expirată, verificată, citată.

Un agent care își amintește rău este mai rău decât un agent care nu își amintește. Pentru că vorbește cu încredere.

Prin urmare, infrastructura trebuie să includă regăsire, fișiere de instrucțiuni, bază de cunoștințe, încorporare atunci când este necesar, dar și curățare. Avem nevoie de o cultură a memoriei: ce intră, cine o aprobă, când decade, cum o corectez.

A șasea piesă: observabilitate, evaluare și reluare

Dacă un agent greșește, jurnalul „numit model” nu este suficient.

Vrei să vezi traseul. Ce context a primit? Ce instrumente erau disponibile? Ce instrument ai ales? Cu ce argumente? Ce răspuns ai primit? Cât a costat? Unde s-a blocat? Omul a aprobat ceva? Modelul de eroare, instrumentul, promptul, datele sau permisiunea este o eroare?

Aici agenții sunt mai mult ca sisteme distribuite decât chatbot.

Aveți nevoie de urme care pot fi citite, nu doar de jurnalele de text. Trebuie să poți reda o alergare. Este necesar să comparați două versiuni ale aceluiași agent pe sarcini cunoscute. Trebuie să măsurăm regresiile: nu numai că „răspunde mai bine”, dar „închide biletul potrivit fără a atinge fișierele nesolicitate”.

Evaluările agentice sunt mai dificile decât evaluările text, deoarece includ acțiuni. Nu este suficient să compari un șir așteptat. Trebuie să te uiți la secvențe, efecte secundare, calitatea artefactului, timp, cost, număr de intervenții umane.

Lucrul amuzant este că mereu ne întoarcem acolo: ingineria software. Teste, medii, urme, rollback. Cu excepția faptului că codul decide acum și ce să facă în continuare.

A șaptea piesa: interfețele umane

Agentul nu trebuie să trăiască doar într-un chat.

Unii agenți au nevoie de un panou. Alții o pagină cu stare și jurnal. Altele dintr-un buton „aprobă”. Mai multe comentarii inline. Încă altele dintr-un CLI.

Interfața de utilizare schimbă comportamentul. Dacă singura modalitate de a controla un agent este să scrieți un mesaj lung, utilizatorul îi va oferi agentului instrucțiuni vagi. Dacă, totuși, vede planul, diferența, sursele, riscurile și următoarea acțiune, poate interveni cu precizie.

O infrastructură decentă a agenților include suprafețe de control:

current status;
plan editabil;
artefacte produse;
diferență;
cereri de aprobare;
cronologie;
buton de oprire;
butonul de reîncercare;
permisiuni vizibile.

Pare banal, dar nu este. Diferența dintre „AI înfiorător” și „asistent de încredere” este adesea doar că acesta din urmă vă arată unde are mâinile.

Stiva mentală

Dacă ar fi să-l desenez astăzi, stiva minimă de agenți ar fi aceasta:

Model: raționament, generare, apelare instrument, multimodal dacă este necesar.
Orchestrare: buclă, pas, planificator, politică, om-în-buclă.
Timp de rulare durabil: flux de lucru, coadă, reîncercare, pauză, reluare.
Sandbox: execuție de cod, sistem de fișiere izolat, limitări, artefacte.
Stratul instrument: MCP, API intern, browser, bază de date, depozit.
Stratul de identitate: OAuth, scope, secret, audit, policy.
Stratul de memorie: contextul proiectului, regăsire, instrucțiuni, expirare.
Observabilitate: indicatori de urmărire, reluare, evaluare, cost și calitate.
Suprafața produsului: chat când este suficient, tablou de bord când este necesar, revizuiește când contează.

Cadrul agentic acoperă în principal punctele 2 și o bucată din punctul 1. Restul este munca adevărată.

Ce aș face în practică

Dacă o echipă mi-ar spune „vrem agenți în producție”, nu aș începe cu zece agenți.

Aș începe cu un flux de lucru mic, repetitiv și observabil. De exemplu: deschideți PR-uri de întreținere, actualizați documentația din problemele închise, pregătiți o revizuire săptămânală, triați erori duplicate, generați teste pentru fișierele afectate.

Atunci aș stabili limite foarte clare:

fara scris fara crengi sau nisip;
fără secrete în prompt;
instrumente în lista de permise;
aprobarea umana pentru actiunile externe;
log și urmărire obligatorii;
buget pe run;
ieșire întotdeauna inspectabilă.

Abia atunci m-as extinde.

Agenții nu eșuează doar pentru că modelele înțeleg greșit. Ei eșuează pentru că le punem în medii vagi, cu permisiuni și așteptări teatrale confuze.

Lectura mea

Infrastructura agentică este plictisitoare în cel mai bun mod.

Nu este partea care te face să aplaudați în demo. Este partea care vă permite să utilizați demo-ul luni dimineața, cu oameni reali, date reale și consecințe reale.

Viitorul agenților nu va fi decis doar de cine are cel mai bun model. O va decide oricine construiește cel mai bun loc în care să-l facă să lucreze: izolat când experimentează, conectat la nevoie, mereu observabil, autorizat cu criterii și suficient de umil încât să se oprească când nu știe.

Acolo, agenții nu mai sunt o jucărie și devin infrastructură.

Surse