Componentele principale

Ce este o componentă principală a unui coding agent?¶

Deschide codul sursă sau documentația aproape oricărui coding agent de nivel de producție - Codex CLI scris în Rust, opencode în TypeScript, părțile cu sursă publică din Claude Code, agenții livrați de o jumătate de duzină de vendori mai mici - și vei vedea conturându-se aceeași arhitectură: un set restrâns de componente principale împachetate într-un harness. Implementările diferă. Anatomia converge. Uneori alte nume, întotdeauna altă așezare a fișierelor, dar aceleași cărămizi conceptuale. Cele mai multe sunt capabilități locale ale agentului. Una singură - subagenții - e mecanismul de compoziție care face agentul recursiv: poate porni instanțe constrânse ale lui însuși.

Context window. Tool-uri. Permisiuni / Sandbox. Skill-uri. Plugin-uri. MCP. Memory. Subagenți.

Subagenții au intrat de curând în vocabularul public - nu pentru că ideea ar fi nouă, ci pentru că au devenit universali la toți agenții majori într-un interval foarte scurt. Claude Code a livrat tool-ul Task, apoi a construit peste el Agent Teams, pentru coordonare la nivel mai înalt. La începutul lui 2026, Codex CLI expunea deja subagenții ca workflow de primă clasă și permitea rularea mai multor subagenți în paralel. Cursor 2.0 a introdus propriul sistem de subagenți. Cline i-a livrat nativ. În circa un an, dispatch-ul unei instanțe-copil constrânse a agentului a trecut de la „workflow avansat” la „o componentă principală pe care harness-ul îl expune by default”. Ăsta e testul pe care îl folosesc pentru statutul de componentă principală, iar subagenții îl trec.

Asta e anatomia. Orice întrebare interesantă despre un coding agent - ce poate face, ce nu poate face, cum îl controlezi, cu ce îl compari - se reduce la unul sau mai multe dintre aceste componente principale. Când apare un agent nou, prima ta întrebare e: cum tratează acesta fiecare componentă principală? Când decizi dacă lași un agent să se atingă de un anumit codebase, a doua întrebare e: care componentă principală e punctul de control relevant pentru riscul respectiv? Când cumperi tooling, a treia întrebare e: ce componentă principală îmbunătățește tooling-ul ăsta și cu ce cost?

Context window-ul - fereastra de context - e ceea ce agentul știe chiar acum. E mărginită: fiecare model are un număr maxim de tokeni pe care îi poate ține în atenția activă. Două sute de mii la un model de gamă medie. Un milion la unul de top. Cifrele astea cresc de la un trimestru la altul; până ajungi tu să citești rândurile astea, vor fi și mai mari. Dar limita există, și limita contează, pentru că fereastra de context e spațiul de lucru în interiorul căruia agentul ia decizii.

Ce intră în context window? System prompt-ul care definește rolul și constrângerile agentului. Istoricul conversației curente cu utilizatorul. Tool call-urile pe care le-a făcut agentul și rezultatele pe care i le-au întors. Fișierele pe care le-a citit sau bucățile de fișiere pe care le-a încărcat. Orice instrucțiuni injectate de harness (ajungem imediat și la harness). Cam asta umple fereastra.

Ce nu intră în context window by default? Restul codebase-ului tău. Istoricul de git. Ticketele din Jira. Wiki-ul din Confluence. Canalul de Slack unde echipa discută arhitectura. Toate astea sunt potențial relevante, toate există pe undeva, dar niciuna nu ajunge automat în atenția agentului. Agentul trebuie să le ceară - prin tool-uri, prin plugin-uri, prin MCP. Ceea ce înseamnă că agentul trebuie să știe că ele există, sau să i se spună, sau să fie configurat să le caute.

Asta e prima surpriză pentru echipele care abia încep să lucreze cu agenți. Agentul e sclipitor la lucrurile pe care le vede și complet orb la tot restul. Cele mai multe eșecuri de tip „agentul a luat o decizie evident greșită” se reduc, la o privire atentă, la „agentul nu a avut contextul necesar ca să ia decizia corectă”. Agentul nu știa de noua bibliotecă de autentificare pentru că nu i-a spus nimeni. A ales by default framework-ul de teste greșit pentru că nimeni nu a pus preferința echipei în configurație. Agentul a luat cea mai bună decizie posibilă cu contextul pe care îl avea, iar decizia a fost greșită pentru că acel context era incomplet.

Gestionarea context window-ului e, prin urmare, una dintre disciplinele inginerești centrale ale programării cu agenți. Decizi în permanență ce încarci, ce rezumi, ce arunci, ce ceri la momentul potrivit. Ferestrele de context mai mari ajută - un milion de tokeni de context e, într-adevăr, mult mai iertător decât două sute de mii - dar ferestrele mai mari nu elimină constrângerea. Doar ridică plafonul.

Tool-urile sunt acțiunile pe care le poate face agentul. Să citească un fișier. Să scrie un fișier. Să editeze un fișier pe loc. Să ruleze o comandă de shell. Să caute un text în tot codebase-ul. Să listeze conținutul unui director.

Majoritatea coding agents de nivel de producție converg spre cam același set de tool-uri de bază. Read, Write, Edit, Bash, Glob, Grep. Uneori câteva în plus - rularea unui snippet de Python, fetch pe un URL, parsarea unui document structurat. Acestea sunt verbele. Fără ele, agentul ar putea gândi, dar n-ar putea acționa.

Tool-urile sunt simple conceptual și importante operațional. Fiecare tool call e un punct de decizie. Fiecare tool call e și un punct de audit - agenții de nivel de producție ar trebui să înregistreze tool call-urile făcute, în ordine, cu tot cu argumente, ca să poți reconstitui și inspecta ulterior comportamentul agentului. Dacă ai avut vreodată de debugat o acțiune de agent în mai mulți pași care a luat-o razna, o să apreciezi pista de audit. Log-ul de tool call-uri e echivalentul log-ului de query-uri SQL într-o problemă de bază de date - fără el, ghicești.

Tot la nivelul tool call-urilor trăiește și guvernanța. O să dedicăm un capitol întreg subiectului, dar, pe scurt: când îi spui unui agent „nu șterge fișiere din directorul ăsta”, ceea ce faci de fapt e să interceptezi tool call-ul de Bash înainte să execute comanda rm. Tool call-ul e bottleneck-ul. Constrângi tool call-urile, constrângi agentul. Lași tool call-urile să ruleze neconstrânse și ai un agent care poate face orice.

Permisiuni / Sandbox¶

Permisiuni / Sandbox e componenta principală care i-a lipsit lui PocketOS. Are două jumătăți, iar ele nu sunt același control scris în două feluri - sunt două controale diferite, pe care agenții convergenți le livrează împreună pentru că fiecare prinde ce scapă celălalt.

Stratul de decizie de la nivelul agentului e cel pe care agentul însuși îl consultă înaintea fiecărui tool call. Reguli Allow / Ask / Deny, plus clasificatorul mai nou de auto-mode, care rezolvă în tăcere deciziile de rutină și le scoate la suprafață pe celelalte, pentru operator. Toți coding agents majori îl livrează: Claude Code, Codex CLI, opencode, Cursor, Gemini CLI. Sintaxa regulilor diferă de la vendor la vendor; rolul arhitectural, nu. E stratul spre care întind mâna întâi cele mai multe echipe. E și stratul pe care prompt injection-ul îl poate învinge, pentru că prompt injection-ul funcționează manipulând raționamentul agentului, iar tocmai raționamentul agentului e cel care consultă regulile.

Enforcement-ul la nivel de OS rulează dedesubt. Kernelul însuși refuză syscall-urile pe care agentul nu era autorizat să le facă: Seatbelt pe macOS, bubblewrap cu Landlock și seccomp pe Linux, token-uri restricționate sau izolare pe bază de WSL2 pe Windows. Agentul nu poate „raționa” pe lângă stratul ăsta, pentru că kernelul nu ascultă raționamentul agentului - ascultă apeluri de sistem. Ori syscall-ul e permis, ori nu e.

Convergența pe jumătatea asta e reală, dar inegală. Codex CLI impune sandbox la nivel de OS by default pe Linux și macOS. Cursor a adăugat controale de sandbox cu suport în kernel în linia 2.x. Gemini CLI livrează profile de sandbox per platformă. Claude Code e opt-in - sandbox-ul există, dar majoritatea instalărilor îl sar. opencode e excepția parțială: livrează doar jumătatea de decizie și lasă izolarea la nivel de OS în seama Docker-ului sau microVM-ului pe care îl configurează operatorul în jurul lui. Convergența e pe prezența ambelor jumătăți ca pachet configurabil, nu pe postură - exact asimetria pe care o are și componenta principală Memory pe a doua lui jumătate. Asta e citirea onestă.

Spus direct: stratul de la nivelul agentului poate fi ocolit prin prompt injection. Stratul de la nivelul OS-ului, nu. Cele două se livrează împreună pentru că niciunul nu e suficient singur. Perechea convergentă e componenta principală.

Capitolul 3 parcurge suprafețele de configurare ale acestei componente principale - cum își expune fiecare agent major regulile de allow/ask/deny, unde se activează sau se dezactivează sandbox-ul de OS și cum se mapează cele cinci straturi de guvernanță din acel capitol pe cele două jumătăți ale componentei principale.

Skill-urile sunt instrucțiuni împachetate, pe care agentul le încarcă atunci când devin relevante. Felul în care preferă echipa să scrie un serviciu de Spring Boot. Convențiile pentru testarea componentelor React. Pattern-ul pentru adăugarea unei coloane noi într-un tabel multi-tenant. Fiecare dintre ele e o bucată de markdown - de obicei între câteva sute și câteva mii de cuvinte - pe care agentul o citește exact în momentul în care are nevoie de expertiza respectivă.

Implementarea skill-urilor diferă de la un agent la altul în numele fișierelor și în semantica de încărcare, dar componenta principală de dedesubt e acum comună tuturor agenților majori. Componenta principală always-loaded a ajuns la convergență pe două nume de fișier: AGENTS.md, neutru față de vendor, suportat de Codex CLI, Cursor, GitHub Copilot, Gemini CLI, Aider și de restul ecosistemului; și CLAUDE.md, pe care Claude Code îl citește nativ. Cele două sunt interoperabile - Claude Code poate importa AGENTS.md în CLAUDE.md, astfel încât conținutul echipei stă într-un singur loc, indiferent de vendor. Ambele se încarcă la începutul sesiunii, ambele joacă același rol. A ajuns la convergență și componenta principală on-demand: fișiere markdown individuale, activate la detecție, ținute în afara contextului până când un task se potrivește cu trigger-ul skill-ului (Claude Code le numește Skills; Codex CLI livrează fișiere SKILL.md cu frontmatter YAML și progressive disclosure). Skill-ul de code review pentru Spring Boot se încarcă atunci când faci review pe cod Spring; nu poluează contextul când agentul ia un task de migrare de schemă. Pattern-ul always-loaded (AGENTS.md, CLAUDE.md) e mai vechi. Pattern-ul dispatch-on-detection (Skills în Claude Code, Skills în Codex) e mai nou și scalează mai bine pe măsură ce crește catalogul de skill-uri al echipei.

Ambele pattern-uri funcționează. Cel cu dispatch la detecție e mai eficient la scară - poți avea cincizeci de skill-uri pentru cincizeci de tipuri de muncă fără să umpli fereastra de context, în fiecare moment, cu patruzeci și nouă irelevante. Pattern-ul always-loaded e mai simplu și mai predictibil. Alege în funcție de tipurile de task-uri pe care le rulează echipa ta și de problemele de context plin de care te lovești.

Skill-urile sunt felul în care codifici expertiza specifică echipei într-o formă pe care agentul o poate folosi. Sunt durabile - stau în git, trec prin review în pull request, poartă semnătura autorului. Sunt cel mai apropiat lucru, în anatomia agentului, de „tribal knowledge-ul seniorului, dar pus pe hârtie”.

Plugin-urile sunt pachete. Un plugin împachetează skill-uri laolaltă cu tool-uri, cu hook-uri și cu comenzi, toate instalabile printr-o singură comandă. hookify e un plugin. Security-guidance e un plugin. Superpowers e un plugin. Plugin-ul e unitatea de distribuție.

De ce contează plugin-urile operațional: fac posibilă partajarea expertizei între echipe fără ca fiecare echipă să reconstruiască aceeași schelărie. Dacă o echipă construiește un workflow excelent de review de PR-uri sub formă de plugin, altă echipă îl poate instala cu o singură comandă. Plugin-ul își gestionează singur versiunile, dependențele, activarea. Echipa care îl primește nu trebuie să-l integreze manual.

De ce contează plugin-urile strategic: creează un marketplace. În mai 2026, marketplace-ul de plugin-uri devenise deja un canal de distribuție real, cu plugin-uri oficiale și comunitare care începeau să formeze un ecosistem. Numărul exact contează mai puțin decât schimbarea de fond: plugin-urile sunt acum o suprafață de supply chain. Marketplace-ul e echivalentul npm-ului pentru programarea cu agenți - și, ca și npm, vine la pachet și cu avantajul reutilizării rapide, și cu dezavantajul riscului de supply chain. Plugin-urile trebuie verificate la fel cum verifici dependențele. Iată checklist-ul pe care îl folosesc eu.

Maintainer-ul. Cine deține plugin-ul. A fost repo-ul activ în ultimele nouăzeci de zile. Există mai mult de un maintainer sau e un bus factor de unu. Poate fi identificat autorul - un istoric real pe GitHub, un angajator real, un palmares - sau e un cont proaspăt creat, cu un singur repo. Un plugin întreținut de Anthropic, de un vendor cunoscut sau de un inginer a cărui altă activitate o poți verifica e într-o cu totul altă clasă de risc decât unul urcat săptămâna trecută de un nume pe care nu-l recunoaște nimeni.

Suprafața de permisiuni. Ce tool-uri instalează plugin-ul. Ce hook-uri înregistrează. Ce căi de fișiere atinge. Ce apeluri de rețea face. Tratează cererile de permisiuni largi exact cum ai trata un pachet npm care cere pe șest acces la filesystem și la rețea în scriptul de instalare: ca pe un red flag care are nevoie de o justificare. Un plugin de review de PR-uri nu are nevoie de drept de scriere în afara .git/. Un plugin de documentație nu are de ce să facă apeluri de rețea către un host terț. Dacă permisiunile depășesc scopul evident al plugin-ului, întreabă de ce înainte să-l instalezi.

Review-ul de cod. Citește sursa la prima instalare. Plugin-urile care merită instalate sunt suficient de mici cât să le citești în douăzeci de minute; Superpowers și hookify sunt amândouă așa. Plugin-urile prea mari ca să le citești fac, de regulă, prea multe. Dacă nu poți înțelege din sursă ce face plugin-ul într-o ședință rezonabilă de citit, e un semnal fie să cauți unul mai mic, fie să investești într-un review mai serios înainte să-l adopți.

Disciplina de update. Fixează versiunea. Nu lăsa auto-update. Tratează un update de plugin exact ca pe un update de dependență - citește diff-ul, rulează suita de teste, livrează bump-ul ca pe o schimbare trecută prin review, nu ca pe una tăcută.

Blast radius - raza de impact. Un plugin care operează în interiorul sandbox-ului agentului e mărginit de sandbox. Un plugin care înregistrează un hook ce rulează pe mașina developerului, în afara sandbox-ului, nu e mărginit de nimic. Preferă-l pe cel mărginit. Când trebuie neapărat să-l instalezi pe cel nemărginit, ridică ștacheta la tot ce am enumerat mai sus.

Marketplace-ul e un canal de distribuție real. Disciplina e aceeași pe care o folosești deja pentru dependențe. Costul unei verificări per plugin e mic față de costul unui singur incident de supply chain.

Ce este MCP?¶

MCP vine de la Model Context Protocol. E o specificație pentru felul în care agenții vorbesc cu sistemele externe. Jira-ul tău. Confluence-ul tău. Postgres-ul tău. GitHub-ul tău. Data warehouse-ul intern. Orice trăiește în afara mediului local al agentului, dar pe care agentul trebuie să-l interogheze sau să-l actualizeze.

Înainte de MCP, fiecare agent avea propria poveste de integrare. Claude se integra cu Jira într-un fel; alt agent se integra cu Jira altfel; dacă schimbai agentul, refăceai toate integrările. MCP a schimbat asta. Același server MCP care vorbește cu Jira-ul tău funcționează cu orice agent care suportă MCP - iar majoritatea coding agents serioși suportă acum MCP.

Asta contează pentru achizițiile enterprise. O integrare MCP e portabilă. Investiția pe care o faci în configurarea unui server MCP pentru sistemele tale interne nu se pierde când se schimbă peisajul agenților. Următorul agent pe care îl adoptă echipa ta va putea folosi aceleași servere MCP pe care le-ai configurat deja. MCP e cel mai apropiat lucru pe care îl are ecosistemul de AI agentic de un „standard deschis care supraviețuiește schimbărilor de vendor”.

Memory¶

Memory e componenta principală devenită universală cel mai recent. Acum optsprezece luni era implicit: agentul încărca un prompt, lucra ceva, iar sesiunea următoare pornea de la zero. Astăzi Memory are două jumătăți - una complet convergentă la toți agenții majori, una în care Claude Code deschide drumul, cu ceilalți pe traseu.

Memoria definită manual e stratul pe care îl scrie echipa. Convergența e reală: Codex CLI, Cursor, GitHub Copilot, Gemini CLI, Aider și restul ecosistemului citesc toți AGENTS.md din rădăcina repository-ului la începutul sesiunii. Claude Code citește CLAUDE.md, care poate importa AGENTS.md pentru a împărți același conținut cu ceilalți agenți. Fișierul e versionat în source control, trecut prin review în pull request-uri, deținut de echipă. Acolo trăiesc pattern-urile interzise, intrările din jurnalul de greșeli, comenzile de build și glosarele de domeniu. Capitolul 6 detaliază ce intră în fișierul ăsta și de ce contează.

Sistemul de auto-memory e ceea ce scrie agentul pentru sine. Claude Code e primul venit; ceilalți agenți converg spre mecanisme similare, dar nu livraseră echivalente la data publicării. Are două suprafețe vizibile: Auto Memory e stratul în care Claude salvează pattern-uri învățate de la o sesiune la alta - comenzi de build pe care le-a dedus, concluzii de debugging pe care le-a confirmat, preferințe de stil de cod pe care le-a inferat - fără ca utilizatorul să le fi scris explicit. Auto Dream e stratul de consolidare în fundal pe care Anthropic l-a dezvăluit la Code with Claude SF pe 2026-05-06: un proces programat care trece în revistă sesiunile recente și memoria stocată, identifică greșelile recurente și workflow-urile convergente și scrie note consolidate înapoi în memoria pe termen lung. Agentul devine mai bun pe codebase-ul tău între rulări.

O precizare despre ce nu e memorie în taxonomia asta: memoria de sesiune (istoricul conversației plus rezultatele tool-urilor din interiorul unei singure sesiuni) e doar context window-ul. E memorie în sensul de zi cu zi, dar nu o componentă principală separată - e componenta principală numită prima.

Memoria definită manual trece testul convergenței încă de azi. Sistemul de auto-memory e pe traseu - Claude Code e primul; ceilalți urmează. Manualul le tratează ca pe o singură componentă principală pentru că rolul structural e identic, cu mențiunea că a doua jumătate e un semnal de pionierat, nu încă o convergență.

Subagenții sunt instanțe-copil constrânse ale agentului însuși.

Agentul-orchestrator pornește un subagent, îi dă un task delimitat, cu un prompt cu scop restrâns, și îl lasă să ruleze în propriul context izolat, cu propriul acces limitat la tool-uri. Subagentul face treaba. Subagentul întoarce un rezultat. Orchestratorul colectează.

Ce îi face pe subagenți distincți structural față de celelalte componente principale e că sunt recursivi. Un subagent e o altă instanță a componentelor principale - are propriul context window, propriile tool-uri, propriile reguli de permisiuni și propriul sandbox, propriile skill-uri, plugin-uri, MCP și Memory - limitată la un task mai mic și izolată de contextul orchestratorului. Orchestratorul nu vede ce a văzut subagentul. Vede doar ce întoarce subagentul. Subagentul nu poluează contextul orchestratorului cu muncă intermediară. Orchestratorul nu poluează contextul subagentului cu istoric care nu-l privește.

Convergența în interval scurt cu care s-a deschis capitolul - toți agenții majori livrând subagenți în circa un an - nu e un accident. Subagenții rezolvă două probleme pe care nu le rezolvă niciun alt componentă principală: muncă în paralel delimitată de independență, nu de coordonare, și izolare a contextului delimitată de scopul task-ului, nu de istoricul sesiunii.

Utilizările principale în munca serioasă: execuția în paralel a unui plan cu mai multe task-uri (faza de Execute a buclei din Capitolul 5), review structurat (trimiți un subagent să verifice conformitatea cu specificația, altul să verifice calitatea codului) și analiză de arhitectură la scară (câte un subagent per fișier sau per modul, care întoarce rezumate structurate pe care orchestratorul le asamblează - workflow-ul din Capitolul 7).

Costul principal: tokenii. Fiecare subagent își rulează propriul model și propriile tool-uri, așa că un dispatch de opt subagenți consumă cam de opt ori tokenii unei rulări cu un singur agent. Folosește-i acolo unde contează paralelismul sau izolarea. Nu-i folosi by default pentru muncă pe care un singur agent ar putea s-o facă liniar.

La mijlocul lui 2026, compoziția asta începe să fie oferită direct de tool-uri, ca funcționalitate. /workflows din Claude Code pune agentul să scrie un script scurt care trimite subagenți în mod determinist - fazele rulează în ordine, munca se ramifică în paralel sau curge printr-un pipeline, fiecare predare întoarce o structură validată după o schemă, nu text liber, iar un pas de verificare poate pune un gate pe rezultat înainte să-l întoarcă. Un singur workflow se poate ramifica în sute de copii, ține munca lor intermediară în variabile de script, nu în context window-ul orchestratorului, se poate relua și are buget limitat. Nu e o componentă principală nouă. E o comoditate la nivel de harness peste componenta principală subagent pe care îl ai deja: determinismul - fluxul de control scris în cod, predări validate prin schemă - e singura diferență reală față de dispatch-ul condus de model pe care ți-l dă deja un plugin ca Superpowers, unde orchestratorul decide în timpul rulării câți copii pornește și le citește înapoi proza. Apelează la varianta scriptată când fan-out-ul e mare, repetabil sau merită verificat mecanic; apelează la dispatch-ul condus de model când nu știi forma muncii până nu intri în ea cu agentul. Ce se compune e același lucru în ambele cazuri.

Revenim la subagenți în Capitolul 5 (Execute) și în Capitolul 7 (review de arhitectură la scară). Ideea din capitolul ăsta e că ei nu sunt o tehnică așezată peste arhitectură. Sunt componenta principală de compoziție al arhitecturii.

Mai e o piesă care le organizează pe toate. Vendorii îi spun harness. Harness-ul e runtime-ul din jurul modelului - partea care transformă modelul brut în ceva util pentru scris cod.

Când îi ceri unui agent să facă o treabă, harness-ul e codul care îți ia cererea, o formatează pentru model, gestionează context window-ul, trimite spre execuție tool call-urile pe care vrea să le facă modelul, capturează rezultatele, i le dă înapoi modelului, decide când a terminat modelul și îți întoarce rezultatul final. Toate componentele principale trăiesc în interiorul harness-ului. Harness-ul e arhitectura; componentele principale sunt componentele.

De ce contează distincția asta: când compari agenți, tentația e să compari modele. „E Claude Code mai bun decât Codex sau Cursor pentru workflow-ul pe care îl rulează echipa mea?” - asta e întrebarea corectă. „Care model are scorul de benchmark mai mare trimestrul ăsta?” - asta e cea greșită. Modelul determină plafonul. Harness-ul determină dacă îl atingi. Compară harness-uri, nu modele.

Spus simplu: harness-ul e tot ce îmbracă bucla agentului. Bucla agentului în sine e banală. Are cam forma unui handler de request HTTP dintr-un framework web - primește promptul, rulează modelul, execută tool-urile, întoarce răspunsul, repetă. Middleware-ul din jurul buclei e locul unde stă munca adevărată. Middleware-ul este harness-ul, este componentele principale, este ceea ce cumperi de fapt când adopți un agent.

O notă despre vocabular. Componentele principale numite aici sunt ceea ce folosește agentul ca să știe, să acționeze, să fie ținut în frâu, să se extindă, să se integreze, să-și amintească și să delege. Testul pentru statutul de componentă principală e convergența: un mecanism e componentă principală atunci când fiecare coding agent major îl livrează ca pachet distinct și configurabil, chiar dacă implementările diferă substanțial. Permisiuni / Sandbox trece testul pe jumătatea stratului de decizie la toți agenții majori; jumătatea de enforcement la nivel de OS e convergentă ca prezență, dar divergentă ca postură, cu posturile vendorilor catalogate în secțiunea de mai sus. Componenta principală Memory are aceeași formă pe a doua lui jumătate. Telemetria nu a trecut încă linia convergenței și rămâne un strat de control în jurul componentelor principale. Când va converge următorul mecanism - candidatul de urmărit e event-push-ul de observabilitate - lista va crește din nou. Capitolul ăsta e primul catalog de convergență; Capitolul 3 e al doilea.

Context window. Tool-uri. Permisiuni / Sandbox. Skill-uri. Plugin-uri. MCP. Memory. Subagenți. Plus harness-ul, ca runtime care le organizează. Asta e lista de azi. Setul e deschis; așteaptă-te să crească. Următoarea componentă principală va intra în listă exact cum a intrat Memory: când apare convergența, nu înainte.

Când apare următorul coding agent în marketplace, trimestrul viitor, grila de evaluare e deja aici. Cât de mare e context window-ul și cum îl gestionează agentul sub presiune? Ce tool-uri sunt disponibile și cum sunt constrânse? Ce model de permisiuni livrează - reguli allow/ask/deny, clasificator auto-mode - și ce sandbox de OS are by default? Cum sunt implementate skill-urile - always-loaded sau activate la detecție? Există un marketplace de plugin-uri și crește? Vorbește MCP, și cât de bună e integrarea MCP? Citește un fișier de memorie partajat de echipă la începutul sesiunii? Menține vreo memorie învățată, scrisă de agent, de la o sesiune la alta? Cum expune subagenții - și e dispatch-ul în paralel o operație de primă clasă sau o idee adăugată ulterior?

Nouă întrebări azi, pe opt componente principale - Memory primește două; mâine vor fi mai multe. Îți spun aproape tot ce ai nevoie ca să compari agentul nou cu cel pe care îl folosești acum.

Capitolul următor: ce se întâmplă când îndrepți un agent spre sursa altuia. Anatomia pe care tocmai am descris-o devine foarte reală, foarte repede.