A sosit era agenților AI! De ce ar trebui să ne intereseze aceștia? Agentul este doar un buzzword nou sau chiar ceva care merită atenția noastră? Care este diferența între un LLM și un agent AI? Citind documentația oficială Strands, care descrie ce este un agent, găsim răspunsul chiar printre primele enunțuri: "un language model poate să răspundă la întrebări, un agent poate să execute fluxuri de lucru"[^1]. Vă invit să navigăm împreună în "mintea» agentului, să ne dăm seama despre cum poate un agent să facă anumite lucruri și să definim ceea ce înseamnă un agent și ceea ce poate să facă.
Baza agentului este un agent loop, care este alcătuit dintr-o regulă simplă în principiu: decide dacă este nevoie să folosim un tool sau nu; dacă este nevoie de un apel de tool, execută toolul și apelează modelul din nou cu rezultatul toolului. Asta se repetă până ce modelul produce răspunsul dorit.
Când interacționăm cu un LLM direct — fie că e un model de la Anthropic ( de exemplu, Claude Opus 4.6), OpenAI ( de exemplu, GPT‑5.2) sau orice alt furnizor — îi dăm un text, el ne returnează un text. Este ca un coleg foarte deștept, care știe enorm de multe lucruri, dar nu are acces la nimic: nici la internet, nici la baza de date, nici la sistemul de fișiere. Poate doar să gândească și să formuleze răspunsuri.
Un agent, pe de altă parte, este acel coleg deștept căruia i-ai dat și acces la tooluri. Poate să caute în baza de date, poate să trimită emailuri, poate să citească fișiere și să apeleze API-uri. Și — asta este partea interesantă — el singur decide când și ce unealtă să folosească. Nu trebuie să îi spunem explicit "acum caută în baza de date". El citește întrebarea noastră, se gândește și decide singur că are nevoie de o căutare în baza de date.
Documentația Strands Agents SDK, frameworkul open-source pe care îl vom folosi ca referință în acest articol, definește trei componente fundamentale:
Modelul — LLM-ul care gândește;
Tool-urile — funcțiile pe care agentul le poate apela;
Să intrăm mai adânc în modul cum funcționează bucla asta. Când un utilizator trimite un mesaj, se întâmplă următorul ciclu:
Mai întâi, agentul asamblează un prompt complet. Nu trimite doar mesajul utilizatorului către model. Adaugă și un sistem prompt (care definește personalitatea și regulile agentului), istoricul conversației, plus o descriere detaliată a fiecărui tool disponibil — cu nume, descriere și schema parametrilor.
Apoi, trimite totul la LLM. Modelul analizează și produce un răspuns. Aici vine momentul cheie: răspunsul poate fi text simplu (răspunsul final) sau o cerere de tool call — un bloc JSON prin care modelul spune "vreau să apelez toolul X cu parametri Y".
Dacă modelul cere un tool, bucla agentului validează cererea, execută funcția respectivă, capturează rezultatul și îl reinjectează în conversație. Modelul primește rezultatul și poate raționa mai departe: poate cere alt tool, poate corecta direcția sau poate produce răspunsul final.
Bucla se oprește în următoarele situații:
când modelul dă un răspuns fără să mai ceară niciun tool;
când se atinge o limită de iterații, când intervine un mecanism de siguranță (guardrail);
Diagrama ne arată structura recursivă care este alcătuită din trei părți: Reasoning (LLM-ul care gândește), Tool Selection (ce tool să fie selectat) și Tool Execution (execuția toolului) după care iarăși vine un call către LLM și, până la urmă, un răspuns final.
Dacă bucla este inima agentului, toolurile sunt mâinile. Un tool în Strands se definește simplu — decorezi o funcție Python cu \@tool, scrii un docstring clar, și gata:
@tool
def search_database(query: str,
max_results: int = 10) -> str:
"""Caută în baza de date a produselor.
Folosește-l când utilizatorul întreabă despre disponibilitate sau prețuri.
NU-l folosi pentru întrebări de cultură generală.
"""
# logica de business aiciCe este important de înțeles: descrierea toolului este cea mai importantă parte. Modelul nu citește codul funcției — citește descrierea. Pe baza ei decide când și cum să apeleze toolul. O descriere vagă sau ambiguă duce la decizii greșite. Practic, descrierea toolului este un contract între dezvoltator și model.
Strands suportă și tooluri asincrone pentru operații de lungă durată, tooluri care returnează rezultate progresiv (streaming), și validare de scheme prin Pydantic.
Până aici am vorbit despre tooluri locale — funcții Python definite în același proiect cu agentul. Dar ce facem când vrem să conectăm agentul la servicii externe? Baze de date, API-uri, platforme cloud?
Aici intră în scenă MCP — Model Context Protocol. Este un standard deschis care rezolvă o problemă practică: înainte de MCP, fiecare framework AI avea propriul mod de a conecta tooluri. Un tool scris pentru un framework nu funcționa cu altul. Fiecare integrare era un efort custom.
MCP standardizează conectivitatea toolurilor, asemănător cu un USB pentru hardware sau HTTP pentru web.
Arhitectura este simplă: client-server. Un server MCP expune tooluri — primește cereri și returnează rezultate. Un client MCP, integrat în agent, descoperă ce tooluri sunt disponibile și le apelează când este nevoie.
Când clientul se conectează la server, mai întâi întreabă: "Ce tooluri ai?" Serverul răspunde cu o listă de definiții — nume, descrieri, scheme de parametri. Agentul le integrează transparent alături de toolurile locale. Din perspectiva modelului, nu există nicio diferență între un tool local și unul de pe un server MCP la distanță.
Conectarea practică arată cam așa:
from mcp import StdioServerParameters, stdio_client
from strands import Agent
from strands.tools.mcp import MCPClient
mcp_client = MCPClient(lambda: stdio_client(
StdioServerParameters(command="uvx", args=["awslabs.aws-documentation-mcp-server@latest"])
))
agent = Agent(tools=[mcp_client])
agent("Ce este AWS Lambda?")Câteva linii de cod și agentul poate interoga toată documentația AWS.[^2] Fără niciun tool scris manual.
Un exemplu pentru folosirea unui tool MCP cu un agent Strands.
Un agent se poate conecta la mai multe servere MCP simultan — unul pentru baze de date, altul pentru e-mail, altul pentru calendar. Modelul vede o paletă unificată de tooluri și poate orchestra apeluri între toate într-o singură sesiune. Poate interoga baza de date, compune un e-mail cu rezultatele și programa o întâlnire de follow-up — totul autonom.
Transportul este abstractizat: stdio pentru tooluri locale (serverul rulează ca subproces, comunicarea e prin stdin/stdout) sau HTTP streamabil pentru servere remote în producție. Toolul funcționează la fel, indiferent de transport.
Ca să închidem cercul, merită menționat cât de simplu este să construiești un server MCP. Practic, decorezi funcții Python, scrii docstringul, implementezi logica de business, iar frameworkul se ocupă de restul: conformitatea cu protocolul JSON-RPC 2.0, descoperirea toolurilor, validarea inputului, serializarea rezultatelor. Dezvoltatorul scrie doar logica de business. Protocolul este invizibil.
Mintea unui agent AI nu este o cutie neagră. Este o buclă elegantă: gândește, acționează, observă, repetă. Modelul stă în centru ca motor de raționament, toolurile îi extind brațele în lumea reală, iar MCP oferă țesutul conectiv care leagă totul de un ecosistem de capabilități.
de Ovidiu Mățan
de Laura Dioşan , Andrei Olar , Mózes Császár
