Ce se întâmplă, de fapt, când un sistem Agentic AI face lucruri pentru tine?
Ghidul pe înțelesul tuturor pentru sistemele AI agentice — fără jargon, prin analogie cu un hotel. Agenți, orchestratori, containere și webhook-uri explicate prin recepționer, cameriste și sonerii.
Probabil ai auzit deja oamenii vorbind despre „agenți AI”, „orchestratori”, „containere” și „webhook-uri” — pe stradă, la birou, la cafea, în reclamele de pe LinkedIn. Sună important. Sună complicat. Sună ca și cum ar trebui să știi deja despre ce e vorba.
Hai să-ți spun un secret: nu trebuie. Nimeni nu s-a născut știind cuvintele astea. Iar majoritatea celor care le folosesc nu le explică nimănui pentru că, sincer, nici ei nu sunt foarte siguri.
Articolul ăsta îți va explica, fără să te trateze de sus, ce sunt aceste „creaturi digitale” și cum trăiesc ele împreună ca să facă lucruri pentru tine. Nu te vom face programator. Te vom face un om care înțelege ce vede în jur.
Și o să folosim, peste tot, analogia hotelului — pentru că funcționează surprinzător de bine. La capătul articolului, vei avea o imagine clară în cap: un hotel mare, cu personal cu uniforme diferite, fiecare cu rolul lui, totul orchestrat ca într-un balet bine repetat.
1. Marea diferență: AI care răspunde vs. AI care face
Începem cu o distincție fundamentală.
Există două tipuri de AI cu care te poți întâlni în lume:
Tipul 1 — AI-ul care răspunde. Îl întrebi ceva, îți răspunde. Atât. ChatGPT, în forma lui clasică, e așa. Îl întrebi „cum gătesc paste”, îți dă rețeta. Conversația se termină acolo. Dacă închizi browserul, el nu mai face nimic — nu are unde să se ducă, nu are ce să facă.
Tipul 2 — AI-ul care face. Acesta nu doar răspunde. Acționează în lume. Trimite mail-uri. Programează întâlniri. Cumpără bilete. Monitorizează evenimente. Te anunță când ceva se întâmplă. Și — partea importantă — continuă să existe și când tu nu ești acolo.
Al doilea tip se numește sistem agentic. Iar în spatele lui nu există „un AI”. Există o întreagă echipă. Cu roluri clare. Cu o casă comună. Cu reguli de comunicare.
Ca într-un hotel.
Platforma noastră Demeter e exact asta — o echipă de agenți autonomi care orchestrează workflow-uri reale de business, cu audit complet pentru fiecare acțiune.
2. Cei patru actori principali
Imaginează-ți un hotel mare. Patru-cinci stele. Personal numeros, fiecare în uniforma lui. Hai să-i cunoaștem.
🧹 Camerista — agentul
În două propoziții: Camerista e cea care face muncă concretă. Curăță, pune apă, aranjează, raportează. Stă la post toată ziua, e plătită pentru ce face cu mâinile ei.
În sistemele AI, ea se numește agent. E un program care trăiește non-stop și care face un lucru real în lume. Nu doar răspunde — acționează.
Caracteristici esențiale:
- Are un job principal și îl știe foarte bine
- Stă disponibilă 24/7 — nu pornește de la zero la fiecare cerere
- Are memorie despre ce a făcut și ce mai are de făcut
- Poate decide singură în limitele date
De ce e ca o cameristă, nu ca un consultant? Pentru că nu vine să-ți spună „eu cred că ar trebui să faci X”. Vine, face X, te anunță că s-a făcut.
Un sistem real are de obicei mai mulți agenți, fiecare cu o specialitate: unul se ocupă de email, altul de calendar, altul de plăți, altul de monitorizare. Nu un singur agent care le face pe toate — pentru că ar deveni haotic. Imaginează-ți un hotel cu o singură cameristă care face și recepție, și bucătărie, și mecanică. Nu merge.
🔧 Specialistul — sub-agentul
În două propoziții: Specialistul e omul care vine doar pentru un anumit lucru. Lustruiește oglinzile. Sau verifică instalația electrică. Sau aduce un aspirator industrial când e nevoie.
În sistemele AI, el se numește sub-agent. E o piesă specializată pe care un agent o folosește când are nevoie. Nu trăiește singur, nu are camera lui — apare când e chemat și pleacă după ce a terminat.
De ce există? Pentru că ar fi absurd ca fiecare cameristă să știe să facă totul perfect. E mai eficient să spui:
- „Tu, cameristă, decizi ce trebuie făcut în cameră.”
- „Tu, specialistul în oglinzi, vino să le lustruiești.”
- „Tu, specialistul în covoare, vino să le aspiri profesional.”
Fiecare cu jobul lui. Schimbi unul fără să strici restul.
Exemple reale de sub-agenți: „cel care clasifică”, „cel care rezumează”, „cel care verifică o adresă de email”, „cel care traduce între limbi”. Fiecare e foarte îngust, dar foarte bun la ce face.
🎩 Recepționerul — orchestratorul
În două propoziții: Recepționerul nu face muncă concretă. Nu curăță. Nu gătește. Nu repară. Dar fără el, nimeni nu știe ce să facă.
În sistemele AI, el se numește orchestrator. Numele vine de la „orchestră” — și chiar e ca un dirijor: nu cântă, dar fără el muzicienii nu intră la timp.
Ce face concret:
- Primește o cerere (de la un client, de pe internet, de oriunde)
- Decide cine se ocupă de ea
- O trimite la cine trebuie
- Notează ce s-a întâmplat
Atenție la o greșeală frecventă: mulți cred că „orchestratorul e cel deștept, agenții doar îi execută ordinele”. E fix invers. Orchestratorul e deliberat „prost” — știe doar să routeze, să dirijeze traficul. Agenții sunt cei care chiar decid ce să facă cu fiecare cerere.
De ce așa? Pentru că dacă pui logica reală („cum se rezolvă X”) în orchestrator, devine un coșmar de întreținut. Cu agenți separați, schimbi cum funcționează un agent fără să atingi nimic altceva. Recepționerul nu trebuie să știe cum se spală o pernă — doar să știe la cine s-o trimită.
👮 Managerul de etaj — supervisorul
În două propoziții: Managerul de etaj nu face muncă utilă pentru oaspete. El doar trece, periodic, prin toate camerele și verifică că totul e bine.
În sistemele AI, el se numește supervisor. Jobul lui e o singură întrebare, pusă din nou și din nou: „Mai trăiești?”
Cum verifică? Trimite o întrebare scurtă fiecărui agent și se uită la răspuns:
- 🟢 Răspuns rapid și clar → totul ok
- 🟡 Răspuns greoi sau cu întârziere → atenție
- 🔴 Niciun răspuns → alarmă, trezește pe cineva
Aceste verificări se numesc healthcheck-uri (verificări de sănătate). Iar dacă un agent e mort, sistemul îl repornește automat. Despre asta vorbim în secțiunea următoare.
Tabel rezumat
| Rol | Face muncă utilă? | Ia decizii? | Trăiește 24/7? |
|---|---|---|---|
| Cameristă (Agent) | ✅ Da, principala lui ocupație | ✅ Da, în domeniul lui | ✅ Da |
| Specialist (Sub-agent) | ✅ Doar un lucru foarte îngust | ⚠️ Doar despre specialitate | ❌ Apare la cerere |
| Recepționer (Orchestrator) | ❌ Nu, doar routează | ❌ Doar „cine primește ce” | ✅ Da |
| Manager (Supervisor) | ❌ Nu | ❌ Doar verifică sănătatea | ⏰ Trece periodic |
3. Unde locuiesc ei? — container, Docker, Swarm
Bine, am stabilit cine sunt. Dar unde stau acești agenți? Pe ce calculator? Cum nu se calcă pe picioare?
Aici intră în scenă cuvintele alea care sună a buzzword: container, Docker, Swarm.
📦 Container — camera personală a agentului
Imaginează-ți un bloc cu multe apartamente. Fiecare apartament e mobilat complet, are propriile facilități, e izolat de vecini. Ce se întâmplă în apartamentul tău nu afectează apartamentul vecinului. Ai propria ta cheie. Propriile tale lucruri.
Un container e exact asta, dar pentru programe. E un „apartament digital” în care trăiește un program (un agent, de exemplu) împreună cu tot ce-i trebuie să funcționeze — librării, configurări, fișiere, tot.
De ce e genial? Pentru că rezolvă coșmarul „funcționează pe calculatorul meu”. Dacă programul tău e într-un container, va rula identic pe laptopul tău, pe serverul din cloud, pe orice mașină. Containerul își cară casa cu el.
🐳 Docker — compania care construiește camerele
Docker e numele tehnologiei care creează și gestionează containere. E ca firma de construcții care a făcut apartamentele, dar și ca administratorul care le ține în viață: le pornește, le oprește, le mută.
Practic, când cineva spune „rulează asta în Docker”, înseamnă: ia programul, împachetează-l într-un container și pornește-l.
🐝 Docker Swarm — hotelul cu management automat
Acum imaginează-ți nu un singur bloc, ci un întreg cartier rezidențial cu multe blocuri. Și un management deștept care:
- Vede când un apartament are probleme și mută locatarul în altul
- Asigură că dacă un bloc cade, locatarii nu rămân pe stradă
- Distribuie noii locatari în blocurile cu cea mai mică încărcare
- Verifică din 30 în 30 de secunde dacă fiecare apartament are curent
Docker Swarm e exact asta: un sistem care coordonează multe containere pe mai multe servere, gata să le repornească dacă mor, să le mute dacă un server cade.
E ceea ce face diferența între „am rulat un program pe un calculator” și „am un sistem care merge non-stop, fără să stea cineva să-l îngrijească”.
Pentru cei care au auzit de Kubernetes: Kubernetes face același lucru ca Swarm, dar e mai puternic și mai complicat. Sunt în aceeași familie de soluții, doar la scale diferite. La fel cum Marriott e mai mare decât un mic lanț local — același business, scară diferită.
4. Cum „aud” și „vorbesc” între ei?
Bine, agenții stau în camerele lor. Dar cum aud când îi cheamă cineva? Cum se înțeleg între ei?
Aici intră cuvintele care confundă cel mai mult oamenii pentru că sună similar: webhook, hook, pub/sub, API. Hai să le clarificăm cu trei metafore simple — toate din hotel.
🔔 Soneria de la ușă — webhook
Imaginează-ți că ești la recepție. Vine cineva de afară. Sună la sonerie. Tu auzi imediat și răspunzi.
Un webhook e exact asta, dar pentru programe. E o adresă pe internet (un URL) la care altcineva poate „suna” trimițând o mică notificare. Programul tău aude soneria și reacționează.
Exemplu concret: când plătești ceva online cu cardul, banca trimite un webhook către magazinul de unde ai cumpărat: „hei, plata a trecut!”. Magazinul aude, marchează comanda ca plătită, îți trimite confirmare. Tu nu vezi nimic din asta — dar fără webhook, magazinul nu ar ști când să-ți expedieze produsul.
Confuzie tipică: „hook” și „webhook” sună la fel, dar nu sunt fix la fel. Webhook = sonerie din afară. Hook = un cui pe care poți atârna ceva în interior. Vorbim despre hook-uri mai jos, la skills.
📻 Radio-ul intern — pub/sub
Acum imaginează-ți stația de radio internă a hotelului. Recepționerul apasă butonul și anunță prin difuzoare:
„Toate cameristele de la etajul 3, vă rugăm la camera 305.”
Difuzoarele transmit anunțul în tot hotelul. Dar doar cameristele de la etajul 3 reacționează. Celelalte aud, dar nu le privește. Recepționerul (cel care anunță) nu trebuie să știe unde e fiecare cameristă — doar publică pe „canalul etaj 3” și toate cele interesate aud.
Acesta e modelul pub/sub (publish/subscribe — publică/abonează):
- Cineva publică un mesaj pe un canal numit
- Cei care s-au abonat la canalul ăla primesc mesajul
- Ceilalți nu sunt deranjați
Tehnologii populare: Redis, RabbitMQ, Kafka. Numele lor apar des în conversații tehnice — sunt diferite mărci de „radio intern”.
📞 Telefonul direct — API
Ultima variantă: vrei să întrebi o singură persoană ceva specific. Suni direct, primești răspuns, închizi.
Un API (Application Programming Interface) e exact așa: modul prin care două programe vorbesc direct între ele. Cerere clară, răspuns clar, conversație unu-la-unu.
Exemple: când agentul tău trimite un mail, folosește API-ul Gmail. Când rezervă un zbor, folosește API-ul liniei aeriene. Când postează pe Twitter/X, folosește API-ul lor. API-urile sunt mâinile prin care agentul atinge lumea exterioară.
⚡ Și încă o magie: cum face un agent multe lucruri „simultan”
Aici e o confuzie mare. Hai s-o lămurim cu o poveste.
Imaginează-ți o cameristă super-eficientă, sâmbătă dimineață. Are de făcut: rufele, supa pentru personal, prăjitura pentru oaspeți, și să răspundă la telefonul intern când sună. Cum procedează?
Varianta proastă: pune rufele, stă lângă mașina de spălat o oră fără să facă nimic, abia apoi începe supa. Total ineficient.
Varianta inteligentă:
- Pune rufele și pleacă — mașina se învârte singură
- Începe supa, taie legumele
- Aude beep-ul mașinii — întoarce și pune ciclul de uscare
- Continuă supa
- Sună telefonul — răspunde
- Între timp pune și prăjitura la cuptor
- Verifică toate trei în timp ce vorbește
Aceasta e cameristă cu event loop. E una singură, dar pentru că treaba ei e mai mult să aștepte lucruri (mașina, cuptorul, telefonul), folosește timpul de așteptare ca să facă altceva.
Asta e ce permite unui agent să asculte cereri prin webhook, să răspundă pe radio-ul intern, să-și ruleze treburile programate, toate aparent în același timp — fără să aibă nevoie de mai multe „creiere” paralele.
5. Ce „știu” agenții să facă? — skills, plugins, LLM
Bine, agenții ascultă, comunică, sunt vii. Dar cum știu ei ce să facă exact?
🎯 Skill — rețeta din bucătărie
Un skill (în română: pricepere, abilitate) e un pachet de instrucțiuni care învață un agent cum să facă un lucru anume.
Analogie: un skill e ca o fișă de rețetă de pe peretele bucătăriei unui hotel. „Cum se face un sos olandez perfect” — o fișă. „Cum se prepară aluatul de pâine” — altă fișă. Bucătarul (agentul) e același. Rețeta îl învață ce să facă într-o situație anume.
Bucătarul citește rețeta înainte să gătească, urmează pașii, livrează rezultatul. Mâine, dacă vine o rețetă nouă, o pune pe perete și gata — bucătarul a învățat un fel nou.
🔌 Plugin — aspiratorul industrial
Un plugin (de la „plug in” — a băga în priză) e o unealtă reală adăugată care extinde ce poate face un agent.
Analogie: dacă camerista are unelte de bază (cârpa, găleata, mătura), plugin-urile sunt aspiratorul industrial pe care îl scoți din depozit doar pentru ocazii speciale, sau mașina de spălat covoare, sau suflătorul de praf pentru tablouri. Camerista nu le folosea ieri. Le folosește azi. Le-a învățat să le folosească. Acum face mai mult decât înainte.
Plugin vs Skill — diferența:
- Skill = instrucțiuni („cum se face ceva”)
- Plugin = o unealtă reală adăugată („cu ce se face”)
În practică, granița se șterge — multe sisteme folosesc cuvintele aproape interschimbabil.
🧠 LLM — „creierul gânditor”
Aici venim la inima problemei. Ce face un „agent AI” cu adevărat inteligent? De ce nu e doar un script obișnuit?
Răspunsul: LLM — Large Language Model. Modele mari de limbaj. ChatGPT, Claude, Gemini, Llama — sunt LLM-uri. Sunt „creierele” pe care agenții le folosesc ca să înțeleagă limbajul natural și să decidă ce să facă.
Atenție la confuzia mare: un agent NU este un LLM. Un agent folosește un LLM, dar e mult mai mult decât atât. LLM-ul e doar partea care gândește. Restul (cum acționează, unde stochează date, cum comunică, cum aude comenzi) e tot codul „obișnuit” din jur.
E ca diferența dintre un șofer și o mașină cu șofer. LLM-ul e șoferul. Agentul e mașina cu șofer plus toate sistemele care fac ca acea mașină să existe în lume: combustibil, asigurare, GPS, parcare, întreținere. Fără șofer, mașina nu pleacă nicăieri. Dar nici doar un șofer fără mașină nu te duce nicăieri.
6. Ritmul vieții lor — cron și momente fixe
Un agent acționează în două ritmuri:
- Reactiv — când cineva îi cere ceva (prin sonerie/webhook, pe radio/pub-sub, sau direct la telefon/API)
- Proactiv — la momente prestabilite, fără să fie chemat
Pentru ritmul al doilea apare cuvântul cron.
⏰ Cron — ceasul programat
Cron e un sistem care pornește programe la momente exacte. „În fiecare zi la 03:00”, „În fiecare luni la 9 dimineața”, „La fiecare 5 minute”.
E vechi (există de zeci de ani pe sistemele Linux), simplu, și extrem de fiabil. Fiecare server are unul. E ca orarul de pe panoul cameristei: „09:00 — etaj 1. 10:30 — pauză. 11:00 — etaj 2.”
Exemple de utilizare în sistemele agentice:
- La fiecare 5 minute: supervisorul Iris verifică sănătatea agenților
- În fiecare noapte la 3: agentul de backup salvează datele
- În fiecare luni dimineață: agentul de raportare trimite raportul săptămânal
Există și o variantă mai modernă: în loc de cron extern, agentul are o alarmă internă care îl trezește singur, fără ajutor din afară. Ambele variante funcționează. În sistemele moderne se folosesc adesea împreună.
7. MVP — De unde începi când construiești așa ceva?
Aici e secțiunea pe care trebuie s-o citești dacă ai vreodată tentația să construiești un sistem agentic.
MVP = Minimum Viable Product. În română: „cea mai mică versiune care chiar funcționează”.
Hotelul de 200 de camere care nu se deschide niciodată
Imaginează-ți pe cineva care vrea să deschidă un hotel. E ambițios. Vrea spa, restaurant cu stele Michelin, sală de conferințe, 200 de camere, valet parking, room service la pat, golf, terapeut canin, sommelier propriu.
Cât timp îi va lua să deschidă? Cel mai probabil — niciodată. Va rămâne pentru totdeauna în fază de proiect. Pentru că fiecare bucățică în plus dublează complexitatea.
Acum imaginează-ți altcineva care zice: „Deschid o pensiune cu 10 camere. Recepție simplă. O cameristă. Mic dejun continental, fără bucătărie. Asta e tot. Vedem cum merge.”
A doua persoană deschide în 3 luni. Primește primii clienți. Învață. Crește. După un an, are deja experiență și știe exact ce să adauge — pentru că oaspeții reali i-au spus. Poate adăuga restaurantul când are deja cerere demonstrată. Spa-ul când are bani și spațiu.
La fel cu sistemele agentice
Tentația, când vezi cuvintele „orchestrator, sub-agent, supervisor, Swarm, healthcheck, pub/sub”, e să crezi că toate sunt necesare de la început. Nu sunt.
Un MVP de sistem agentic poate avea:
- ✅ Un singur agent care face un singur lucru util
- ✅ Un container Docker simplu pe un server
- ✅ Un cron care îl pornește din când în când
- ❌ Fără orchestrator (nu e nevoie când ai un singur agent)
- ❌ Fără sub-agenți (agentul face tot inițial)
- ❌ Fără supervisor (te uiți tu manual la log-uri în prima lună)
- ❌ Fără Swarm (un singur server e suficient)
- ❌ Fără pub/sub (agentul vorbește direct cu ce are nevoie)
Și asta e suficient. Dacă funcționează, dacă oamenii îl folosesc, dacă aduce valoare reală — atunci adaugi piesele când chiar îți trebuie:
- Apare al doilea agent? → Acum ai nevoie de un mod să-i coordonezi. Vine orchestratorul.
- Devine prea greu agentul? → Spargi părți în sub-agenți.
- Pică des? → Acum ai nevoie de Swarm și healthcheck.
- Mai mulți agenți trimit mesaje multor agenți? → Acum ai nevoie de pub/sub.
Regula de aur: nu construi pentru 1000 de utilizatori când ai 2. Nu construi pentru 100 de agenți când ai 1. Adaugă complexitate doar când durerea de a NU o avea devine mai mare decât durerea de a o avea.
Multe proiecte mor pentru că echipa a construit „arhitectura corectă” de la zero — și a obosit înainte să livreze ceva real. Începe simplu. Crește când îți spune realitatea.
8. O zi în hotel — povestea unei cereri
Acum că avem toate piesele, hai să le punem cap la cap. Cum arată o cerere obișnuită care intră în sistem și iese ca rezultat?
Scena 1: Oaspetele cere ceva
Un client folosește o aplicație. Scrie ceva sau apasă un buton. „Vreau să rezerv o întâlnire pentru mâine”. „Notează-mi această cheltuială”. „Trimite-mi un raport cu vânzările săptămânii”.
Scena 2: Soneria sună la recepție (webhook)
Cererea ajunge instant la URL-ul de intrare al sistemului. Recepționerul (orchestratorul) aude.
Scena 3: Recepționerul decide cine se ocupă (orchestrator)
Recepționerul aruncă o privire la cerere: „E o cerere de rezervare → o trimit la Camerista B. E o cerere de raport → o trimit la Camerista C.”
Apoi face anunțul: pe radio-ul intern (sistemul pub/sub), pe canalul „rezervări”.
Scena 4: Camerista aude și începe (agent)
Camerista B e abonată la canalul „rezervări”. Primește mesajul. Înțelege ce trebuie făcut. Începe lucrul.
Scena 5: Cheamă specialistul dacă e nevoie (sub-agent)
„Înainte să fac rezervarea, vreau să verific dacă datele sunt valide.” Cheamă sub-agentul de validare. Sub-agentul face un singur lucru: verifică datele. Răspunde: „OK” / „Nu OK”. Și pleacă.
Scena 6: Camerista termină și notează (audit + storage)
Acțiunea se execută în lumea reală — rezervarea e făcută, raportul e generat, cheltuiala e salvată. Totul se notează în arhiva sistemului, ca să se știe ce s-a întâmplat. Dacă vreodată trebuie să verifici „cine a făcut ce și când”, arhiva îți spune.
Scena 7: Oaspetele primește răspunsul
Notificare push pe telefon, un mail, un mesaj — orice canal era cerut. Clientul vede că s-a făcut.
Și în tot timpul ăsta…
Pe fundal, managerul de etaj (supervisorul) continuă să treacă din 5 în 5 minute pe la fiecare. Recepționerul răspunde? 🟢 Camerista B răspunde? 🟢 Specialistul de validare răspunde? 🟢 Totul bine.
Dacă vreunul nu ar răspunde, Docker Swarm îl repornește automat. În câteva secunde, sistemul e iar întreg.
Tot procesul, de la momentul în care oaspetele cere ceva până când primește răspunsul: câteva secunde.
9. De ce e construit așa? — întrebări frecvente
„De ce nu un singur program mare care face tot?”
Pentru că:
- Dacă pică, pică tot
- Dacă vrei să-l updatezi, trebuie să-l oprești complet
- Dacă crește, nu poți paraleliza
- Dacă cineva strică o parte, strică restul
Cu agenți separați: pică unul, ceilalți merg mai departe. Schimbi un agent fără să atingi restul. Crește bucățile care au nevoie, fără să umfli tot.
„Orchestratorul nu e cel mai important? El conduce totul.”
Cam invers. Orchestratorul e cel mai prost dintre actori — știe doar să routeze. Agenții sunt cei deștepți. Dacă orchestratorul devine deștept, sistemul devine de neîntreținut. Recepționerul de la hotel nu trebuie să știe cum se spală o pernă — doar să știe la cine s-o trimită.
„Agenții AI înlocuiesc oamenii complet?”
Aproape niciodată. Sistemele agentice bine făcute au puncte de aprobare umană la momentele critice. Agenții fac munca grea, omul ia deciziile importante. La fel cum hotelul are personal mult — dar tot e cineva care decide să cumpere mobilă nouă.
„Dacă vorbesc cu un agent, vorbesc cu LLM-ul?”
Parțial. Vorbești cu agentul, care folosește LLM-ul ca să te înțeleagă și să-ți răspundă. Dar tot ce ține de „a face ceva în lume” e cod obișnuit din jurul LLM-ului. Camerista poate fi cea care vorbește cu tine — dar nu mintea ei e cea care curăță camera. Mâinile o fac.
„Cât costă să rulezi un astfel de sistem?”
Foarte variabil. Un MVP simplu pe un server modest poate costa $20-50/lună. Sisteme mari cu mulți agenți și utilizare grea pot ajunge la mii de dolari pe lună (mai ales costul LLM-urilor, dacă sunt apelate des). Costul crește cu volumul, nu doar cu complexitatea.
„De unde încep dacă vreau să construiesc așa ceva?”
Începe simplu. Un agent. Un job clar. Un cron care îl pornește. Vezi dacă funcționează. Vezi dacă oameni reali îl folosesc. Apoi adaugi piese, una câte una. Vezi secțiunea MVP de mai sus — e cel mai important sfat din articol.
Dacă vrei să sari peste partea „construiesc de la zero”, platformele ca Demeter îți dau deja stack-ul (agenți, orchestrator, supervisor, audit) — focus pe ce face agentul, nu pe plumbing.
10. Glosar rapid — pentru reverificare
| Termen | Ce e | Analogie hotel |
|---|---|---|
| Agent | Program care trăiește 24/7 și face muncă concretă | Cameristă cu post fix |
| Sub-agent | Funcție specializată folosită de un agent | Specialist chemat ad-hoc |
| Orchestrator | Routează cereri către agentul potrivit | Recepționer |
| Supervisor | Verifică sănătatea sistemului periodic | Manager de etaj |
| Container | Pachet izolat în care rulează un program | Cameră de hotel mobilată |
| Docker | Tehnologia care creează containere | Firma care construiește camerele |
| Docker Swarm | Multe servere care coordonează containere | Hotelul cu management automat |
| Kubernetes | Variantă mai puternică de Swarm | Lanțul mare de hoteluri |
| Healthcheck | Verificare automată că un program răspunde | „Mai trăiești?” |
| Webhook | URL public unde sistemele externe „sună” | Sonerie de la ușă |
| Hook | Punct intern în cod unde poți adăuga ceva | Cui pe perete |
| Pub/Sub | Sistem de mesaje pe canale tematice | Radio intern |
| Redis / RabbitMQ / Kafka | Tehnologii populare pentru pub/sub | Mărci de radio intern |
| API | Interfață prin care două programe vorbesc | Telefon direct |
| Event loop | Buclă care procesează evenimente unul după altul | Cameristă super-eficientă |
| Cron | Programator care pornește lucruri la ore fixe | Orarul de pe panou |
| Skill | Pachet de instrucțiuni învățate de agent | Rețetă din bucătărie |
| Plugin | Unealtă reală adăugată care extinde agentul | Aspirator industrial |
| LLM | Model AI care înțelege și produce limbaj | Creier gânditor |
| MVP | Cea mai mică versiune care chiar funcționează | Pensiune cu 10 camere |
| Audit | Înregistrare a tuturor acțiunilor sistemului | Registrul de la recepție |
11. Concluzie: AI-ul nu e magie, e o echipă bine organizată
Dacă ai citit până aici, deja înțelegi mai mult decât 95% dintre oamenii care folosesc cuvintele astea zilnic. Hai să rezumăm imaginea de ansamblu.
Un sistem AI agentic e o echipă. Nu un singur „creier” — o echipă de programe care colaborează, fiecare cu rolul lui:
- Cameristele (agenții) fac muncă concretă
- Specialiștii (sub-agenții) îi ajută cu lucruri foarte specifice
- Recepționerul (orchestratorul) dirijează traficul fără să facă el muncă
- Managerul (supervisorul) verifică din 5 în 5 minute că toată lumea e în viață
Toți trăiesc în camere izolate (containere), într-un hotel coordonat (Docker Swarm) care îi repornește dacă pică.
Vorbesc între ei prin sonerii (webhook-uri pentru cereri din afară), radio intern (pub/sub pentru anunțuri pe canale) și telefoane directe (API-uri pentru conversații unu-la-unu).
Sunt programați să acționeze atât reactiv (când li se cere ceva), cât și proactiv (la ore fixe, prin cron).
„Inteligența” lor vine în mare parte de la LLM-uri (creierele gânditoare), dar tot restul — acțiunea în lumea reală — e inginerie atentă în jurul lor.
Și cel mai important: nu trebuie să construiești tot deodată. Începi cu o pensiune cu 10 camere. Verifici că funcționează. Crești când îți spune realitatea. Asta înseamnă MVP. Asta e diferența între un proiect care livrează și unul care moare pe planșetă.
Acum, când vei mai auzi pe cineva spunând „avem un sistem agentic cu orchestrator și sub-agenți care comunică prin pub/sub în containere coordonate de Swarm”, vei putea zâmbi și să-ți spui în gând: „știu fix despre ce vorbește. E un hotel.”
Iar asta — să înțelegi ce vezi, fără să te lași intimidat de jargon — e jumătate din meserie.
Referințe & lectură suplimentară
- Anthropic — Building effective agents (2024) — patterns oficiale pentru construirea agenților.
- Docker — What is a container — definiție canonică Docker containers.
- Docker Swarm overview — orchestrare nativă Docker pentru servicii distribuite.
- Webhooks vs APIs (Stripe Engineering) — distincția practică webhook vs API direct.
- Cron (Linux man page) — clasicul scheduler care încă rulează lumea.
Acest articol face parte din seria „AI demistificat” publicată pe caitech.eu. Următoarele articole vor acoperi prompt engineering, RAG (cum dăm agenților acces la cunoștințe externe), și observabilitate (cum vedem ce se întâmplă în sistem). Rămâi aproape.