Era chatbotului AI simplu se apropie de final. Timp de trei ani, modul implicit de a "adăuga AI" într-un produs a fost o casetă conversațională: utilizatorul scria o întrebare, modelul rezuma un document sau redacta un email, iar restul îl făcea un om. Era util, dar pasiv. Ingineria agentică schimbă fișa postului. Modelul nu mai generează doar text, ci începe să acționeze: decide ce instrument să apeleze, validează inputul și execută în numele tău un flux de lucru real.
Concluzii cheie
- Un chatbot generează text; un agent acționează printr-un set definit de instrumente pe care are voie să le apeleze.
- Model Context Protocol (MCP) îi oferă modelului operațiuni validate și auditate, nu acces liber la sistemele tale.
- Agenții în producție au nevoie de trei lucruri: limite stricte ale datelor, scheme validate și puncte de aprobare umană pentru orice acțiune distructivă.
- Problema grea s-a mutat de la prompt engineering la orchestrarea sistemului.
- Diferența dintre un demo și un produs ține de disciplină, nu de sofisticarea modelului.
Prin ce diferă un agent de un chatbot?
Un chatbot e un model izolat, separat de sistemele tale. Un agent e același model conectat la ele printr-o interfață controlată. Chatbotul răspunde; agentul acționează.
Interfața aia e toată miza. În loc să ceri unui model să "scrie un email", unui agent i se dă un instrument send_email cu o semnătură fixă, pe care îl apelează cu argumente validate, iar emailul chiar pleacă. Modelul devine partea care decide. Instrumentele sunt partea care face.
Ce face de fapt Model Context Protocol?
MCP îi dă modelului un set definit de instrumente și un contract strict pentru folosirea lor. În loc să-i predai modelului baza ta de date, expui un server îngust: poate interoga o tabelă Postgres, actualiza o înregistrare CRM sau declanșa un deploy, dar numai prin endpointuri pe care le-ai publicat explicit, cu fiecare input validat înainte ca ceva să ruleze.
Simon Willison și alții care urmăresc domeniul ăsta repetă aceeași idee: problema grea s-a mutat de la prompt engineering la orchestrarea sistemului. Să faci un model să producă text plauzibil nu mai e blocajul. Să-l faci să execute acțiunea corectă, în siguranță, de fiecare dată, ăsta e blocajul.
De ce are nevoie un agent de nivel de producție?
Trei cerințe sunt nenegociabile. Sari peste oricare dintre ele și ai un demo, nu un sistem.
- Limite stricte ale datelor. Modelul nu primește niciodată acces nerestricționat la o bază de date de producție. Vorbește cu un server MCP care expune un set îngust și auditat de operațiuni, cu autentificare propagată la fiecare apel. Poate citi statusul unui colet. Nu poate rula SQL arbitrar.
- Scheme validate. Fiecare acțiune propusă de model e verificată pe baza unei scheme stricte înainte să se execute. Modelele sunt nedeterministe și vor genera ocazional un apel malformat sau în afara limitelor. Schema e poarta deterministă care îl prinde.
- Puncte de aprobare umană. Citirea și colectarea sunt automatizate. Deciziile care schimbă starea, emiterea unui refund, ștergerea unei înregistrări, transferul de bani, cer confirmare umană explicită. Agentul pregătește acțiunea; un om o aprobă.
De ce dau încă rateuri în producție majoritatea "agenților"?
Pentru că echipele livrează doar calea fericită și sar peste limite. Un model care merge într-un demo, cu suficient trafic real, va apela la un moment dat instrumentul greșit, va returna date greșite cu mult aplomb sau va încerca să acționeze peste autoritatea lui. Fără o schemă care să respingă apelul prost și un om care să-l prindă pe cel riscant, eșecul ăla ajunge la un client.
Soluția nu e un prompt mai bun. E o arhitectură în care acțiunea nesigură e imposibilă prin construcție, nu doar puțin probabilă.
Cum arată de fapt un agent în producție?
Forma e aceeași la toți agenții pe care îi livrăm la Systemartis. Un model stă în spatele unui orchestrator care gestionează rutarea, reîncercările și punctele de control umane. Instrumentele sunt expuse prin servere MCP care validează și loghează fiecare apel. Starea trăiește într-un backend real, nu în fereastra de context a modelului.
Când ceva o ia razna, urma de audit arată exact ce instrument a fost apelat, cu ce input și ce a venit înapoi. Asta face sistemul demn de încredere. "A făcut-o AI-ul" nu e un răspuns pe baza căruia poate acționa cineva. "Agentul a apelat update_shipment cu acest payload la acest moment, iar acesta e răspunsul", da.
Nu mai construi wrappere
Următoarea generație de software nu va fi judecată după cât de bine conversează, ci după cât de fiabil funcționează fără supraveghere. Un wrapper subțire în jurul unui endpoint de chat-completion nu e asta. Un agent cu instrumente reale, limite ferme, apeluri validate și un om care ține cheile la orice e distructiv, ăla da.
Chatbotul a fost un demo util. Agentul e produsul.