Ce sunt AI Agents — De la Copilot la Sisteme Autonome în 2026

Un chatbot așteaptă să fie întrebat. Un agent nu așteaptă pe nimeni — își stabilește singur pașii, cheamă instrumentele de care are nevoie și continuă până își atinge obiectivul, chiar și după ce tu ai închis laptopul. Această diferență, aparent subtilă, este cea mai semnificativă schimbare de paradigmă din inteligența artificială aplicată de la apariția modelelor transformer în 2017: un agent AI nu mai este un asistent care răspunde, ci un sistem software care percepe mediul, planifică secvențe de acțiuni, utilizează instrumente externe și operează autonom până la atingerea unui obiectiv definit. Iar granița dintre „un apel deștept la un LLM" și „un agent adevărat" este exact locul unde majoritatea proiectelor fie generează valoare economică reală, fie ard bani fără rezultat.

De la Chatbot la Agent: O Taxonomie a Autonomiei

Pentru a înțelege ce sunt agenții AI, trebuie mai întâi să stabilim o taxonomie clară a nivelurilor de autonomie în sistemele bazate pe modele lingvistice mari (LLM). Această taxonomie nu este doar academică — ea dictează deciziile arhitecturale, costurile operaționale și profilul de risc al fiecărui sistem.

Nivelul 0 — LLM ca funcție pură (Stateless Completion). La acest nivel, un model precum Claude Opus 5 sau GPT-5.6 Sol primește un prompt și returnează un răspuns. Nu există memorie între apeluri, nu există instrumente, nu există planificare. Exemplu: un endpoint API care traduce text din engleză în română. Fiecare cerere este independentă. Costul este previzibil (tokens intrare + tokens ieșire), iar riscul este minim deoarece output-ul nu declanșează nicio acțiune în lumea reală.

Nivelul 1 — Copilot (Human-in-the-Loop permanent). GitHub Copilot, Cursor sau Claude Code în modul interactiv operează la acest nivel. Modelul sugerează, dar omul decide. Fiecare acțiune potențial distructivă (ștergerea unui fișier, executarea unei comenzi) necesită aprobare explicită. Sistemul poate avea acces la instrumente (terminal, file system), dar delegarea este granulară și supervizată.

Nivelul 2 — Agent semi-autonom (Human-on-the-Loop). Agentul execută secvențe de acțiuni fără aprobare individuală, dar operează sub constrângeri stricte: buget maxim de tokens, listă albă de instrumente permise, timeout-uri, și un mecanism de escaladare când incertitudinea depășește un prag. Omul monitorizează și intervine doar când agentul semnalează o situație excepțională. Majoritatea implementărilor enterprise din 2026 operează la acest nivel.

Nivelul 3 — Agent autonom cu self-governance. Agentul stabilește sub-obiective, alocă resurse, selectează strategii și se auto-corectează fără intervenție umană. Acest nivel este încă experimental în producție, cu excepția domeniilor cu risc scăzut (generare de conținut, analiză de date non-critice). Cercetările recente din 2026 de la Anthropic și Google DeepMind explorează mecanisme formale de verificare care ar permite autonomie completă în domenii critice.

Nivelul 4 — Sisteme multi-agent cu emergență coordinată. Multiple agenți autonomi colaborează, negociază și se coordonează pentru a rezolva probleme complexe. Fiecare agent are competențe specializate, iar comportamentul colectiv emergent depășește capacitățile individuale. Proiectele pilot din 2026 (de exemplu, sistemele de dezvoltare software fully-agentic de la Anthropic și OpenAI) demonstrează potențialul acestui nivel.

┌─────────────────────────────────────────────────────────┐
│  TAXONOMIA AUTONOMIEI ÎN SISTEME BAZATE PE LLM          │
├─────────────────────────────────────────────────────────┤
│  Nivel 0: LLM Stateless    │  prompt → completion       │
│  Nivel 1: Copilot          │  sugestie → aprobare umană │
│  Nivel 2: Agent Semi-Auto  │  obiectiv → execuție suprav│
│  Nivel 3: Agent Autonom    │  obiectiv → self-governance│
│  Nivel 4: Multi-Agent      │  misiune → coordonare      │
├─────────────────────────────────────────────────────────┤
│  Risc:    ▓░░░░  →  ▓▓▓▓▓                              │
│  Control: ▓▓▓▓▓  →  ▓░░░░                              │
│  Valoare: ▓░░░░  →  ▓▓▓▓▓                              │
└─────────────────────────────────────────────────────────┘

Definiția formală pe care o vom utiliza în acest curs: un agent AI este un sistem software care (1) primește un obiectiv de nivel înalt, (2) descompune obiectivul în sub-sarcini, (3) selectează și invocă instrumente pentru fiecare sub-sarcină, (4) evaluează rezultatele intermediare, (5) își adaptează planul în funcție de feedback, și (6) operează în cadrul unor constrângeri de siguranță predefinite.

The Agentic Stack: Cele 5 Componente Fundamentale

Orice agent AI, indiferent de complexitate, poate fi descompus în cinci componente arhitecturale. Acest model — pe care îl numim The Agentic Stack — oferă un cadru analitic pentru evaluarea, proiectarea și depanarea sistemelor agentic.

1. Brain (Creierul) — Modelul LLM

Creierul agentului este un model lingvistic mare care servește drept motor de raționament. În 2026, alegerea modelului este o decizie arhitecturală critică:

Update 24 iulie 2026 — Claude Opus 5 (top-ul familiei Opus). Anthropic a lansat Opus 5 (claude-opus-5) ca vârf al familiei Opus, cu același pricing ca generația anterioară 4.8 ($5/$25 per 1M tokens), context 1M, output 128K. Cel mai capabil model Anthropic per total rămâne Claude Fable 5 (GA 9 iunie 2026, $10/$50, tier peste Opus), iar Claude Sonnet 5 (30 iunie 2026, $2/$10 preț introductiv până la 31 august 2026) este noul default pentru sarcini uzuale. Generația 4.7 (16 aprilie 2026) introdusese un tokenizer nou care poate folosi mai mulți tokeni pentru același text (interval ~1,0–1,35× în funcție de conținut) — acea schimbare se păstrează în 4.8 și în Opus 5. Cele mai relevante aspecte pentru agent developers la Opus 5: (1) conform anunțului Anthropic, pe Frontier-Bench depășește de peste două ori performanța lui Opus 4.8, la un cost per task mai mic, iar pe CursorBench 3.2 la effort maxim ajunge la 0,5% de scorul de vârf al lui Fable 5, la jumătate din costul per task; (2) adaptive thinking este activ implicit — dacă omiți parametrul thinking, modelul gândește (spre deosebire de Opus 4.8/4.7, unde omiterea însemna fără thinking), deci recalibrează max_tokens; (3) dezactivarea thinking-ului (thinking: {"type": "disabled"}) este permisă doar la effort high sau mai mic — combinată cu xhigh/max întoarce 400; (4) tool use reliability sustenabilă pentru zeci de turnuri consecutive fără drift. Knowledge cutoff: mai 2026. Practic, agenții long-horizon devin viabili în producție începând cu generația 4.7/4.8, iar Opus 5 este alegerea recomandată azi pentru coding agentic complex.

Update 9 iulie 2026 — GPT-5.6 Sol. OpenAI a lansat GPT-5.6 Sol la $5/$30 per 1M tokens (Pro $30/$180), cu context de ordinul a 1M tokeni. Este omnimodal nativ end-to-end (text + voice + imagine + video procesate într-un singur prompt), cu rezultate puternice pe benchmark-urile agentic/terminal și o eficiență sporită de tokeni per task în Codex. Suportă computer use nativ, tool search integrat și Responses API. Pentru agenți, omnimodalitatea înseamnă că un singur apel poate primi screenshot + voice memo + text fără pre-procesare separată.

O practică frecventă în 2026 este tiered model selection: agentul folosește un model rapid și ieftin (Haiku 4.5) pentru decizii de rutină și escaladează la un model puternic (Opus 5 sau GPT-5.6 Sol) pentru raționament complex. Aceasta reduce costurile cu 60-80% fără compromiterea calității decizionale. Pattern-ul recomandat în 2026 pentru agenți: Sonnet 5 ca hot-path (tool calling rapid și ieftin — $2/$10 preț intro până la 31 aug 2026, apoi $3/$15), cu escaladare la Opus 5 pe edge cases și pe pași care necesită raționament long-horizon. Tokenizer-ul nou (introdus în 4.7 și păstrat în 4.8, ~1,0–1,35× mai mulți tokeni pentru același text, în funcție de conținut) face ca atenția la caching (TTL 5 min, 90% off) și context pruning să devină critice — un agent multi-turn fără caching consumă rapid bugetul.

# Exemplu: Tiered Model Selection cu fallback
import anthropic

client = anthropic.Anthropic()

def select_model(task_complexity: str) -> str:
    """Selectează modelul optim pe baza complexității sarcinii."""
    MODEL_TIERS = {
        "trivial": "claude-haiku-4-5",      # Clasificare, extracție simplă
        "standard": "claude-sonnet-4-6",     # Sinteză, analiză moderată
        "complex": "claude-opus-5",        # Raționament multi-hop, decizii critice
    }
    return MODEL_TIERS.get(task_complexity, "claude-sonnet-4-6")

def agent_call(prompt: str, complexity: str = "standard") -> str:
    model = select_model(complexity)
    response = client.messages.create(
        model=model,
        max_tokens=4096,
        messages=[{"role": "user", "content": prompt}]
    )
    return response.content[0].text

# Triaj automat al complexității
def classify_complexity(task_description: str) -> str:
    classification = agent_call(
        f"Clasifică complexitatea acestei sarcini ca 'trivial', "
        f"'standard' sau 'complex'. Răspunde cu un singur cuvânt.\n\n"
        f"Sarcină: {task_description}",
        complexity="trivial"  # Triajul în sine este trivial
    )
    return classification.strip().lower()

2. Tools (Instrumente) — Function Calling

Instrumentele transformă un LLM dintr-un „papagal stochastic" într-un agent capabil să interacționeze cu lumea reală. Un instrument este o funcție cu o schemă JSON precisă pe care agentul o poate invoca. Documentația oficială Anthropic (https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview) detaliază specificațiile complete ale protocolului de tool use.

Categoriile principale de instrumente:

• Instrumente de citire: interogări baze de date, căutare web, acces API-uri externe, citire fișiere
• Instrumente de scriere: creare/modificare fișiere, trimitere email-uri, actualizare baze de date
• Instrumente de calcul: execuție cod (sandboxed), operații matematice, simulări
• Instrumente de comunicare: notificări, escaladare către oameni, raportare

# Definirea unui instrument cu JSON Schema
tools = [
    {
        "name": "query_database",
        "description": (
            "Execută o interogare SQL read-only asupra bazei de date "
            "de producție. Returnează maximum 100 de rânduri. "
            "NU suportă instrucțiuni DDL sau DML (INSERT/UPDATE/DELETE)."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {
                    "type": "string",
                    "description": "Interogare SQL SELECT validă"
                },
                "database": {
                    "type": "string",
                    "enum": ["analytics", "users", "orders"],
                    "description": "Baza de date țintă"
                }
            },
            "required": ["query", "database"]
        }
    },
    {
        "name": "send_notification",
        "description": (
            "Trimite o notificare prin Slack către un canal specificat. "
            "Folosește doar pentru alerte critice sau rapoarte solicitate."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "channel": {
                    "type": "string",
                    "description": "Numele canalului Slack (ex: #incidents)"
                },
                "message": {
                    "type": "string",
                    "description": "Conținutul notificării (max 2000 caractere)"
                },
                "severity": {
                    "type": "string",
                    "enum": ["info", "warning", "critical"],
                    "description": "Nivelul de severitate"
                }
            },
            "required": ["channel", "message", "severity"]
        }
    }
]

3. Memory (Memoria) — Contextul Persistent

Memoria unui agent operează pe trei niveluri distincte:

Memoria de lucru (Working Memory) — fereastra de context a conversației curente. Limitată de context window-ul modelului (1M tokens pentru Claude Opus 5 și GPT-5.6 Sol, 2M pentru Gemini 3.1 Pro). Conține istoricul conversației, rezultatele instrumentelor și raționamentul curent. Cu Opus 5, 1M context devine practic o memorie extinsă cross-session pentru agenți — poți păstra în prompt zile întregi de istoric de tool use, validat de îmbunătățirea reliability long-horizon. Atenție: context window mare nu înseamnă că trebuie umplut tot — Lost-in-the-Middle rămâne o realitate (degradare notabilă a regăsirii pentru informațiile din mijlocul contextului).

Memoria episodică (Short-term Persistent) — informații despre sesiuni recente, stocate într-o bază de date vectorială sau key-value store. Permite agentului să „își amintească" interacțiuni anterioare cu același utilizator sau despre același proiect.

Memoria semantică (Long-term Knowledge) — baza de cunoștințe a agentului, implementată prin RAG (Retrieval-Augmented Generation). Include documentație internă, proceduri operaționale, baze de cunoștințe specifice domeniului.

# Arhitectură de memorie pe trei niveluri
from dataclasses import dataclass, field
from datetime import datetime
from typing import Any

@dataclass
class AgentMemory:
    """Sistem de memorie pe trei niveluri pentru un agent AI."""

    # Nivel 1: Memoria de lucru (în context window)
    working_context: list[dict] = field(default_factory=list)
    max_working_tokens: int = 100_000

    # Nivel 2: Memoria episodică (bază de date vectorială)
    episode_store: Any = None  # ChromaDB, Pinecone, etc.

    # Nivel 3: Memoria semantică (RAG)
    knowledge_base: Any = None  # Index vectorial persistent

    def add_to_working_memory(self, role: str, content: str) -> None:
        """Adaugă un mesaj în memoria de lucru cu gestionarea overflow-ului."""
        self.working_context.append({
            "role": role,
            "content": content,
            "timestamp": datetime.now().isoformat()
        })
        self._compact_if_needed()

    def _compact_if_needed(self) -> None:
        """Compactează memoria de lucru când se apropie de limită."""
        # Estimare simplificată: ~4 caractere per token
        total_chars = sum(len(m["content"]) for m in self.working_context)
        estimated_tokens = total_chars // 4

        if estimated_tokens > self.max_working_tokens * 0.8:
            # Strategia: sumarizează mesajele vechi, păstrează cele recente
            old_messages = self.working_context[:-10]
            recent_messages = self.working_context[-10:]

            summary = self._summarize(old_messages)
            self.working_context = [
                {"role": "system", "content": f"Rezumat conversație anterioară: {summary}"}
            ] + recent_messages

    def recall_episodes(self, query: str, k: int = 5) -> list[dict]:
        """Recuperează episoade relevante din memoria episodică."""
        if self.episode_store is None:
            return []
        results = self.episode_store.query(query_texts=[query], n_results=k)
        return results

    def search_knowledge(self, query: str, k: int = 10) -> list[str]:
        """Caută în baza de cunoștințe semantice."""
        if self.knowledge_base is None:
            return []
        return self.knowledge_base.similarity_search(query, k=k)

    def _summarize(self, messages: list[dict]) -> str:
        """Placeholder pentru sumarizare — în producție folosește LLM."""
        return f"[Sumarizare a {len(messages)} mesaje anterioare]"

4. Planning (Planificarea) — Descompunerea Obiectivelor

Planificarea este capacitatea agentului de a descompune un obiectiv complex în sub-sarcini executabile și de a stabili ordinea optimă de execuție. Vom explora în detaliu pattern-urile de planificare (ReAct, Plan-and-Execute, Reflexion) în lecția următoare. Aici prezentăm conceptual rolul planificării:

Obiectiv: "Generează raportul lunar de vânzări pentru martie 2026"
    │
    ├── Sub-sarcină 1: Extrage datele din baza de date (tool: query_database)
    │       └── Query: SELECT ... FROM orders WHERE month = '2026-03'
    │
    ├── Sub-sarcină 2: Calculează metrici agregate (tool: code_interpreter)
    │       └── Script Python: calcul revenue, growth, top products
    │
    ├── Sub-sarcină 3: Generează vizualizări (tool: code_interpreter)
    │       └── matplotlib charts: revenue trend, category breakdown
    │
    ├── Sub-sarcină 4: Compune narativul raportului (LLM reasoning)
    │       └── Analiză text cu insights și recomandări
    │
    └── Sub-sarcină 5: Formatează și distribuie (tools: file_write, send_email)
            └── PDF + email către stakeholders

5. Guardrails (Bariere de Siguranță) — Constrângeri și Control

Guardrails-urile sunt mecanismele care previn comportamentul nedorit al agentului. Într-un sistem de producție, acestea nu sunt opționale — sunt critice. Fără ele, un agent autonom poate genera costuri necontrolate, poate corupe date sau poate lua decizii cu consecințe ireversibile.

Categorii de guardrails:

• Budget enforcement: limită maximă de tokens/apeluri API per sesiune
• Tool access control: listă albă/neagră de instrumente permise per context
• Output validation: verificarea output-ului înainte de execuție (ex: SQL injection prevention)
• Circuit breakers: oprirea automată la detectarea anomaliilor (ex: prea multe erori consecutive)
• Human escalation triggers: condiții care forțează intervenția umană
• Rate limiting: limitarea frecvenței acțiunilor pentru prevenirea loop-urilor infinite

# Implementare guardrails cu buget și circuit breaker
from dataclasses import dataclass
from enum import Enum

class AgentState(Enum):
    RUNNING = "running"
    PAUSED = "paused"
    ESCALATED = "escalated"
    TERMINATED = "terminated"

@dataclass
class GuardrailConfig:
    max_iterations: int = 50
    max_tokens_budget: int = 500_000
    max_tool_calls: int = 100
    max_consecutive_errors: int = 3
    allowed_tools: list[str] | None = None
    require_human_approval: list[str] | None = None  # tools needing approval

class AgentGuardrails:
    def __init__(self, config: GuardrailConfig):
        self.config = config
        self.iterations = 0
        self.tokens_used = 0
        self.tool_calls = 0
        self.consecutive_errors = 0
        self.state = AgentState.RUNNING

    def check_before_iteration(self) -> AgentState:
        """Verifică toate condițiile înainte de fiecare iterație."""
        if self.iterations >= self.config.max_iterations:
            self.state = AgentState.TERMINATED
            return self._terminate("Limita de iterații atinsă "
                                   f"({self.config.max_iterations})")

        if self.tokens_used >= self.config.max_tokens_budget:
            self.state = AgentState.TERMINATED
            return self._terminate("Bugetul de tokens epuizat "
                                   f"({self.config.max_tokens_budget})")

        if self.consecutive_errors >= self.config.max_consecutive_errors:
            self.state = AgentState.ESCALATED
            return self._escalate("Prea multe erori consecutive "
                                  f"({self.consecutive_errors})")

        self.iterations += 1
        return AgentState.RUNNING

    def check_tool_call(self, tool_name: str) -> bool:
        """Verifică dacă apelul instrumentului este permis."""
        if self.config.allowed_tools is not None:
            if tool_name not in self.config.allowed_tools:
                raise PermissionError(
                    f"Instrumentul '{tool_name}' nu este în lista permisă"
                )

        self.tool_calls += 1
        if self.tool_calls > self.config.max_tool_calls:
            self.state = AgentState.TERMINATED
            raise ResourceWarning("Limita de apeluri instrumente atinsă")

        if (self.config.require_human_approval and
                tool_name in self.config.require_human_approval):
            self.state = AgentState.PAUSED
            return False  # Necesită aprobare umană

        return True

    def report_success(self) -> None:
        self.consecutive_errors = 0

    def report_error(self) -> None:
        self.consecutive_errors += 1

    def record_tokens(self, count: int) -> None:
        self.tokens_used += count

    def _terminate(self, reason: str) -> AgentState:
        print(f"[GUARDRAIL] Agent terminat: {reason}")
        return AgentState.TERMINATED

    def _escalate(self, reason: str) -> AgentState:
        print(f"[GUARDRAIL] Escaladare către om: {reason}")
        return AgentState.ESCALATED

Comparație cu Automatizarea Tradițională

Este esențial să înțelegem diferența fundamentală dintre un agent AI și un sistem tradițional de automatizare (workflow engine, RPA, cron jobs). Această distincție este frecvent confuzată în industrie, ceea ce duce la implementări suboptimale.

Regula de aur: Folosește automatizare tradițională pentru fluxuri bine definite, repetitive și stabile. Folosește agenți AI pentru sarcini care necesită raționament, adaptare la contexte variate sau unde spațiul de excepții este prea mare pentru a fi codificat exhaustiv.

Scenariu Aplicat: Rezolvarea Autonomă a Incidentelor DevOps

Să examinăm un scenariu concret în care un agent AI generează valoare substanțială: rezolvarea autonomă a incidentelor de infrastructură. Acest exemplu este reprezentativ pentru implementările enterprise din 2026.

Context: O companie SaaS cu 50 de microservicii pe Kubernetes primește o alertă PagerDuty la 3:00 AM — latența serviciului de plăți a crescut de la 200ms la 4500ms.

Fără agent: Un inginer on-call se trezește, se autentifică, verifică dashboards, citește loguri, formulează ipoteze, testează, aplică fix-ul, verifică. Timp mediu: 45-90 minute.

Cu agent AI (Nivel 2 — semi-autonom):

# Pseudocod: Agent DevOps pentru rezolvarea incidentelor
import anthropic
from datetime import datetime

client = anthropic.Anthropic()

SYSTEM_PROMPT = """Ești un agent DevOps specializat în rezolvarea incidentelor.
Ai acces la următoarele instrumente:
- query_metrics: Interogare Prometheus/Grafana
- query_logs: Căutare în Elasticsearch/Loki
- kubectl_read: Comenzi kubectl read-only (get, describe, logs)
- kubectl_write: Comenzi kubectl de modificare (scale, rollout, restart)
- create_ticket: Creare ticket Jira
- notify_slack: Notificare Slack
- run_playbook: Execuție runbook predefinit

CONSTRÂNGERI CRITICE:
1. kubectl_write necesită aprobare umană pentru orice operațiune pe namespace-ul 'production'
2. Maximum 20 de apeluri API per incident
3. Dacă nu poți diagnostica în 10 minute, escaladează
4. Documentează FIECARE acțiune în timeline-ul incidentului
5. NU modifica niciodată configurația bazei de date direct
"""

INCIDENT_TOOLS = [
    {
        "name": "query_metrics",
        "description": "Interogare metrici din Prometheus. Returnează serii temporale.",
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {"type": "string", "description": "PromQL query"},
                "duration": {"type": "string", "description": "ex: '1h', '30m'"}
            },
            "required": ["query", "duration"]
        }
    },
    {
        "name": "query_logs",
        "description": "Căutare în loguri. Returnează ultimele N intrări relevante.",
        "input_schema": {
            "type": "object",
            "properties": {
                "service": {"type": "string"},
                "query": {"type": "string"},
                "severity": {"type": "string", "enum": ["info", "warn", "error"]},
                "limit": {"type": "integer", "default": 50}
            },
            "required": ["service", "query"]
        }
    },
    {
        "name": "kubectl_read",
        "description": "Execută comenzi kubectl read-only.",
        "input_schema": {
            "type": "object",
            "properties": {
                "command": {"type": "string", "description": "ex: 'get pods -n payments'"},
                "namespace": {"type": "string"}
            },
            "required": ["command"]
        }
    }
    # ... alte instrumente
]

def handle_incident(alert: dict) -> dict:
    """Punct de intrare pentru rezolvarea autonomă a unui incident."""

    guardrails = AgentGuardrails(GuardrailConfig(
        max_iterations=30,
        max_tokens_budget=200_000,
        max_tool_calls=20,
        max_consecutive_errors=3,
        require_human_approval=["kubectl_write"]
    ))

    messages = [
        {"role": "user", "content": (
            f"INCIDENT ALERT:\n"
            f"Serviciu: {alert['service']}\n"
            f"Severitate: {alert['severity']}\n"
            f"Descriere: {alert['description']}\n"
            f"Timestamp: {alert['timestamp']}\n\n"
            f"Diagnostichează și rezolvă acest incident. "
            f"Începe cu investigarea metricilor și logurilor."
        )}
    ]

    timeline = []

    while guardrails.check_before_iteration() == AgentState.RUNNING:
        response = client.messages.create(
            model="claude-sonnet-4-6",  # Sonnet pentru viteză
            max_tokens=4096,
            system=SYSTEM_PROMPT,
            tools=INCIDENT_TOOLS,
            messages=messages
        )

        guardrails.record_tokens(response.usage.input_tokens
                                 + response.usage.output_tokens)

        if response.stop_reason == "tool_use":
            for block in response.content:
                if block.type == "tool_use":
                    tool_name = block.name
                    tool_input = block.input

                    # Verificare guardrails
                    if not guardrails.check_tool_call(tool_name):
                        # Necesită aprobare umană
                        timeline.append({
                            "time": datetime.now().isoformat(),
                            "action": f"AWAITING APPROVAL: {tool_name}",
                            "input": tool_input
                        })
                        # În producție: trimite notificare și așteaptă
                        break

                    # Execuție instrument
                    result = execute_tool(tool_name, tool_input)
                    timeline.append({
                        "time": datetime.now().isoformat(),
                        "action": tool_name,
                        "input": tool_input,
                        "result_summary": str(result)[:200]
                    })

                    messages.append({"role": "assistant", "content": response.content})
                    messages.append({
                        "role": "user",
                        "content": [{"type": "tool_result",
                                     "tool_use_id": block.id,
                                     "content": str(result)}]
                    })

        elif response.stop_reason == "end_turn":
            # Agentul a terminat — extrage concluziile
            final_response = response.content[0].text
            timeline.append({
                "time": datetime.now().isoformat(),
                "action": "RESOLUTION",
                "summary": final_response[:500]
            })
            break

    return {"timeline": timeline, "tokens_used": guardrails.tokens_used}

Rezultatul tipic: Agentul identifică în 3-5 minute că un deployment recent a introdus un query SQL neoptimizat care generează full table scans, scalează temporar replica-ul bazei de date, face rollback la deployment-ul anterior și creează un ticket Jira cu analiza completă a cauzei. Inginerul on-call primește pe Slack o notificare cu rezumatul acțiunilor, verifică și confirmă. Timpul total: 5-8 minute vs. 45-90 minute manual.

Capcane Frecvente: Anti-pattern-uri în Dezvoltarea de Agenți

Experiența acumulată în 2024-2026 în implementări enterprise a cristalizat un set de anti-pattern-uri pe care orice practician trebuie să le cunoască:

1. Over-agentification (Agentificarea excesivă)

Simptom: Fiecare funcționalitate devine „un agent". Formularul de contact este „un agent de comunicare", login-ul este „un agent de autentificare".

Problemă: Nu orice sarcină necesită raționament LLM. Dacă un flux poate fi complet specificat prin reguli deterministe, un agent adaugă latență, cost și impredictibilitate fără valoare adăugată.

Regulă: Dacă poți scrie un flowchart complet al logicii de decizie fără ramificații condiționate de conținut natural-language, probabil nu ai nevoie de un agent.

2. Lipsa Circuit Breaker-elor

Simptom: Agentul intră într-un loop infinit de reîncercări sau generează costuri necontrolate.

Problemă: LLM-urile pot „halucina" o strategie care eșuează repetat, dar modelul insistă cu variații minime ale aceleiași abordări.

Soluție: Implementează obligatoriu: limită de iterații, buget de tokens, timeout global, și detecție de loop (dacă ultimele N acțiuni sunt similare, oprește).

3. Zero Human-in-the-Loop pentru Acțiuni Ireversibile

Simptom: Agentul șterge resurse, trimite emailuri clienților sau modifică date de producție fără nicio aprobare umană.

Problemă: Chiar și cele mai bune modele din 2026 au o rată de eroare non-zero. Pentru acțiuni ireversibile, consecințele unei erori pot fi catastrofale.

Soluție: Clasifică instrumentele în tiers de risc. Tier 1 (citire) = execuție liberă. Tier 2 (scriere reversibilă) = log + notificare. Tier 3 (acțiuni ireversibile) = aprobare umană obligatorie.

4. Ignorarea Observabilității

Simptom: Agentul „a făcut ceva" dar nimeni nu știe exact ce, în ce ordine, cu ce parametri.

Problemă: Fără trace-uri detaliate, debugging-ul unui agent este aproape imposibil. Comportamentul non-determinist al LLM-urilor face debugging-ul și mai dificil decât în sisteme tradiționale.

Soluție: Loghează complet fiecare iterație: prompt trimis, răspuns primit, tool calls cu parametri și rezultate, tokens consumați, timp per operațiune. Instrumente recomandate: LangSmith, Braintrust, Arize Phoenix, sau soluții custom cu OpenTelemetry.

5. Prompt-uri Insuficient de Specifice

Simptom: Agentul interpretează obiectivele în moduri surprinzătoare, folosește instrumente neașteptate sau ignoră constrângeri implicite.

Problemă: Un system prompt vag lasă loc de interpretare. LLM-urile optimizează pentru „helpfulness", ceea ce poate însemna acțiuni pe care nu le anticipai.

Soluție: System prompt-ul unui agent trebuie să fie un document de specificații precise: ce poate face, ce NU poate face, în ce ordine să procedeze, când să escaladeze, ce ton să adopte, ce formate să folosească.

Ghiduri Oficiale: Perspective de la Anthropic și OpenAI

Două resurse esențiale pentru oricine construiește agenți AI:

Anthropic — „Building Effective Agents" (https://docs.anthropic.com/en/docs/build-with-claude/agentic-systems): Acest ghid subliniază principiul „keep it simple" — în multe cazuri, o implementare bazată pe un singur loop LLM cu instrumente este suficientă și preferabilă unui framework complex. Anthropic recomandă augmented LLM ca punct de plecare, nu sisteme multi-agent. De asemenea, documentația oficială de tool use (https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview) oferă specificații complete pentru implementarea function calling cu modelele Claude.

OpenAI — Agents Documentation (https://platform.openai.com/docs/guides/agents): OpenAI oferă un ghid cuprinzător pentru construirea agenților cu GPT-5.6 Sol, inclusiv best practices pentru tool calling, function definitions și structured outputs. OpenAI pune accent pe „function calling reliability" și pe validarea strictă a output-urilor prin JSON Schema.

Principii comune din ambele ghiduri:

1. Începe simplu: Un loop cu un LLM și câteva instrumente bine definite rezolvă 80% din cazuri.
2. Iterează pe baza eșecurilor reale: Nu arhitectura „la perfecție" înainte de a avea date despre modurile de eșec.
3. Prioritizează observabilitatea: Fiecare decizie a agentului trebuie să fie auditabilă.
4. Testează cu adversarii: Simulează input-uri malițioase, cazuri limită, timeout-uri.
5. Implementează graceful degradation: Când agentul nu poate rezolva, escaladarea trebuie să fie lină și informativă.

Pseudocod Complet: Arhitectura unui Agent cu Budget Enforcement

Să integrăm toate componentele într-o arhitectură completă de agent. Acest exemplu demonstrează cum funcționează cele 5 componente ale Agentic Stack-ului împreună:

# Arhitectură completă a unui agent AI cu toate cele 5 componente
import anthropic
import json
import time
from dataclasses import dataclass, field
from typing import Callable

@dataclass
class AgentConfig:
    """Configurația completă a agentului."""
    name: str
    system_prompt: str
    model: str = "claude-sonnet-4-6"
    escalation_model: str = "claude-opus-5"
    max_iterations: int = 50
    max_tokens_budget: int = 300_000
    max_tool_calls: int = 50
    tools: list[dict] = field(default_factory=list)
    tool_handlers: dict[str, Callable] = field(default_factory=dict)
    escalation_threshold: float = 0.7  # Complexitate peste care escaladează modelul

class AutonomousAgent:
    """
    Agent AI autonom cu cele 5 componente ale Agentic Stack:
    1. Brain (LLM cu tiered selection)
    2. Tools (Function calling cu validare)
    3. Memory (Context management cu sumarizare)
    4. Planning (ReAct loop implicit)
    5. Guardrails (Budget, circuit breaker, escalation)
    """

    def __init__(self, config: AgentConfig):
        self.config = config
        self.client = anthropic.Anthropic()
        self.messages: list[dict] = []
        self.tokens_used = 0
        self.tool_calls_count = 0
        self.consecutive_errors = 0
        self.iteration = 0
        self.trace: list[dict] = []

    def run(self, objective: str) -> dict:
        """Execută agentul cu un obiectiv dat."""
        self.messages = [{"role": "user", "content": objective}]
        self._log("START", {"objective": objective})

        while True:
            # GUARDRAIL: Verificare buget
            if self.iteration >= self.config.max_iterations:
                return self._finalize("Limita de iterații atinsă")
            if self.tokens_used >= self.config.max_tokens_budget:
                return self._finalize("Bugetul de tokens epuizat")
            if self.consecutive_errors >= 3:
                return self._finalize("Prea multe erori consecutive — escaladare")

            self.iteration += 1

            # BRAIN: Selectare model (tiered)
            model = self._select_model()

            try:
                # Apel LLM
                response = self.client.messages.create(
                    model=model,
                    max_tokens=4096,
                    system=self.config.system_prompt,
                    tools=self.config.tools,
                    messages=self.messages
                )
                self.tokens_used += (response.usage.input_tokens
                                     + response.usage.output_tokens)
                self.consecutive_errors = 0

            except Exception as e:
                self.consecutive_errors += 1
                self._log("ERROR", {"error": str(e)})
                continue

            # PLANNING: Procesare răspuns (ReAct loop implicit)
            if response.stop_reason == "tool_use":
                self._handle_tool_calls(response)
            elif response.stop_reason == "end_turn":
                final_text = ""
                for block in response.content:
                    if hasattr(block, "text"):
                        final_text += block.text
                self._log("COMPLETE", {"response": final_text[:500]})
                return self._finalize("Completat cu succes", final_text)
            else:
                self._log("UNEXPECTED_STOP", {"reason": response.stop_reason})
                return self._finalize(f"Stop reason neașteptat: {response.stop_reason}")

        return self._finalize("Loop terminat")

    def _select_model(self) -> str:
        """BRAIN: Selectează modelul bazat pe complexitatea iterației."""
        if self.iteration > 10 and self.consecutive_errors > 0:
            # Escaladare la model mai puternic după eșecuri
            return self.config.escalation_model
        return self.config.model

    def _handle_tool_calls(self, response) -> None:
        """TOOLS: Procesare și execuție tool calls."""
        self.messages.append({"role": "assistant", "content": response.content})

        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                self.tool_calls_count += 1

                # GUARDRAIL: Verificare limită tool calls
                if self.tool_calls_count > self.config.max_tool_calls:
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": "EROARE: Limita de apeluri instrumente atinsă.",
                        "is_error": True
                    })
                    continue

                handler = self.config.tool_handlers.get(block.name)
                if handler is None:
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": f"EROARE: Instrument necunoscut '{block.name}'",
                        "is_error": True
                    })
                    self.consecutive_errors += 1
                    continue

                try:
                    result = handler(**block.input)
                    self._log("TOOL_CALL", {
                        "tool": block.name,
                        "input": block.input,
                        "result_preview": str(result)[:200]
                    })
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": json.dumps(result, ensure_ascii=False)
                    })
                except Exception as e:
                    self.consecutive_errors += 1
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": f"EROARE la execuția instrumentului: {str(e)}",
                        "is_error": True
                    })

        self.messages.append({"role": "user", "content": tool_results})

    def _log(self, event: str, data: dict) -> None:
        """GUARDRAILS/OBSERVABILITY: Logging complet."""
        entry = {
            "iteration": self.iteration,
            "timestamp": time.time(),
            "event": event,
            "tokens_used": self.tokens_used,
            "tool_calls": self.tool_calls_count,
            **data
        }
        self.trace.append(entry)

    def _finalize(self, reason: str, result: str = "") -> dict:
        """Generează raportul final al execuției."""
        return {
            "status": reason,
            "result": result,
            "metrics": {
                "iterations": self.iteration,
                "tokens_used": self.tokens_used,
                "tool_calls": self.tool_calls_count,
                "estimated_cost_usd": self.tokens_used * 0.000015  # Estimare
            },
            "trace": self.trace
        }

Exemple din Industrie: Agenți AI în Producție (2026)

Câteva exemple verificabile de implementări enterprise:

1. Klarna — Agent de Customer Service: Klarna a raportat că agentul lor AI gestionează echivalentul muncii a 700 de angajați full-time, rezolvând 2/3 din interacțiunile cu clienții. Agentul operează la Nivel 2 (semi-autonom) cu escaladare automată către oameni pentru cazuri complexe.

2. Devin / Cognition Labs — Agent de Software Engineering: Primul agent comercial de dezvoltare software operează la Nivel 3, capabil să citească specificații, să scrie cod, să ruleze teste și să facă debugging autonom. Evaluările publice raportează că poate rezolva autonom o parte din issue-urile GitHub de complexitate medie — cifrele exacte variază semnificativ între benchmark-uri; consultă evaluări independente actuale înainte de a te baza pe un procent.

3. Harvey AI — Agent Juridic: Utilizat de firme mari de avocatură, Harvey operează ca agent semi-autonom pentru cercetare juridică, analiză de contracte și due diligence. Agentul caută în baze de date juridice, sintetizează precedente și generează memorandumuri — totul sub supervizarea unui avocat.

Recapitulare și Pregătire pentru Lecția Următoare

În această lecție am stabilit fundamentele conceptuale ale agenților AI:

1. Taxonomia autonomiei: 5 niveluri, de la LLM stateless la sisteme multi-agent
2. The Agentic Stack: Brain, Tools, Memory, Planning, Guardrails
3. Diferența agent vs. automatizare tradițională: raționament adaptiv vs. fluxuri deterministe
4. Anti-pattern-uri critice: over-agentification, lipsa circuit breaker-elor, zero HITL
5. Arhitectura completă: implementare end-to-end cu budget enforcement

Ai acum harta agentului — cele cinci niveluri de autonomie, cei cinci piloni ai stivei agentice și anti-pattern-urile care fac diferența dintre un demo și un sistem care rezistă. Dar un agent stă sau cade după un singur lucru: cât de bine gândește înainte să acționeze. Aici intervine Planning-ul — și tocmai el separă agentul care duce un task la capăt de cel care se învârte în cerc, consumând buget fără să avanseze. În lecția următoare adâncim exact această componentă, cu pattern-urile ReAct, Plan-and-Execute și Reflexion, implementări complete și analiza comparativă a costurilor și performanței — iar de aici fiecare lecție adaugă o piesă până când vei putea construi singur un agent care merită pus în producție.