Ce este un AI agent: cinci tipuri clasice, două definiții rivale

Cel mai vechi exemplu din domeniu este un aspirator într-o lume cu două pătrate, A și B, fiecare fie curat, fie murdar.¹ A supraviețuit în fiecare manual pentru că este cea mai mică lume în care un agent poate avea dreptate sau se poate înșela.

Perceptul este o pereche — unde sunt și dacă aici este murdar — iar acțiunile sunt SUCK, LEFT și RIGHT. Întregul program este o singură linie.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

Rulează-l împotriva fiecărei configurații inițiale a lumii cu două pătrate:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

Acesta este un simple reflex agent: acționează doar pe perceptul curent, fără memorie a vreunui lucru de dinainte. Nu este o categorie-jucărie — un termostat este una, la fel și un singur apel către un model de limbaj fără conversație atașată.

Acum strică-l așa cum o face realitatea. Un robot aspirator real are un senzor de murdărie și o bară de protecție, nu un pătrat etichetat A sub covor. Scoate locația din percept și nu schimba nimic altceva:

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

Același program, două pătrate. Dintr-o stare inițială termină în trei pași; din alta intră în peretele din dreapta de cinci sute de ori și ar continua până i s-ar termina bateria. Nu poate percepe diferența dintre cele două situații, deci nu poate acționa diferit în ele. Russell și Norvig formulează rezultatul general într-o singură linie: buclele infinite sunt adesea inevitabile pentru simple reflex agents în medii parțial observabile.¹

Există o rezolvare care costă o linie și zero memorie, merită măsurată înainte să întindem mâna după ceva mai inteligent.

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

Două mii de rulări ale unui coridor complet murdar la trei dimensiuni, cu același generator seed-uit peste tot:

Randomizarea elimină complet bucla. Dar costă: opt camere au nevoie de cincisprezece mișcări dacă știi ce faci, iar acest agent are o medie de 68,7 și o dată a avut nevoie de 306. Acesta este întregul capitol în miniatură. Fiecare capabilitate pe care o adăugăm cumpără corectitudine într-un caz pe care agentul anterior nu îl putea gestiona și facturează pentru ea într-o monedă pe care trebuie mai întâi să o numești.

Un agent percepe mediul prin senzori și acționează prin actuatori. Programul de agent este funcția de la percepturi la acțiuni — fiecare listare de mai sus este una. Secvența de percepturi este tot ce a fost perceput până acum, iar un simple reflex agent ignoră totul în afară de ultimul element.

Raționalitatea este cuvântul pe care cele mai multe articole îl greșesc, iar dacă îl nimerești, restul capitolului devine utilizabil. Un agent nu este rațional sau irațional în sine. Russell și Norvig definesc un agent rațional ca fiind unul care, pentru fiecare secvență posibilă de percepturi, selectează acțiunea despre care se așteaptă să maximizeze măsura de performanță, având în vedere dovezile acelei secvențe și orice cunoștințe încorporate are.¹ Măsura de performanță nu este în interiorul agentului: aparține designerului, iar raționalitatea este definită doar relativ la ea.

Specificația se scrie convențional ca patru lucruri, PEAS: măsură de performanță, mediu, actuatori, senzori.

Observă care rând este cel ciudat. Aproape fiecare echipă care construiește agents în 2026 notează E, A și S — schemele tool-urilor, integrările, formatul mesajului — pentru că fără ele codul nu rulează. Aproape nimeni nu notează P. Fără ea, „agentul nostru se descurcă bine” nu are un sens pe care cineva să îl poată verifica, iar „rațional” nu poate fi aplicat deloc sistemului, ci doar unei demonstrații. Capitolul 29 este despre transformarea lui P într-un număr, iar acesta este motivul pentru care există.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

Mediile de sarcină sunt clasificate în continuare de-a lungul a șapte axe, dintre care cinci decid cea mai mare parte a dificultății de aici: complet sau parțial observabil, determinist sau nu, episodic sau secvențial, static sau dinamic, cunoscut sau necunoscut.¹ Un agent care vorbește cu tool-uri reale printr-o rețea reală se află în colțul greu al tuturor celor cinci — nedeterminist chiar și la temperatură zero (Capitolul 17) și, cel subestimat, necunoscut, pentru că nu ai un model fiabil despre ce fac propriile tale tool-uri lumii. De aceea bucla din Capitolul 23 are nevoie de tratarea erorilor mai mult decât de planificare.

Podelele reale nu sunt unidimensionale, așa că promovează lumea la un plan. Diezii sunt pereți, asteriscurile sunt murdărie, iar robotul pornește în camera din mijloc:

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

Upgrade-ul evident este memoria. Agentul păstrează o hartă: fiecare pătrat pe care a stat și fiecare pătrat unde s-a declanșat bara de protecție. Regula lui este să meargă într-un pătrat adiacent pe care nu l-a vizitat — dreapta, apoi jos, apoi stânga, apoi sus — și să se retragă când totul în jurul lui este cunoscut. Acesta este un model-based reflex agent: menține stare internă din istoricul percepturilor, așa că poate acționa pe baza a ceea ce nu vede în momentul curent.

Este o îmbunătățire reală și tot nu este suficient:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

Cinci mii de mișcări, jumătate din podea nevăzută. Harta este corectă, iar regulile sunt corecte. Ce nu poate face agentul este să folosească harta ca să meargă undeva: regulile lui răspund mereu doar la „în care dintre cei patru vecini ar trebui să pășesc”, așa că odată ce rămâne fără pătrate nevizitate lângă el, nu are nicio cale să exprime gândul există un pătrat nevizitat la opt mișcări distanță și aș vrea să stau pe el. Știe unde este. Nu știe unde vrea să fie.

Un goal-based agent deține, pe lângă modelul său despre lume, o descriere a situației pe care vrea să o producă și alege acțiuni căutând prin secvențe ale acestora până găsește una care se termină acolo. Obiectivele transformă selecția acțiunii dintr-o căutare în tabel într-o căutare propriu-zisă.

Obiectivul este „nu rămâne niciun pătrat murdar”. Căutarea este o parcurgere breadth-first până la cel mai apropiat pătrat murdar, iar calea pe care o returnează este planul.

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

Douăzeci și șapte de mișcări, podea curată. Dar uită-te la coloana bateriei și la ultimul segment al planului. Coloana 0 este mochetată: traversarea unui pătrat cu mochetă costă șase unități de baterie, un pătrat cu gresie costă una. Agentul s-a întors acasă pe coloana 0 pentru că sunt patru mișcări în loc de opt, iar acele patru mișcări pe mochetă au costat 24, în timp ce ocolul de opt mișcări ar fi costat 13.

Nu poate face altfel. Un obiectiv este un test binar: podeaua este curată sau nu este. Fiecare plan care se termină cu o podea curată îl satisface la fel, așa că atunci când mai multe reușesc, agentul nu are pe ce să aleagă între ele. Ca să preferi o reușită în locul alteia ai nevoie de un număr peste rezultate, iar acel număr este o funcție de utilitate. Un agent care o maximizează este un utility-based agent.

Schimbarea în cod este un singur termen în interiorul căutării. Breadth-first search numără mișcări; fă-l să numere costul în schimb și ai algoritmul lui Dijkstra și un agent diferit:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

Patru mișcări în plus, unsprezece unități de baterie în minus: cu douăzeci și unu la sută mai ieftin. Același obiectiv, aceeași hartă, același cod cu excepția unui termen. Cei doi agents diferă doar prin ceea ce încearcă să facă bine și iau rute diferite spre casă.

Acesta este și primul punct în care agentul are nevoie de ceva ce nu poate produce. Cineva trebuie să decidă cât valorează o unitate de baterie relativ la o mișcare. Utilitatea este măsura de performanță scrisă într-o formă cu care agentul poate calcula, iar scrierea ei este treaba designerului. Când oamenii spun că un agent „a optimizat lucrul greșit”, aproape niciodată nu vorbesc despre un bug. Vor să spună că această linie a fost scrisă neglijent.

Acum lasă murdăria să reapară. Patru camere se murdăresc din nou la patru rate diferite, iar agentului nu i se spun niciodată. Vizitează o cameră per tick și vede doar acea cameră. Măsura de performanță este numărul de room-ticks petrecute murdare pe parcursul a 4.000 de ticks — mai puțin este mai bine.

Un learning agent, în descompunerea din manual, este oricare dintre cele de mai sus plus trei părți: un element de învățare care schimbă agentul, un critic care îi spune cum se descurcă agentul față de un standard fix de performanță și un generator de probleme care propune acțiuni ce merită încercate pentru ceea ce ar preda.¹ Trei politici în același mediu. Prima nu învață; a doua și a treia învață același lucru și îl folosesc diferit.

Ratele ascunse erau 0,35 pentru bucătărie, 0,05 pentru hol, 0,02 pentru birou și 0,01 pentru pod — iar learner A le-a găsit. A identificat corect bucătăria ca fiind cea mai murdară cameră din casă, apoi a mers în bucătărie la fiecare tick pentru restul simulării, în timp ce celelalte trei au rămas murdare pentru totdeauna. Este de cinci ori mai rău decât să nu învețe deloc și nu este stricat.

Lecția este cea din secțiunea despre utilitate. Learner A a maximizat „probabilitatea ca încăperea pe care urmează să o vizitez să fie murdară”. Măsura de performanță era „room-ticks petrecute murdare”. Numere diferite; al doilea este ceea ce puncta criticul, iar nimeni nu i-a spus agentului. Learner B înmulțește aceeași rată învățată cu timpul scurs de la ultima vizită — murdăria pe care se așteaptă să o găsească, nu șansa de a găsi oricare — și bate patrularea de la care a pornit.

Un detaliu de implementare a decis rezultatul. În prima versiune a lui learner B, o cameră în care nu apăruse nicio murdărie în trei vizite primea o rată exact zero — iar zero înmulțit cu orice este zero, deci nu mai era vizitată niciodată și estimarea nu mai putea fi corectată. Netezirea fracției, reușite plus unu peste încercări plus doi, a transformat 11.895 în 1.576. „Încă nu a fost observat” și „măsurat și a ieșit zero” sunt afirmații diferite, iar un sistem care le stochează în același câmp ia decizii pe care nu le poate desface.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

Fiecare dintre cele cinci este astăzi în producție sub alt nume.

Două rânduri sunt mai aproape decât o analogie, într-un mod care costă bani.

Chatul este un model-based reflex agent al cărui model nu este intern. În manual, starea este o variabilă în interiorul programului de agent. Într-un chat este transcriptul: trăiește la tine, este retrimis integral la fiecare apel și este reconstruit de la zero în interiorul modelului de fiecare dată. Aceasta este factura pătratică din Capitolul 16 și este același obiect pe care manualul l-a desenat ca o cutie etichetată „stare”. Iată diferența, măsurată pe o singură întrebare de follow-up, cu și fără cele două mesaje dinainte:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

Același model, aceleași trei cuvinte de input de la utilizator, iar al doilea este robotul din coridor care intră în perete. Nu au existat tool-uri în acea rulare, deci 15 este inventat — dar starea este ceea ce face ca follow-up-ul să însemne ceva. O reconstruiești de fiecare dată și plătești de 2,3× mai mulți token de intrare pentru ea într-o conversație de două ture. Capitolul 16 a măsurat unde ajunge multiplicatorul până la tura patruzeci.

Reflexion este un learning agent care își schimbă inputul, nu programul. În descompunerea din manual, elementul de învățare modifică elementul de performanță. Reflexion lasă weights în pace și scrie text reflexiv într-un buffer episodic pe care următoarea încercare îl citește.³ Elementul de învățare este un prompt, memoria este un rând în baza de date, elementul de performanță este un model înghețat — iar diagrama este cea din manual, neschimbată.

Și iată limita onestă a mapării. Cele cinci tipuri clasifică programul de agent. În 2026, acel program este rupt pe mijloc: o parte este codul tău, o parte este în weights pe care nu le-ai antrenat. Când un model decide singur să apeleze un tool, testul de obiectiv este în programul tău sau în model? Taxonomia nu are niciun răspuns, pentru că atunci când a fost scrisă nu exista alt loc unde să fie — iar întrebarea aceasta este exact locul în care cele două definiții moderne se despart.

Definițiile sunt argumente despre comportament și sunt mult mai ușor de judecat cu un trace în față.

Bucla de mai jos trimite conversația către un model; dacă răspunsul conține un tool call, execută tool-ul, atașează rezultatul și trimite totul din nou. Rulează împotriva unui Qwen2.5-0.5B-Instruct local, în spatele unui endpoint cu formă OpenAI, pe această mașină — cusătura din Capitolul 14, deci bucla nici nu știe, nici nu îi pasă ce se află în spatele portului.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

Două linii poartă întreaga idee, iar ambele sunt marcate; restul este bookkeeping. Toate cele trei comportamente sunt vizibile într-o singură rulare. Întrebat ceva ce poate face singur, modelul răspunde. Întrebat ceva ce nu poate, apelează:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

Și se oprește — al treilea comportament și cel mai ușor de ratat, pentru că arată ca și cum nu s-ar întâmpla nimic. Bucla se termină pentru că tura 2 a revenit fără un tool call. Nimeni nu a decis asta; modelul a decis, emițând proză. Condiția de terminare a acestui program este semnul unei absențe.

Încă două rulări merită spațiul. Întrebat să compare două orașe, modelul emite ambele tool calls într-o singură tură, primește ambele valori înapoi și greșește comparația:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

Tool-urile au funcționat. Apelul paralel a funcționat. Bucla a funcționat. Răspunsul este fals, cu ambele numere corecte așezate în transcript. Împachetarea unui model într-o buclă nu îl face să raționeze; îi dă unui model care greșește capacitatea de a acționa pe baza faptului că greșește — ceea ce este Capitolul 30 în avans și jumătate din Capitolul 29.

Acum șterge return marcat și lasă bucla să ruleze până la limita ei. Aceeași întrebare, același model:

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

De patru ori mai mulți token de intrare, de patru ori mai mult timp de ceas și un final în care agentul a uitat ce fusese întrebat și interoghează utilizatorul despre o întrebare la care acesta răspunsese în tura unu. Răspunsul corect era pe ecran la tura 2, iar fiecare tură de după a făcut transcriptul mai rău.

Așadar, un agent nu este o buclă. Este o buclă plus o regulă pentru a ieși din ea, iar aceasta are exact o astfel de regulă. Capitolul 23 găsește cinci și arată ce se strică atunci când fiecare lipsește.

Ambele citate, nu parafrazate, pentru că parafrazele sunt locul unde se fabrică confuzia.

Definiția unu pune granița la cine controlează fluxul. Building effective agents de la Anthropic numește ambiguitatea și decide asupra ei:

„La Anthropic, categorisim toate aceste variații drept sisteme agentic, dar trasăm o distincție arhitecturală importantă între workflows și agents: Workflows sunt sisteme în care LLM-urile și tool-urile sunt orchestrate prin căi de cod predefinite. Agents, pe de altă parte, sunt sisteme în care LLM-urile își direcționează dinamic propriile procese și propria utilizare a tool-urilor, menținând controlul asupra modului în care îndeplinesc sarcinile.”⁴

Testul este o întrebare despre codul tău sursă: cine a ales pasul următor? Un switch în programul tău: workflow. Modelul: agent. Același document spune că agents „sunt de obicei doar LLM-uri care folosesc tool-uri pe baza feedbackului din mediu într-o buclă” — exact listarea de mai sus.

Definiția doi pune granița la independența față de utilizator. A practical guide to building agents de la OpenAI își deschide pagina de definiții așa:

„În timp ce software-ul convențional le permite utilizatorilor să simplifice și să automatizeze workflows, agents pot realiza aceleași workflows în numele utilizatorilor, cu un grad ridicat de independență. Agents sunt sisteme care îndeplinesc independent sarcini în numele tău.”⁵

Două propoziții mai târziu, pe aceeași pagină, exclude:

„Aplicațiile care integrează LLM-uri, dar nu le folosesc pentru a controla execuția workflow-ului — gândiți-vă la chatbots simpli, LLM-uri single-turn sau clasificatoare de sentiment — nu sunt agents.”⁵

Citește aceste citate în ordine. Propozițiile de deschidere trag linia la independență: pleacă acest lucru și termină treaba fără mine? A patra o trage la controlul execuției, adică exact linia Anthropic. Teste diferite, aceeași pagină, și există sisteme reale asupra cărora nu sunt de acord.

Dededesubt există o coliziune de vocabular și ea provoacă dispute în ședințe reale. În primul document, un workflow este o arhitectură și este lucrul care nu este un agent. În al doilea, un workflow este „o secvență de pași care trebuie executați pentru a îndeplini obiectivul utilizatorului” — treaba însăși, din care fiecare agent are una. „Am înlocuit workflow-ul cu un agent” este coerent sub prima definiție și aproape lipsit de sens sub a doua.

Trei sisteme care există în 2026, sub ambele definiții.

Două dintre cele trei schimbă tabăra. Aceasta nu este o defecțiune a vreunuia dintre documente. Este un avertisment despre un tip de ședință în care doi oameni care sunt complet de acord despre ce face un sistem petrec o oră contrazicându-se despre cum să îl numească.

Definițiile se ciocnesc pentru că fiecare comprimă două întrebări independente într-un singur cuvânt. Separă-le și dezacordul devine un tabel, mai util decât un verdict.

Fiecare definiție contestă o celulă diferită, iar celelalte două nu sunt contestate deloc. Deci atunci când eticheta contează — într-un contract, o analiză de risc, un postmortem — cele două propoziții care merită scrise nu sunt „este agent?” ci cine a ales pasul următor și cine urmărea. Ambele pot primi răspuns citind cod, niciuna nu are nevoie de definiția cuiva, iar împreună poartă fiecare consecință pe care eticheta trebuia să o reprezinte.

Nimic din acestea nu este nou. Wooldridge și Jennings au trecut în revistă sensurile concurente ale cuvântului „agent” în 1995;⁶ Franklin și Graesser au pus întrebarea acestui capitol în 1996, au adunat definițiile aflate în circulație și au constatat că nu erau de acord.⁷ Un survey din 2023 încă definește agents de la primele principii — „entități artificiale care își simt mediul, iau decizii și întreprind acțiuni”⁸ — pentru că nu exista nimic stabilit de citat, iar CoALA descrie părți în loc să traseze o graniță.⁹ Treizeci de ani de refuz de a ajunge la un acord spun că acest cuvânt face mai mult de o treabă.

Acum consecința care sosește înaintea filosofiei, adică factura.

Fiecare măsurătoare de aici are aceeași formă. Apelul unic a costat 39 token de intrare; aceeași întrebare cu un tool a costat 420 pe două apeluri; bucla cu regula de oprire eliminată a costat 1.688 pe șase. Creșterea este mai rea decât liniară, pentru că tura n poartă cu ea fiecare tură anterioară: coloana prompt a acelei rulări de șase ture citește 187, 238, 261, 302, 327, 373. Capitolul 16 a derivat că totalul este $\Theta(n^2)$ și a potrivit curba pe o conversație reală. Un agent transformă fiecare sarcină în acea conversație, indiferent dacă un om o vede vreodată sau nu.

Dacă acele numărători de token măsurate ar fi mers la un endpoint comercial la tarifele citite de Capitolul 16 pe 6 septembrie 2026 — $2,00 per milion de token de intrare și $12,00 per milion de ieșire — cele patru rulări ar arăta ca preț astfel:

Rândul doi față de rândul unu este numărul de ținut minte. De șapte ori și jumătate costul, pentru un răspuns mai prost la o întrebare pe care modelul o știa deja. Nimic nu era configurat greșit: exista un tool, așa că modelul l-a folosit — iar constatarea din Capitolul 18, că prețul unui catalog, nu acuratețea lui, este ceea ce doare, are aici cea mai ieftină demonstrație cu un catalog de unu.

De aceea jumătatea utilă a ambelor documente este jumătatea despre a nu construi asta. Anthropic este direct: găsește cea mai simplă soluție posibilă și adaugă complexitate doar când este necesar, ceea ce „ar putea însemna să nu construiești deloc sisteme agentic”, deoarece sistemele agentic „schimbă latență și cost pe performanță mai bună a sarcinii” și „pentru multe aplicații, optimizarea apelurilor LLM unice cu retrieval și exemple in-context este de obicei suficientă”.⁴ Cazul său pentru un agent este îngust: probleme deschise unde nu poți prezice numărul de pași și nu poți hardcoda o cale, într-un mediu în care ai încredere, acceptând „costuri mai mari și potențialul de erori care se compun”.⁴ Ecranul OpenAI este imaginea în oglindă — judecată complexă, seturi de reguli imposibil de întreținut, date nestructurate — și se termină la fel: „altfel, o soluție deterministă poate fi suficientă”.⁵

Așadar, în taxonomia acestui capitol: un număr fix de pași într-o ordine fixă este un pipeline, iar faptul că îl numești agent nu îl va face mai rapid. Dacă numărul de pași depinde de ce găsești pe drum, vrei o buclă — și cumperi acea flexibilitate cu N apeluri, un transcript pătratic și un sistem care poate greși de N ori în loc de o singură dată.

Acum ai taxonomia, ambele definiții moderne, cele două axe care le fac compatibile și o buclă scurtă care răspunde, apelează și se oprește.

Acea buclă are o singură cale de a se termina: modelul nu mai cere tool-uri. Capitolul 23 o strică intenționat, de șapte ori, iar fiecare ruptură adaugă o piesă. O sarcină imposibilă, și nu se termină niciodată — o limită de ture. O noapte de rulare, și factura sosește — un buget în dolari. Un tool care eșuează — o eroare pe care modelul o poate folosi. Același apel de două ori — o cheie de idempotency. Un fișier pe care nu ar fi trebuit să îl atingă — o aprobare umană. Un restart la jumătate — persistența sesiunii. Un tool care durează trei minute în tăcere — progres și anulare. Ce iese este un harness, fișierul pe care rulează restul acestui curs.

Ceea ce lasă întrebarea despre care era de fapt diagonala disputată a acestui capitol. O buclă care își decide singură pasul următor trebuie să decidă când se oprește, iar tocmai am văzut ce se întâmplă când nu poate: șase ture, de patru ori factura și un agent care interoghează utilizatorul despre o întrebare la care răspunsese deja. Oprirea nu este o singură condiție. Câte sunt și care se declanșează prima?

LLM Powered Autonomous Agents (2023) de Lilian Weng este cea mai cunoscută descompunere a unui language agent în planificare, memorie și utilizarea tool-urilor și este lectura următoare potrivită alături de cele două documente de vendor; cele trei componente ale sale sunt Capitolele 23, 24 și 18 ale acestui curs, în această ordine.

Fiecare număr din acest capitol a fost produs pe această mașină și nimic nu a fost estimat. Coridorul, planul etajului, cei patru agents care îl parcurg și cele trei politici de patrulare sunt TypeScript-ul de mai sus, rulat pe Node 22; cifrele agentului randomizat sunt medii peste câte 2.000 de rulări seed-uite, iar cifrele de patrulare sunt rulări seed-uite unice de 4.000 de ticks. Trace-urile de model vin din Qwen2.5-0.5B-Instruct în float32 pe CPU cu greedy decoding, servite peste loopback de un mic endpoint Python local care încarcă weights și vorbește forma OpenAI chat-completions — din nou cusătura, cu tensorii pe partea de Python și bucla pe cea de TypeScript — deci numărătorile de token sunt cele ale tokenizerului acelui model, iar latențele sunt ale acelei mașini. Singurele cifre luate din altă parte sunt cele două prețuri din tabelul de cost, care sunt tarifele citite de Capitolul 16 din pagina de prețuri OpenAI pe 6 septembrie 2026, aplicate aici numărătorilor de token măsurate local ca ilustrare, nu ca factură observată.