Decodorul numelor de produse AI: ce este fiecare și unde se află în stack

120–150 de minute · +60–90 de minute pentru exerciții · Nivel: începător · Recomandat înainte: Lecțiile 1–3

Lecția pe scurt

Întrebarea centrală: când întâlnești un nume precum OpenClaw, Hermes, NemoClaw, OpenShell, Ollama, Hugging Face, NeMo, NIM, LangGraph sau MCP, cum afli ce fel de lucru este, ce responsabilitate îndeplinește și cu ce nu trebuie confundat?

În Lecția 1 ai învățat să nu clasifici un sistem după eticheta de marketing. În Lecția 2 ai separat modelul de bucla agentului, de stare și de instrumente. În Lecția 3 ai construit harta completă a stack-ului prin cele 14 responsabilități: hardware fizic; sistem de operare și drivere; platformă de accelerare; limbaj, runtime și dependențe; framework ML și biblioteci numerice; artefactul modelului; runtime de inferență și server de model; controllerul agentului; instrumente și integrări; date, stare, memorie și retrieval; securitate, identitate și guvernanță; observabilitate, teste și evaluări; interfață și aplicație; deployment și operațiuni. Acum folosim exact acea hartă pentru a descifra nume concrete.

Lecția pornește de la o problemă foarte practică. Produsele reale nu se încadrează întotdeauna în compartimentele clare ale unei diagrame didactice. Un produs poate acoperi trei sau patru responsabilități. Un nume poate desemna un ecosistem întreg, nu o singură bibliotecă. Două produse pot ocupa parțial același strat și totuși pot rezolva probleme diferite. Iar unele lucruri pe care le compară oamenii pe internet nici măcar nu aparțin aceleiași categorii.

Reper rapid: exact aceleași șase zone din Lecția 3

1. Zona I — fundația fizică: hardware: CPU, RAM, stocare, GPU, VRAM și rețea.
2. Zona II — de la hardware la software: sistem de operare, kernel, drivere și platformă de accelerare.
3. Zona III — software-ul care execută aplicația și calculele modelului: limbaj, runtime, dependențe, mediu virtual, framework-uri ML și biblioteci numerice.
4. Zona IV — model și inferență: artefactul modelului, cuantizare, runtime de inferență și server de model.
5. Zona V — deasupra modelului: controllerul agentului, orchestratorul și harness-ul, instrumentele, integrările, datele, starea, memoria și retrieval.
6. Zona VI — control și operare: securitate, identitate, guvernanță, observabilitate, teste, evaluări, interfață, aplicație, deployment și operațiuni.

Nu introducem o hartă nouă: aceasta este aceeași grupare din Lecția 3. Dacă uiți numărul unei zone, reconstruiește-l din responsabilitatea componentei: ce face această parte a sistemului?

De aceea nu vom întreba „care este mai bun: Ollama sau OpenShell?” înainte să observăm că întrebarea seamănă cu „care este mai bun: motorul sau centura de siguranță?”. Ollama și OpenShell pot exista în aceeași arhitectură tocmai pentru că au responsabilități diferite: unul se ocupă în principal de accesul la inferență, celălalt de izolarea și limitarea execuției agentului.

Regula lecției

Nu compara două nume până când nu le-ai identificat categoria și responsabilitatea. Mai întâi întrebi „ce este?”, apoi „ce face?”, apoi „unde se află în stack?”, abia după aceea „cu ce alternative îl compar?”.

La finalul lecției vei putea

1. să plasezi OpenClaw, Hermes Agent, NemoClaw, OpenShell, Ollama, Hugging Face, NVIDIA NeMo, NVIDIA NIM, LangGraph și MCP pe harta din Lecția 3;
2. să explici de ce aceste zece nume nu sunt zece alternative pentru aceeași problemă;
3. să recunoști diferența dintre aplicație de agent, framework de orchestrare, runtime de inferență sau server de model, platformă, protocol, sandbox și stack de referință;
4. să explici de ce Hugging Face și NeMo sunt nume-umbrelă care acoperă mai multe produse sau responsabilități;
5. să deosebești NeMo de NemoClaw și Hermes Agent de modelele Hermes;
6. să explici de ce MCP standardizează modul de conectare dintre componente, dar nu rulează el însuși agentul și nu îl face automat sigur;
7. să corectezi zece diagrame de arhitectură intenționat greșite;
8. să citești documentația unui produs nou și să îl plasezi în stack fără să te bazezi pe o listă învățată pe de rost.

1. De ce numele produselor ne păcălesc

Numele comerciale și numele proiectelor open-source sunt utile pentru a găsi software, dar nu sunt o clasificare tehnică.

Un nume de produs poate ascunde mai multe niveluri. „Hugging Face” poate însemna compania, Hub-ul, o bibliotecă Python, un serviciu de inferență sau întregul ecosistem. „NeMo” poate însemna o suită NVIDIA, NeMo Framework, NeMo Agent¹ Toolkit sau alte servicii din ecosistem. „Hermes” poate desemna o familie de modele, dar Hermes Agent este o aplicație și framework de agent. „NemoClaw” seamănă ca nume cu „NeMo”, dar nu este NeMo redenumit.

În același timp, un singur produs poate acoperi mai multe responsabilități. OpenClaw oferă gateway¹⁴ — poarta software prin care trec mesajele și conexiunile —, sesiuni, canale, instrumente⁴ și un harness de agent¹ — programul care ține bucla agentului în funcțiune; nu poate fi reprezentat corect într-o singură casetă dacă desenăm arhitectura realist. Hermes Agent combină bucla agentului cu memorie persistentă, skill-uri, instrumente și mai multe interfețe de interacțiune. Hugging Face combină depozite de modele și date cu biblioteci și servicii. NeMo este o suită modulară. A încerca să forțezi toate acestea într-un singur strat duce la o hartă înșelătoare.

Întrebarea care rămâne valabilă este din Lecția 3: ce responsabilitate este îndeplinită? Chiar dacă produsul își schimbă funcțiile în următoarea versiune, poți reface analiza.

2. Metoda decodorului: șapte întrebări înainte să compari produse

Metoda este mai importantă decât lista celor zece produse. O vei putea folosi și pentru nume care apar după publicarea cursului.

CategoriaEste model, runtime, server, aplicație, framework, protocol, platformă, sandbox sau stack de referință?

IntrareaCe primește: prompt, mesaje, fișiere, apeluri API, evenimente, artefacte de model?

IeșireaProduce tokeni, o decizie de workflow, un apel de instrument, un mediu izolat, date sau doar o conexiune?

ResponsabilitateaCe rând din harta celor 14 responsabilități îndeplinește?

DependențeleAre nevoie de un model separat, de hardware, de un server, de un agent sau de alte servicii?

AutoritateaPoate doar răspunde sau poate și citi, scrie, executa, trimite ori administra resurse?

Limita de securitateCine verifică identitatea (autentificare), cine dă voie (autorizare), cine ține acțiunea într-un spațiu limitat (izolare) și cine păstrează urma a ce s-a întâmplat (audit)?

Ordinea contează: identifică întâi categoria, rolul și limitele; comparația cu alternative vine după aceea.

După cele șapte întrebări poți adăuga una de actualitate: „Descriu versiunea de astăzi sau reputația istorică a produsului?” Este esențială pentru produse care evoluează rapid.

3. Aplică decodorul o dată, cap-coadă

Înainte să privim toate cele zece nume, aplicăm metoda completă unui singur produs. Alegem Ollama deoarece separarea dintre model, runtime și agent¹ a fost deja introdusă în Lecția 3.

Abia după acest traseu are sens să întrebăm dacă Ollama trebuie comparat cu NIM, cu un alt server de model¹⁶ sau cu un serviciu oferit în cloud de un furnizor. Nu îl comparăm direct cu OpenShell sau MCP, pentru că acestea rezolvă alte responsabilități.

4. Harta rapidă a celor zece nume

Tabelul de mai jos este punctul de orientare. Primele zece rânduri sunt numele analizate în lecție; secțiunile următoare justifică fiecare plasare și arată unde apar suprapunerile. Ultimele cinci rânduri sunt nume învecinate pe care le vei întâlni constant alături de ele: completează straturile de jos ale hărții și relațiile dintre agenți¹.

Cum citești tabelul: coloana „Zona principală” nu spune că produsul se reduce la acea zonă. Spune care este punctul cel mai potrivit de plecare pentru explicație. OpenClaw și Hermes ating mai multe responsabilități. Hugging Face și NeMo sunt intenționat marcate ca ecosisteme sau suite. MCP este o relație standardizată între componente și de aceea nu se comportă ca o „cutie” obișnuită din diagramă. Cele cinci nume învecinate arată că harta nu începe la agent¹: CUDA și PyTorch stau sub model, vLLM stă lângă Ollama și NIM, LangChain lângă LangGraph, iar A2A lângă MCP — de aceea sunt și cele mai frecvente surse de confuzie.

5. Aplicații de agent: OpenClaw și Hermes Agent

Ambele produse coordonează comportamentul agentului¹ și interacțiunea cu modele și instrumente⁴, dar modelul rămâne o componentă separată.

OpenClaw — aplicația și gateway-ul agentului, nu modelul

OpenClaw este util în această lecție tocmai pentru că îndeplinește mai multe responsabilități și poate fi confundat ușor cu modelul pe care îl folosește.

Documentația actuală descrie OpenClaw ca un asistent AI open-source și un gateway¹⁴ multi-canal care rulează pe dispozitivele sau serverele utilizatorului. Gateway-ul coordonează sesiunile, instrumentele⁴, evenimentele și conexiunile cu canale precum Telegram, Slack, Discord sau WhatsApp. Modelele și harness-urile pot fi schimbate, iar instrumentele, skill-urile și pluginurile extind capabilitățile.

În practică: îi poți scrie agentului¹ printr-un canal precum Telegram, iar OpenClaw poate coordona modelul și instrumentele⁴ configurate pentru a duce sarcina mai departe.

Din perspectiva Lecției 3, OpenClaw acoperă în primul rând rolul de controller¹² al agentului¹, instrumentele⁴ și integrările, starea⁵/sesiunile și interfața și canalele. Modelul rămâne o dependență separată. Poate fi găzduit sau local, în funcție de configurație.

Ultimul punct este important. Documentația OpenClaw avertizează că instrumentele⁴ sesiunii principale pot rula direct pe sistemul-gazdă (host) dacă sandboxing-ul nu este configurat. Asta înseamnă că „folosesc OpenClaw” nu răspunde de la sine la întrebarea „care este limita mea de securitate?”.

Hermes Agent — agent persistent, nu „modelul Hermes”

Cuvântul „Hermes” este ambiguu în ecosistemul Nous Research, de aceea numele complet contează.

Hermes Agent¹ este aplicația/framework-ul de agent. Documentația oficială actuală îl prezintă ca un agent open-source care poate folosi mai mulți furnizori de modele, instrumente⁴, memorie persistentă, skill-uri, sarcini programate și gateway-uri¹⁴ de mesagerie. Aceeași bază de agent poate fi folosită din CLI sau TUI, din aplicația desktop nativă, din panoul web (dashboard) și prin canalele de mesagerie configurate.

În practică: folosești Hermes Agent¹ când vrei un agent care păstrează memorie între sesiuni, poate folosi instrumente⁴ și poate fi accesat din mai multe interfețe.

Modelele Hermes sunt altceva: artefacte⁹ aparținând unor familii de modele (model families) pe care un runtime le poate executa. Poți folosi Hermes Agent¹ cu alte modele, iar un model Hermes poate fi folosit fără Hermes Agent. Relația este „agentul folosește un model”, nu „agentul este modelul”.

Pe harta stack-ului, Hermes Agent¹ intră în principal în Zona V: controller¹², harness, instrumente⁴, stare⁵ și memorie. Gateway¹⁴-urile de mesagerie ajung în zona interfeței. Dacă agentul rulează comenzi în sistem, întrebarea de securitate rămâne separată: cum primește acces la terminal, în ce mediu rulează comenzile, ce aprobări sunt active și cât de izolat este mediul?

6. Execuție controlată: NemoClaw și OpenShell

Aici separăm aplicația agentică de mediul în care rulează și care îi pune limite. Agentul¹ și sandbox-ul²⁰ pot fi schimbate independent.

NemoClaw — stack de referință pentru rularea controlată a agenților

NemoClaw este un exemplu bun de nume care descrie mai degrabă o compoziție de responsabilități decât o singură bibliotecă.

Documentația NVIDIA descrie NemoClaw ca un stack de referință²¹ open-source pentru rularea controlată a agenților¹ care rămân activi permanent (always-on) în containere OpenShell. NemoClaw adaugă configurarea inițială (onboarding), gestionarea ciclului de viață (lifecycle management), CLI, configurarea inferenței și politici de rețea peste sandbox-ul²⁰ furnizat de OpenShell. În documentația actuală, onboarding-ul suportă OpenClaw, Hermes și LangChain Deep Agents Code; OpenClaw rămâne agentul implicit pentru comanda nemoclaw onboard.

În practică: folosești NemoClaw când vrei să pornești și să operezi un agent¹ suportat într-un mediu OpenShell cu configurări și politici repetabile.

Asta înseamnă că NemoClaw nu înlocuiește agentul¹ și nu este același lucru cu OpenShell. O schemă utilă:

AGENT / HARNESS
      │
      ▼
NemoClaw — blueprint, ciclu de viață, configurare, inferență, politici
      │
      ▼
OpenShell — sandbox + gateway + izolare + aplicarea politicilor (policy enforcement)
      │
      ▼
container / mașină virtuală / infrastructură

NemoClaw ocupă în primul rând Zona VI: deployment, securitate operațională și alcătuirea unui mediu care poate fi refăcut identic. Dar configurează și modul în care agentul¹ ajunge la serviciul de inferență, de aceea atinge Zona IV. El nu transformă OpenClaw în model și nici OpenShell în orchestrator.

OpenShell — izolarea și aplicarea politicilor, nu controllerul agentului

OpenShell rezolvă o problemă diferită de cea rezolvată de un server de model¹⁶ sau de un framework de orchestrare¹⁸.

NVIDIA OpenShell este documentat ca un mediu de execuție pentru agenți¹, orientat spre izolare și aplicarea politicilor. Creează medii izolate și aplică politici declarative — reguli scrise în configurație, nu decise ad-hoc de agent — pentru acces la fișiere, rețea, date de autentificare precum chei și parole și infrastructură. Matricea de suport curentă include Docker, Podman, Kubernetes și microVM-uri ca medii în care OpenShell poate administra sandbox²⁰-uri. Kubernetes este documentat ca suportat prin chart-ul Helm; pentru producție trebuie totuși verificată matricea de suport a versiunii folosite, deoarece cerințele și interfețele pot evolua.

În practică: OpenShell este locul în care pui limite concrete: ce fișiere vede agentul¹, unde poate comunica în rețea și ce procese poate porni.

În harta Lecției 3, OpenShell aparține în primul rând responsabilității de securitate, izolare și deployment. Agentul¹ poate rula în interiorul sandbox²⁰-ului. Modelul poate fi accesat prin Inference Routing: în configurația administrată de OpenShell, codul din sandbox poate trimite cereri la https://inference.local, iar gateway-ul¹⁴ le rutează către furnizorul și modelul configurate fără să expună agentului cheia reală a furnizorului. Un endpoint este pur și simplu adresa la care un program trimite cereri. OpenShell nu decide obiectivul agentului și nu generează răspunsul modelului.

7. Inferență: Ollama și NVIDIA NIM

Aceste produse apar în partea stack-ului care rulează sau servește modele. Ele nu decid singure obiectivul agentului¹.

Ollama — rulare și servire de modele, nu agent

Ollama este unul dintre cele mai utile exemple pentru diferența dintre model, artefact⁹ și runtime sau server de inferență.

Ollama a devenit cunoscut ca o modalitate simplă de a descărca și rula modele deschise local, cu CLI și API⁷. În prezent, Ollama oferă atât modele locale, cât și modele găzduite în cloud. Pentru arhitectură, întrebarea corectă nu mai este „Ollama este local?”, ci „unde se execută modelul pe care l-am selectat prin Ollama?”.

În practică: Ollama este util când o aplicație are nevoie de o cale simplă și uniformă pentru a porni sau apela modele locale ori modele disponibile prin Ollama Cloud.

Când modelul rulează local, Ollama ocupă Zona IV: gestionează artefacte⁹ compatibile, pornește inferența și pune la dispoziție un API⁷. Când folosești un model cloud prin Ollama, modul de apelare poate rămâne asemănător, dar hardware-ul, artefactul și runtime-ul efectiv de inferență sunt operate la distanță.

Un agent¹ precum OpenClaw, Hermes Agent sau un workflow⁶ LangGraph poate folosi un endpoint Ollama. Asta nu face Ollama agent. Ollama execută sau servește inferența; controllerul¹² agentului decide când și de ce să o ceară.

NVIDIA NIM — microserviciu de inferență, nu modelul servit

NIM ne permite să separăm foarte clar „modelul” de „serviciul care îl face accesibil”.

NVIDIA NIM este o familie de microservicii¹⁷ de inferență containerizate, parte din NVIDIA AI Enterprise. Un microserviciu este un serviciu software separat, cu o interfață bine definită, care îndeplinește o responsabilitate precisă într-un sistem mai mare. Pentru LLM²/VLM, documentația actuală descrie NIM ca un strat de orchestrare¹⁸ pregătit pentru producție în jurul unui motor de inferență precum vLLM, menționat deja în Lecția 3 ca exemplu de runtime/server de model¹⁶, cu API-uri⁷ compatibile, verificări de stare⁵ și disponibilitate (health/readiness) și observabilitate. În funcție de ofertă, există containere legate de un model și containere model-free, adică imagini de container în care modelul este ales și încărcat la runtime. Din perspectiva acestei lecții, categoria rămâne aceeași: NIM este componenta de servire și inferență, nu modelul și nu controllerul¹² agentului¹.

În practică: NIM este folosit când vrei să oferi unui agent¹ sau unei aplicații un API⁷ stabil către inferență optimizată pe infrastructură NVIDIA.

APLICAȚIE / AGENT
       │ apel API
       ▼
     NIM
       │ încarcă / servește
       ▼
MODEL + MOTOR DE INFERENȚĂ
       │
       ▼
GPU / INFRASTRUCTURĂ

Dacă schimbi modelul dintr-un NIM, ai schimbat artefactul⁹ și, prin el, ce știe să facă modelul, nu categoria produsului NIM. Dacă schimbi NIM cu alt server de model¹⁶, ai schimbat componenta de servire. Această separare este exact cea introdusă în Lecția 3.

8. Ecosisteme și suite: Hugging Face și NVIDIA NeMo

Aceste nume acoperă mai multe produse sau servicii. Pentru o diagramă corectă trebuie numită componenta concretă.

Hugging Face — nume-umbrelă pentru mai multe componente

Dacă încerci să pui „Hugging Face” într-un singur strat, aproape sigur vei pierde informație.

Hugging Face Hub este o platformă pentru repository-uri — termen introdus în Lecția 1 — de modele, seturi de date și Spaces, adică aplicații și demonstrații găzduite pe Hub. În jurul lui există biblioteci precum transformers, datasets, huggingface_hub, peft și altele, plus servicii de inferență precum Inference Providers și Inference Endpoints. Aceste componente au responsabilități diferite.

În practică: poți lua un model de pe Hub, îl poți încărca printr-o bibliotecă Hugging Face sau poți folosi un serviciu de inferență Hugging Face; sunt trei roluri diferite.

Acesta este motivul pentru care o lecție dedicată Hub-ului va analiza platforma și depozitele în profunzime, iar o lecție separată va distinge seturile de date păstrate pe Hub de biblioteca Python datasets. În Lecția 4 nu trebuie încă să înveți API⁷-urile lor; trebuie să înveți să ceri numele complet al componentei.

NVIDIA NeMo — întreabă întotdeauna „care componentă NeMo?”

NeMo este un exemplu actual de suită care a crescut dincolo de categoria în care mulți cursanți au întâlnit-o prima dată.

Documentația NVIDIA actuală descrie NeMo ca o suită modulară de API-uri⁷ și biblioteci pentru ciclul de viață al agenților¹ AI — construire, deployment și optimizare — iar NeMo Framework rămâne componenta dedicată dezvoltării și antrenării modelelor generative. În aceeași suită găsești NeMo Agent Toolkit și NeMo Microservices, cu responsabilități diferite pentru evaluare, date, personalizarea modelelor, mecanisme de protecție (guardrailing) și operare.

În practică: când cineva spune „folosim NeMo”, cere numele componentei: una poate antrena modele, alta poate evalua și optimiza agenți¹, iar altele oferă servicii specializate.

Concluzia nu este că „NeMo face tot”. Concluzia este că NeMo este o familie sau suită, iar arhitectura trebuie să numească componenta concretă. Dacă într-o diagramă scrii doar „NeMo” între utilizator și bază de date, informația este insuficientă.

9. Orchestrare și integrare: LangGraph și MCP

LangGraph organizează traseul și starea⁵ unui workflow⁶; MCP standardizează comunicarea cu anumite funcții externe. Pot fi folosite împreună.

LangGraph — orchestrare și stare, nu inferență

LangGraph aparține aproape exact stratului pe care Lecția 3 l-a numit controller¹² sau orchestrator.

Documentația LangGraph îl descrie ca un framework și runtime de orchestrare¹⁸ de nivel scăzut pentru agenți¹ cu stare⁵, care pot rula pe perioade lungi. Oferă mecanisme pentru grafuri, execuție durabilă și reluabilă (durable execution), streaming, persistență și intervenție umană în flux (human-in-the-loop). Poate folosi modele și instrumente⁴ din alte ecosisteme; nu este el însuși furnizorul modelului.

În practică: LangGraph este util când trebuie să descrii explicit pașii unui agent¹, să păstrezi starea⁵ dintre pași și să poți relua execuția după o pauză sau o eroare.

În arhitectura noastră, LangGraph intră în Zona V — controllerul¹² agentului¹. Un nod poate apela un model prin Ollama, NIM sau un API⁷ extern. Alt nod poate apela un instrument⁴ prin MCP. Starea⁵ poate fi păstrată într-un mecanism persistent de stocare (backend). Permisiunile reale ale instrumentelor rămân însă responsabilitatea sistemului din jur.

MCP — protocol de conectare, nu „agent universal”

MCP este probabil numele cel mai ușor de desenat greșit, deoarece este un standard de comunicare, nu o aplicație unică.

Model Context Protocol¹⁹ definește o arhitectură gazdă–client–server (host–client–server) construită pe JSON-RPC, un format de mesaje de tip cerere–răspuns. În specificația curentă 2026-07-28, nucleul protocolului este stateless: fiecare cerere este autonomă și poartă versiunea protocolului și funcțiile relevante. Serverele MCP pot expune instrumente⁴ (tools), resurse (resources) și prompturi³ (prompts), iar o aplicație-gazdă (host) creează clienți MCP care comunică fiecare cu un server.

În practică: MCP îți permite să conectezi aceeași aplicație AI la servere diferite pentru fișiere, baze de date sau servicii, folosind un protocol¹⁹ comun în locul unei integrări complet diferite pentru fiecare.

Un server MCP nu este, el însuși, instrumentul⁴ pe care îl expune. Un server poate expune mai multe instrumente, iar o resursă și un prompt³ sunt primitive diferite de un instrument. MCP standardizează schimbul dintre componente, dar nu garantează că o operație este sigură: autorizarea, consimțământul, validarea parametrilor și izolarea rămân responsabilități ale aplicației-gazdă, serverului și infrastructurii.

HOST / APLICAȚIE DE AGENT
        │
        ├── MCP client ───── MCP server A ── tools
        │                              └──── resources
        │                              └──── prompts
        │
        └── MCP client ───── MCP server B ── tools / resources

În harta Lecției 3, MCP se află la granița dintre controllerul¹² agentului¹ și instrumente⁴ și date. Este o interfață standardizată între responsabilități, nu o înlocuire a lor. Controllerul decide dacă solicită un instrument. Serverul MCP expune instrumentul. Sistemul de autorizare decide dacă operația este permisă. Sandbox-ul²⁰ limitează unde se execută. Toate aceste roluri pot exista separat.

10. Cum compari corect: alternative, suprapuneri și componente complementare

Unele perechi sunt alternative parțiale, altele sunt complementare. Comparația are sens numai după ce ai stabilit responsabilitatea comună și constrângerile proiectului.

OpenClaw versus Hermes Agent

Acestea sunt comparabile ca tip de produs: ambele sunt aplicații agentice care includ un harness cu instrumente⁴, modele configurabile, persistență și mai multe interfețe de interacțiune. Diferențele de produs contează, dar comparația are sens pentru că aparțin unor categorii apropiate. Lecțiile dedicate OpenClaw și Hermes Agent¹ vor analiza aceste diferențe în profunzime.

NemoClaw versus OpenShell

Nu sunt alternative directe. OpenShell este stratul de bază care asigură izolarea și aplicarea politicilor. NemoClaw compune un stack de referință²¹ peste OpenShell și adaugă configurarea inițială (onboarding), gestionarea ciclului de viață și configurarea agentului¹ și a inferenței. Poți spune „NemoClaw folosește OpenShell”; nu este corect să spui „aleg între NemoClaw și OpenShell ca două sandbox²⁰-uri echivalente”.

Ollama versus NIM

Comparația poate avea sens doar pentru responsabilitatea de servire și inferență. Ollama pune accent pe ușurința de folosire pentru programatori și poate folosi modele locale sau găzduite în cloud, în timp ce NIM livrează microservicii¹⁷ containerizate și optimizate din ecosistemul NVIDIA. Nu deduce din această descriere care este mai bun pentru proiectul tău; trebuie să compari modelul, hardware-ul, licența, costul, latența și operațiunile.

LangGraph versus MCP

Nu sunt concurenți. LangGraph organizează starea⁵ și pașii unui flux de lucru⁶ agentic. MCP standardizează conexiunea dintre o aplicație și servere care expun instrumente⁴, resurse și prompturi³. Un nod LangGraph poate apela un instrument prin MCP.

NeMo versus NemoClaw

Asemănarea de nume este înșelătoare. NeMo este o suită NVIDIA mai largă pentru modele, agenți¹ și ciclul lor de viață. NemoClaw este un stack de referință²¹ orientat spre rularea controlată a agenților prin OpenShell. Într-o arhitectură poți întâlni componente NeMo și NemoClaw în același proiect fără ca ele să fie același lucru.

Hugging Face versus Ollama

„Hugging Face” este prea larg pentru o comparație directă. Poți compara un serviciu de inferență Hugging Face cu varianta prin Ollama, sau poți descărca de pe Hub un artefact⁹ compatibil cu un runtime local. Dar Hub-ul nu este „alternativa” Ollama în sens general: unul poate fi sursa artefactului, celălalt mecanismul de rulare.

Alege mai întâi responsabilitatea pe care o compari

Comparația are sens numai după ce ai stabilit responsabilitatea și constrângerile.

Chiar și după ce ai ales categoria corectă, comparația trebuie să folosească criterii relevante: compatibilitate, licență, confidențialitate, cost, latență, observabilitate, maturitate operațională, suprafață de atac și efort de mentenanță. „Are mai multe funcții” nu este criteriu suficient.

11. Securitate: un nume de produs nu este o limită de încredere

Într-un sistem agentic, întrebarea „ce poate face?” trebuie urmată imediat de „cine îi permite și unde este aplicată limita?”. Prin limită de încredere înțelegem locul în care sistemul verifică dacă o acțiune are voie să se întâmple și până unde poate ajunge.

Unele produse din această lecție oferă funcții de securitate, dar rolurile trebuie separate:

• OpenShell este conceput explicit pentru sandboxing și politici de execuție și rețea;
• NemoClaw compune politici și deployment peste OpenShell pentru un stack de referință²¹;
• OpenClaw are politici pentru instrumente⁴ și opțiuni de sandboxing, dar instrumentele pot rula direct pe sistemul-gazdă (host) în anumite configurații — nu presupune izolare doar din numele produsului;
• Hermes Agent¹ oferă aprobări și opțiuni de izolare și un backend pentru terminal, dar configurația efectivă decide autoritatea;
• MCP transportă funcții între client și server, dar nu transformă automat un instrument⁴ periculos într-un instrument sigur;
• Ollama sau NIM servesc modele; faptul că modelul este local sau containerizat nu definește singur permisiunile agentului¹;
• LangGraph poate implementa pași de aprobare și întreruperi, dar izolarea sistemului de operare rămâne altă responsabilitate;
• Hugging Face/NeMo includ mecanisme de acces, deployment sau mecanisme de protecție în anumite componente, dar trebuie numită componenta concretă și politica folosită.

12. Exemple complete: aceleași produse, roluri diferite

Nu memorăm combinații recomandate. Urmărim responsabilitățile ca să vedem de ce anumite componente pot apărea împreună.

Telegram
   │
   ▼
OpenClaw ── controller + sesiuni + instrumente
   │
   ├────────► Ollama ── model local
   │
   └────────► MCP client ──► server MCP calendar

Aplicație web
    │
    ▼
LangGraph ── stare + workflow + pas de aprobare
    │
    ├────────► NIM ── endpoint de inferență
    │
    └────────► MCP ── CRM / documente / instrumente

Utilizator
   │
   ▼
Hermes Agent
   │
   ▼
NemoClaw — onboarding + configurare + ciclu de viață
   │
   ▼
OpenShell sandbox
   │
   ├────────► inferență configurată
   └────────► rețea / fișiere conform politicii

Canal / operator
      │
      ▼
OpenClaw (agent)
      │
      ▼
NemoClaw (blueprint + ciclu de viață + configurare)
      │
      ▼
OpenShell (sandbox + politici + gateway)
      │
      ├────────► inferență configurată
      └────────► rețea permisă explicit

13. Cinci familii de confuzii pe care trebuie să le recunoști

În loc să memorăm zece corecții aproape identice, grupăm erorile după mecanismul care le produce. Aceste cinci familii vor reapărea în exercițiul cu diagrame.

Fiecare card pornește de la o propoziție pe care o spune des cineva care învață. Citește-o, încearcă să vezi singur problema, apoi citește explicația.

command -v ollama
( fără rezultat — cod de retur 1 )

./src/lesson02_invoice_agent.py --input data/inbox/invoice_complete.json --trace-file logs/lesson02/complete.jsonl | jq '{status, actions_taken}'
{
  "status": "waiting_for_review",
  "actions_taken": [
    "calculate_totals",
    "prepare_review_package",
    "wait_for_human_review"
  ]
}

lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Crystal Well Integrated Graphics Controller (rev 08)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X/M370X] (rev 83)

14. Găsește greșeala — zece diagrame intenționat greșite

Aceasta este proba practică principală a Lecției 4. Înainte să deschizi răspunsul, rescrie mental fiecare diagramă folosind responsabilitățile din Lecția 3.

Diagrama 1 — „Ollama trimite e-mailul”

Utilizator → Ollama → Gmail → e-mail trimis

Cheia instructorului — diagrama corectată

Diagrama susține că Ollama primește cererea utilizatorului și trimite singur e-mailul; în realitate Ollama este un runtime local care servește modele, iar decizia și trimiterea aparțin altor componente. Ollama este un runtime cu server care descarcă și execută modele pe calculatorul local (Lecția 3, secțiunea 6.4): primește o cerere de inferență și întoarce text generat. El nu știe care este sarcina, nu păstrează starea⁵ între pași și nu are drepturi pe contul tău de Gmail.

Categoriile confundate: runtime-ul este desenat ca actor care decide, deși aceea este responsabilitatea controllerului¹² — componenta care ține starea⁵ și alege pașii (Lecția 3, secțiunea 7.1) — iar instrumentul⁴ de e-mail este desenat ca etapă care „dorește” să trimită, deși el execută doar o acțiune autorizată de o politică. Diagrama corectată separă exact cele două: Utilizator → agent sau controller → Ollama (model) + instrument Gmail → aprobare și politică → trimitere.

Capcana: într-o diagramă cu trei casete, runtime-ul pare suficient pentru tot. Pentru constructorul de agenți¹, separarea arată unde se acordă permisiunile: dreptul de trimitere se acordă instrumentului, iar politica se aplică controllerului¹² — niciodată modelului.

Diagrama 2 — „Hugging Face este modelul”

Aplicație → Hugging Face → răspuns

Cheia instructorului — diagrama corectată

Diagrama susține că „Hugging Face” este componenta care produce răspunsul; numele acoperă de fapt trei componente diferite, cu roluri și permisiuni diferite. Hugging Face Hub este depozitul public de unde descarci artefacte⁹ de model; transformers este o bibliotecă Python care încarcă și execută modele; un serviciu de inferență este un API⁷ găzduit care rulează modelul la furnizor (Lecția 3, secțiunile 6.1, 6.4 și 6.5).

Categoriile confundate: depozitul este desenat ca productor de răspunsuri, deși el doar distribuie fișiere; biblioteca este omisă complet, deși ea este codul care rulează în aplicația ta. Diagrama corectată numește componenta exactă: descărcarea artefactului de pe Hub, execuția prin transformers în aplicație sau apelul către serviciul de inferență.

Capcana: numele comerciale care acoperă tot lanțul ascund unde se produc costurile și unde se pun cheile. Pentru constructorul de agenți¹, precizia contează practic: descărcarea de pe Hub nu cere cheie de serviciu, apelarea inferenței găzduite cere — două straturi, două politici diferite.

Diagrama 3 — „LangGraph este sandbox”

Agent → LangGraph security boundary → shell

Cheia instructorului — diagrama corectată

Diagrama susține că LangGraph este limita de securitate între agent¹ și shell; în realitate LangGraph este un framework de orchestrare¹⁸, iar izolarea execuției este responsabilitatea sandbox²⁰-ului. LangGraph organizează fluxul de lucru al unui agent ca graf de pași și tranziții (Lecția 3, secțiunea 7.1); sandbox-ul este mecanismul tehnic care limitează ce poate atinge un program — fișiere, rețea, dispozitive (Lecția 3, secțiunea 8.2).

Categoriile confundate: orchestrarea este desenată drept „security boundary”, deși un framework de grafuri nu oprește niciun apel de sistem; shell-ul este desenat ca destinație finală, deși el rulează sub politicile sandbox²⁰-ului. Diagrama corectată desparte rolurile: LangGraph/controller → instrument shell → sandbox/politici → sistem.

Capcana: să crezi că „framework-ul agentic are securitate inclusă”. Pentru constructorul de agenți¹, separarea contează la audit: întrebarea „ce oprește o comandă periculoasă?” trebuie să aibă răspuns într-un mecanism tehnic, nu în numele bibliotecii care ordonează pașii.

Diagrama 4 — „MCP este baza de date”

Agent → MCP database → clienți

Cheia instructorului — diagrama corectată

Diagrama susține că MCP este o bază de date; MCP este un protocol¹⁹, iar baza de date rămâne o componentă separată pe care un server MCP o expune. MCP (Model Context Protocol) este protocolul prin care aplicația agentului¹ — host-ul — accesează instrumente⁴ și resurse printr-un client MCP către servere MCP (Lecția 3, secțiunea 7.2). Un server MCP este un program care expune astfel de instrumente sau resurse.

Categoriile confundate: protocolul¹⁹ este desenat ca depozit de date, deși el definește doar cum circulă cererile; serverul MCP lipsește din diagramă, deși el este componenta care se conectează la baza de date. Diagrama corectată le pune pe toate: agent host → MCP client → MCP server → instrument sau resursă DB → bază de date.

Capcana: să crezi că „integrarea MCP” ține loc de permisiuni pe baza de date. Pentru constructorul de agenți¹, separarea arată unde se aplică controlul: drepturile de citire și scriere se acordă serverului MCP și instrumentului expus, nu protocolului¹⁹, care nu are cont propriu.

Diagrama 5 — „NeMo = NemoClaw”

NVIDIA NeMo / NemoClaw → același produs → model

Cheia instructorului — diagrama corectată

Diagrama susține că NeMo și NemoClaw sunt același produs; ele sunt două componente diferite, cu responsabilități diferite în același ecosistem. NeMo este suita NVIDIA pentru antrenare și construire — cu Framework, Agent¹ Toolkit și alte servicii; NemoClaw este un stack de referință²¹ pentru rularea agenților, construit peste OpenShell. Primul construiește și servește modele; al doilea asamblează un agent complet.

Categoriile confundate: suita este desenată ca punct final, deși ea produce componente; stack-ul de referință²¹ este redus la un nume de model, deși el însumează mai multe straturi. Diagrama corectată le desenează ca responsabilități diferite, nu ca două nume pentru același obiect.

Capcana: să compari modele sau runtime-uri „între NeMo și NemoClaw” — comparația are sens doar la nivelul componentei corecte. Pentru constructorul de agenți¹, distincția economisește decizii greșite: ce alegi din suită este o decizie, ce folosește stack-ul de referință²¹ este alta.

Diagrama 6 — „NIM = weights”

Fișier NIM → GPU → tokeni

Cheia instructorului — diagrama corectată

Diagrama susține că fișierul NIM conține GPU-ul¹¹ și produce tokeni direct; NIM este de fapt microserviciul¹⁷ de inferență care deservește un model, nu un format de ponderi. Ponderile (weights) sunt valorile numerice învățate, stocate în artefacte⁹ de model (Lecția 3, secțiunea 6.1); NIM este serviciul NVIDIA care împachetează un runtime și expune modelul prin API⁷ (Lecția 3, secțiunea 6.4).

Categoriile confundate: fișierul este desenat ca sursă de calcul, deși el este dată stocată; GPU-ul¹¹ este desenat ca consumator de fișier, deși el este pornit de un runtime; API-ul⁷ lipsește, deși el este interfața prin care aplicația primește tokeni. Diagrama corectată ordonează straturile: artefact sau model → motor sau runtime în NIM → API NIM → aplicație.

Capcana: să crezi că „descarci NIM-ul și modelul rulează singur”. Pentru constructorul de agenți¹, separarea arată unde se plătește și unde se limitează: inferența se servește prin API-ul⁷ NIM, iar autoritatea rămâne la aplicația care îl apelează.

Diagrama 7 — „OpenShell înlocuiește agentul”

Utilizator → OpenShell → decide ce instrument urmează

Cheia instructorului — diagrama corectată

Diagrama susține că OpenShell decide ce instrument⁴ urmează; OpenShell limitează execuția, iar decizia aparține agentului¹ sau controllerului¹². OpenShell este stratul care aplică politici și sandbox²⁰ asupra acțiunilor agentului — ce comenzi sunt permise, pe ce fișiere, în ce rețea. El nu are obiectiv și nu alege pași.

Categoriile confundate: stratul de politici este desenat ca creierul sistemului, deși el este mai degrabă un filtru; agentul¹ lipsește din diagramă, deși el păstrează starea⁵ și propune acțiunile. Diagrama corectată pune decizia la locul ei: utilizator → agent sau controller → acțiune → OpenShell politici și sandbox → sistem.

Capcana: să integrezi politicile în interiorul deciziei și să crezi că „dacă e permis, fac”. Pentru constructorul de agenți¹, separarea este exact modelul din Lecția 2: modelul propune, controllerul¹² decide, iar stratul de politici permite sau blochează execuția reală.

Diagrama 8 — „NemoClaw este doar alt nume pentru OpenShell”

NemoClaw = OpenShell

Cheia instructorului — diagrama corectată

Diagrama susține că NemoClaw și OpenShell sunt același produs cu nume diferite; relația corectă este de compoziție — NemoClaw folosește OpenShell ca strat de bază și adaugă propriile componente. Compoziția înseamnă că un produs include și configurează altul, fără ca cele două să devină identice: NemoClaw adaugă blueprint-uri, gestionarea ciclului de viață și configurarea peste ce oferă OpenShell.

Categoriile confundate: stratul de bază este desenat ca întregul produs, deși el este o parte; componentele adăugate lipsesc din diagramă, deși ele sunt diferența dintre cele două nume. Diagrama corectată arată relația: NemoClaw → configurează și folosește OpenShell → sandbox.

Capcana: să citești știri despre OpenShell și să le atribui automat lui NemoClaw, sau invers. Pentru constructorul de agenți¹, desenarea compoziției contează la actualizări: o schimbare în OpenShell ajunge la NemoClaw prin stratul de bază, iar ce este specific NemoClaw se modifică separat.

Diagrama 9 — „OpenClaw este furnizorul modelului”

OpenClaw model weights → inferență → tool

Cheia instructorului — diagrama corectată

Diagrama susține că OpenClaw produce ponderile modelului și le rulează; OpenClaw este aplicația și gateway-ul¹⁴ agentului¹, iar modelul cu furnizorul său se configurează separat. OpenClaw este programul agentului care primește sarcini și apelează instrumente⁴; ponderile — valorile învățate ale unui model — vin dintr-un artefact⁹ livrat de un furnizor ales de tine (Lecția 3, secțiunea 6.1).

Categoriile confundate: aplicația este desenată ca furnizor de model, deși furnizorul este o alegere de configurare; instrumentele⁴ sunt comprimate într-o singură etapă de inferență, deși ele se atașează separat de model. Diagrama corectată desparte traseele: OpenClaw agent → furnizor de model sau runtime și, separat, OpenClaw agent → instrumente.

Capcana: să crezi că schimbarea modelului înseamnă schimbarea aplicației. Pentru constructorul de agenți¹, separarea este chiar avantajul: poți înlocui furnizorul de model fără să atingi OpenClaw, iar instrumentele⁴ își păstrează permisiunile indiferent de modelul ales.

Diagrama 10 — „Hermes Agent = model Hermes”

Hermes Agent.gguf → Ollama → agent

Cheia instructorului — diagrama corectată

Diagrama susține că fișierul „Hermes Agent¹.gguf” este aplicația agent, rulată de Ollama; de fapt numele acoperă două obiecte diferite — aplicația Hermes Agent și un posibil model numit Hermes, ambalat ca artefact⁹. Extensia .gguf denumește un artefact de model — fișierul cu ponderi (Lecția 3, secțiunea 6.1) — nu un program agent.

Categoriile confundate: aplicația și artefactul⁹ poartă același nume comercial, deși pot exista independent; Ollama este desenat ca „creator” de agent¹, deși el doar servește modelul configurat. Diagrama corectată poate fi Hermes Agent → Ollama → model Hermes compatibil, dar Hermes Agent poate folosi și alte modele, iar un model Hermes poate fi folosit de alte aplicații.

Capcana: să deduci arhitectura din numele fișierelor. Pentru constructorul de agenți¹, regula practică este: aplicația, artefactul⁹ și runtime-ul sunt trei obiecte care se potrivesc între ele prin compatibilitate, nu prin nume — și fiecare se verifică separat.

15. Cinci domenii: aceeași hartă, combinații diferite

Un nume de produs nu are valoare în vid. Rolul lui devine clar abia când știm ce problemă rezolvă sistemul și ce responsabilități sunt necesare.

16. Exerciții practice

Exercițiile verifică dacă poți aplica metoda la arhitecturi noi, nu doar dacă ai memorat tabelul din secțiunea 4.

17. Quiz cu răspunsuri explicate

Răspunde înainte să deschizi explicația. Pentru fiecare întrebare încearcă să spui: categoria, responsabilitatea principală și confuzia pe care o evităm.

18. Recapitulare

Nu trebuie să memorezi zece definiții izolate. O parte din vocabular — runtime, framework, harness, server de model¹⁶, protocol¹⁹, sandbox²⁰ — a fost deja construit în Lecțiile 1–3. Aici îl aplici produselor reale și adaugi doar câțiva termeni noi, precum gateway¹⁴, microserviciu¹⁷ și stack de referință²¹. Trebuie să poți reconstrui diferența dintre categorii și să explici de ce unele produse se suprapun. Vocabularul aplicat se află acum în secțiunea „Vocabular esențial”, la finalul lecției.

Regula într-o frază: OpenClaw și Hermes controlează agentul¹; Ollama sau NIM servesc modele; LangGraph orchestrează starea⁵; MCP conectează componente și funcții; OpenShell izolează execuția; NemoClaw compune un stack de referință²¹ peste OpenShell; Hugging Face și NeMo sunt ecosisteme sau suite care trebuie desfăcute în componente concrete.

Vocabular esențial

Recitește definițiile după parcurgerea lecției — acum fiecare termen are context. Sunt grupate în două familii: termenii moșteniți din Lecțiile 1–3 și vocabularul aplicat produselor reale. Apasă pe numărul de lângă un termen ca să ajungi la explicația lui; butonul Înapoi al browserului te duce înapoi unde citeai.

Vocabular din Lecțiile 1–3

Vocabularul aplicat produselor

19. Referințe și documentație oficială

Produsele din această lecție se schimbă rapid. Descrierile au fost reverificate în documentația oficială disponibilă la 1 octombrie 2026. La instalare sau la luarea unei decizii de producție, verifică din nou versiunea curentă, notele de versiune (release notes) și matricea de compatibilitate.

• OpenClaw — documentație oficială și OpenClaw — sandboxing.
• Nous Research — Hermes Agent și Hermes Desktop.
• NVIDIA NemoClaw — Overview, CLI / agent selection și Platform Support / project status.
• NVIDIA OpenShell — Developer Guide, Supported Agents, Inference Routing, Support Matrix și Kubernetes setup.
• Ollama, Cloud models și ollama launch.
• Hugging Face Hub, Inference Providers și retrospectiva huggingface_hub v1.0.
• NVIDIA NeMo — suite overview, NeMo Framework și NeMo Agent Toolkit.
• NVIDIA NIM și NIM LLM/VLM — Architecture.
• LangGraph — overview și LangChain — overview.
• Nume învecinate: NVIDIA CUDA, PyTorch, vLLM și A2A Protocol.
• MCP — specificația 2026-07-28, MCP — Architecture, MCP — Security Best Practices, MCP joins the Agentic AI Foundation și anunțul inițial MCP.

20. Ce urmează

Lecțiile 1–4 te-au ajutat să te orientezi. Acum poți separa conceptele, poți explica bucla agentului¹, poți reconstrui stack-ul complet și poți plasa nume concrete fără să le tratezi ca pe ceva magic. Următoarea parte a cursului începe cu bazele software pe care agenții le pot afecta în mod real.

Lecția 5 — Fișiere, procese, utilizatori și permisiuni va coborî din nou spre sistemul de operare. Vom analiza ce este un proces, cine îl rulează, ce fișiere poate citi sau modifica și de ce autoritatea reală a unui agent¹ este limitată în cele din urmă de drepturile pe care sistemul de operare le acordă proceselor sale.