De ce au nevoie de fapt agenții AI de la infrastructură: 7 cerințe și unde le stă în cale hostingul gândit pentru oameni

Cea mai mare parte a hostingului a fost proiectată în jurul unei persoane la tastatură: un formular de înregistrare, un card, un dashboard, un e-mail când ceva merge prost. Un agent AI care are nevoie de putere de calcul nu se potrivește niciunuia dintre pași. Nu poate rezolva un captcha, nu poate deosebi o pagină de mentenanță de una stricată și nu va observa că a creat același server de patruzeci de ori.

E tentant să spui „dă-i doar un API”. E prima cerință, nu ultima. Mai jos sunt șapte pe care le considerăm importante, din construirea propriului server MCP și REST API pentru agenți. Pentru fiecare: ce merge prost fără ea.

1. Tot ce-i trebuie unui agent e programabil

Crearea, inspectarea, redimensionarea și ștergerea resurselor trebuie să meargă fără browser. Asta include și părțile plictisitoare: aflarea prețului înainte de cumpărare, verificarea dacă o locație are capacitate, citirea parolei unei mașini noi, anularea.

Fără asta: agentul ajunge la 80% din drum și se oprește la singurul pas care cere un clic, iar un om trebuie oricum să termine treaba. Un API parțial e adesea mai rău decât niciunul, pentru că invită automatizări care nu se pot încheia.

2. Erori pe baza cărora un program poate acționa

Un agent citește un răspuns și decide ce face mai departe. Un corp JSON cu un cod stabil (402 insufficient_balance, 409 sandbox_paused, 429 budget_exceeded, cu momentul în care se resetează) e ceva după care se poate ramifica. O pagină HTML de eroare sau un 500 cu un mesaj vag îl lasă să ghicească: adesea reîncercând ceva ce nu va reuși niciodată.

Fără asta: bucle de reîncercare. Cele mai scumpe eșecuri ale agenților nu tind să fie deciziile greșite; sunt același apel eșuat, repetat de mii de ori.

3. Plată fără om în buclă

Plățile cu cardul sunt pline de pași construiți ca să confirme că e prezentă o persoană: coduri 3-D Secure, confirmări în aplicația băncii, verificări de identitate. Sunt bune pentru prevenirea fraudei și imposibile pentru software. Un sold preplătit, alimentat dinainte (în cazul nostru, adesea cu stablecoins), îi permite unui agent să plătească pentru ce folosește fără ca un om să aprobe fiecare taxare.

Fără asta: fie un om aprobă fiecare cumpărătură, ceea ce anulează rostul, fie cineva îi dă unui agent un card, un risc pe care nu ar trebui să și-l asume nimeni.

4. Limite ferme pentru cheltuieli

Un sold preplătit plafonează cel mai rău caz la cât e în el. Poate fi totuși mult. Un plafon zilnic și lunar, în dolari, aplicat de platformă, nu de bunele intenții ale agentului, transformă un agent prins într-o buclă într-o pierdere mică. Plafonul ar trebui să eșueze zgomotos, cu o eroare pe care agentul o recunoaște, și să oprească sau să pună pe pauză ce rulează.

Fără asta: afli de buclă din sold. Facturarea sandboxurilor are plafoane tocmai din motivul ăsta, iar pagina MCP guardrails sugerează ce acțiuni ar trebui să ceară deloc aprobarea unui om.

5. Putere de calcul la granularitatea potrivită

Agenții produc trei feluri foarte diferite de muncă:

• Secunde: rulează un fragment generat, verifică un răspuns, încearcă o reparație.
• Ore: o evaluare, un scraping, un build lung.
• Mereu pornit: un bot, un API, un worker programat.

O platformă care oferă doar servere lunare face primul fel absurd de scump; una care oferă doar sandboxuri de scurtă durată îl face fragil pe al treilea. O sarcină de 20 de secunde pe o mașină taxată pe oră plătește 59 de minute de nimic. Cum funcționează facturarea la secundă arată unde încetează fiecare model să aibă sens.

Fără asta: agenții fie plătesc prea mult pentru munca scurtă, fie rulează servicii de lungă durată pe o infrastructură care nu era făcută să rămână pornită.

6. Izolare implicită

Codul pe care îl scrie un agent e cod pe care nu l-a verificat nimeni. Ar trebui să ruleze undeva unde nu e nimic de valoare: nu pe hostul agentului însuși, nu pe un server cu cheile tale, nu pe mașina care îți trimite e-mailurile. În practică, asta înseamnă o VM sau un microVM separat pentru fiecare sarcină, șters după aceea. Nivelurile de izolare pentru cod nesigur compară opțiunile; microVM-urile Firecracker, explicate arată de ce contează un kernel propriu.

Fără asta: primul prompt injection care ajunge în codul generat are acces la tot ce poate atinge hostul agentului.

7. Vizibilitate și un buton de oprire

Omul responsabil pentru un agent trebuie să vadă ce a făcut agentul și să-l poată opri repede. Asta înseamnă consumul și costul pe fiecare resursă, o listă a tot ce a creat agentul și o cale de a șterge totul. Datele de acces ar trebui să poată fi revocate și să aibă o durată destul de scurtă încât una scursă să nu fie valabilă la nesfârșit, cu o cale de reîmprospătare care nu cere o persoană.

Fără asta: curățenia devine arheologie. Resursele uitate se facturează mai departe; un token scurs merge mai departe.

De ce nu au nevoie agenții

La fel de grăitor e ce nu ajută: dashboarduri proiectate să vândă în plus, e-mailuri de bun venit, planuri ale căror limite reale sunt într-o notă de subsol, prețuri afișate abia după înregistrare. Nimic din toate astea nu poate fi citit de software, iar o parte chiar induce în eroare un model care ia textul literal.

Ce e încă nerezolvat

Nu tot ce e aici e o problemă de inginerie rezolvată.

• Răspunderea. Cineva e responsabil pentru ce face un agent cu un cont. Platformele au nevoie de o cale de a lega activitatea automatizată de o persoană responsabilă, fără s-o forțeze pe acea persoană prin fiecare pas.
• Abuzul. Înregistrarea deschisă, complet automată, e exact ce vor și cei care abuzează. Fiecare platformă care servește agenți echilibrează accesul fără frecare cu fermele de conturi și mining-ul, și niciuna nu are un răspuns perfect.
• Fluxurile lungi. Agenții eșuează în continuare mai des la procese de zece pași decât la apeluri singulare. Infrastructura poate ajuta făcând fiecare pas idempotent și starea lui ușor de interogat, ca o reîncercare să continue, nu să dubleze.

Unde am ajuns

Am încercat să construim pentru aceste cerințe, nu în jurul lor: un server MCP și un REST API care acoperă tot ciclul de viață, erori lizibile de mașini, un sold preplătit, plafoane de cheltuieli, sandboxuri de cod facturate la secundă pentru munca scurtă și servere lunare, ca planul AI agent, pentru munca de lungă durată. O prezentare a părții de sandboxuri e în sandbox pentru agenți AI. Preferăm să judeci lista după propriile ei merite; e o listă de verificare utilă pentru orice platformă pe care lași un agent liber.