Short Friday, o analiză fiscală cu zece livrabile — cum am pus o echipă întreagă de agenți AI la treabă

Vineri, înainte de weekend

Era o vineri ca oricare alta, din alea în care mintea e deja pe jumătate în weekend. Numai că, exact în ziua precedentă, în Monitorul Oficial nr. 543 din 2 iulie 2026 apăruse OPANAF 828/2026 — ordinul care rescrie din temelii modul în care se întocmește, se prezintă și, mai ales, se transmite către autorități dosarul prețurilor de transfer. Actul pe care îl înlocuiește funcțional, OPANAF 442/2016, avea deja aproape zece ani. În fiscalitatea românească, zece ani înseamnă o eră geologică.

Norocul meu a fost că nu am pornit de la zero. Comunitatea de pe LinkedIn discutase deja principalele modificări încă de la lansarea proiectului în secțiunea de transparență decizională a ANAF, de pe 10 iunie 2026, iar imediat după publicarea în Monitorul Oficial cineva a postat deja extrasul oficial. Așa că, atunci când m-am uitat peste text, aveam deja contextul comunității, nu doar litera ordinului.

În acel context, am făcut ce mi s-a părut firesc: am trimis către CFO un mail scurt cu sumarul actualizărilor și documentul oficial integral atașat. Și am închis, din reflex profesional, cu o frază pe care o punem cu toții mecanic la finalul unui mail: „Rămân disponibil pentru discuții.” Zâmbet, trimite, înapoi la treabă.

Discuția de la prânz și lista care crește

Pe la prânz, CFO-ul trece direct pe la biroul meu. Nu un mail, nu un telefon — față în față, cu ușa deschisă și cafeaua în mână, exact genul de discuție relaxată în care fiecare idee o naște firesc pe următoarea. „Ionuț, am văzut și eu comunicatul Ministerului Finanțelor despre noile reguli de prețuri de transfer — ministrul vorbește chiar de modificări «seismice». Mă gândeam că am avea nevoie de ...”

A pornit de la miezul problemei și, de acolo, lista a crescut de la sine. Fiecare „și ar mai fi util să…” mai adăuga un document. Pe măsură ce vorbea, numărăm în gând:

• O analiză completă a noului ordin — nu de dragul unui rezumat, ci pentru un gap analysis onest: unde stă dosarul nostru de prețuri de transfer azi, sub regulile din 2016, și ce trebuie de fapt să livrăm în 2027. Comparație integrală, articol cu articol, cu checklist de obligații noi, plan de acțiune și riscuri.
• Un brief pentru managementul local — ceva scurt, de decizie, pe care un om ocupat să-l citească în cinci minute și să înțeleagă ce se schimbă și ce trebuie hotărât.
• Un draft de email în engleză pentru HQ — „e util să informăm din timp și echipa de taxe de la grup”, ca ei să știe ce li se cere: Master File actualizat, date de la partea-mamă.
• O agendă de discuție cu consultanții fiscali și auditul — „să integrăm și punctele pe care oricum le discutăm cu ei”, ca întâlnirea să fie eficientă, nu o improvizație.
• Un material pentru newsletter-ul intern — „și colegii ar trebui să afle”, pe înțelesul celor din finance, operations, procurement, nu doar al specialiștilor.
• Un infografic de o pagină — „ceva de avut la îndemână”, de deschis rapid când vrei un refresh al punctelor-cheie.
• O prezentare de vreo 10 slide-uri — „o să vină și momentul să prezentăm board-ului”.
• O traducere în engleză a întregului OPANAF — „avem varianta Google Translate, dar parcă nu e de încredere pentru un act normativ; sigur te descurci tu cu un prompt pentru un AI”.

Și, încheie prietenește: „Știu că e început de weekend și nu vreau să-ți răpesc short friday, dar poate până luni după-masă reușim să avem documentele.”

Opt cereri. Și, cum ideile bune vin exact când nimeni nu ți le cere, mi-am mai adăugat una, pentru mine: un podcast audio pe care să-l ascult în metrou pe drumul spre birou de luni dimineață, ca să reanalizez punctele-cheie și noile direcții fără să deschid un document. Iar infograficul, la o adică, îl voiam în două forme — una de prezentare și una web. Total: zece fișiere. Până luni. În timpul unui short friday.

Un orchestrator, nu un om care copiază prompturi

Primul instinct a fost cel al oricui: să deschid un chat AI și să cer, pe rând, fiecare document. M-am oprit însă la timp. România e o țară cu modificări legislative frecvente, iar acest tip de pachet — analiză, briefuri, traducere, prezentare — nu e un caz izolat; aproape sigur voi avea nevoie de el din nou, la următoarea schimbare de normă. Nu voiam să salvez fiecare prompt care a funcționat într-o arhivă pe care apoi s-o răscolesc peste șase luni, căutând varianta bună.

Așa că am ales să standardizez tot procesul. În loc de zece conversații ad-hoc, construiesc o singură dată un agent care poate replica întregul flux ori de câte ori am nevoie: un orchestrator care face întâi analiza grea — completă, validată — și apoi delegă către o echipă de subagenți specializați, câte unul pentru fiecare tip de livrabil. Data viitoare, doar încarc noul ordin și pornesc procesul.

Merită lămurită aici o confuzie pe care am avut-o și eu la început: „agenți” versus „skills” nu e o alegere de tip ori-ori. Nu sunt două soluții concurente pentru aceeași problemă — fac lucruri diferite și designul bun le folosește pe amândouă, stratificat.

Skill-urile sunt cunoașterea; subagenții sunt forța de muncă. Un skill nu poate produce în paralel cinci documente; un subagent nu-ți ține, reutilizabilă, cunoașterea de domeniu. Fiecare acoperă golul celuilalt.

În cazul meu, baseline-ul de prețuri de transfer, terminologia ANAF, formatul de citare a articolelor și tokenii de brand au devenit skills — referință pasivă, pe care o trage oricine are nevoie de ea. Iar cei care produc efectiv fiecare deliverable, fiecare în contextul lui izolat, au devenit subagenți. Un al treilea strat, permanent, stă într-un fișier CLAUDE.md: cine sunt (contabil senior, fiscalitate RO), convențiile de foldere, brandul. Se încarcă automat la fiecare sesiune, așa că nu-l repet în fiecare prompt.

Cum se construiește, pas cu pas, în Claude

Partea asta merită detaliată, fiindcă oricine o poate reproduce. Un „agent” nu e modelul în sine, ci sistemul din jurul lui: modelul e creierul, agentul e învelișul care îi dă unelte, o buclă de execuție și permisiuni. Un subagent e o instanță separată pe care agentul principal o pornește pentru o sarcină delimitată — cu propriul system prompt, propria fereastră de context și propria listă de unelte. În Claude, tot procesul se așază în câteva fișiere, într-un folder de proiect. Iată-l pas cu pas.

Pasul 1 — un folder la care Claude are acces

Totul pleacă de la un folder de proiect pe care i-l pui la dispoziție. Acolo încarci sursele (ordinul nou, cel vechi, proiectul din transparență) și tot acolo se vor scrie livrabilele. Fără acces la folder, agenții n-au nici de unde citi, nici unde scrie. Structura pe care am folosit-o:

tpd-analysis/
├── CLAUDE.md                 # contextul permanent al proiectului
├── .claude/
│   ├── agents/               # subagenții — un fișier .md fiecare
│   │   ├── research-web.md
│   │   ├── brief-ro.md
│   │   ├── brief-en.md
│   │   ├── draft-consultant.md
│   │   ├── newsletter.md
│   │   ├── infografic-html.md
│   │   ├── prezentare.md
│   │   ├── traducere-ro-en.md
│   │   └── podcast-nlm.md
│   └── skills/               # cunoașterea reutilizabilă
│       ├── tpd-domain/SKILL.md
│       ├── brand-design/SKILL.md
│       └── citare-opanaf/SKILL.md
├── surse/                    # AICI încarci OPANAF nou + vechi + proiect
└── output/                   # analiza + cele 10 livrabile

Pasul 2 — contextul permanent (CLAUDE.md)

Fișierul CLAUDE.md din rădăcina proiectului se încarcă automat la fiecare sesiune. Acolo pui ce e valabil mereu: cine ești (contabil senior, fiscalitate RO), domeniul, convențiile de foldere, brandul. Nu-l repeți în fiecare prompt — e memoria de fundal a proiectului.

Pasul 3 — cunoașterea reutilizabilă (skills)

Un skill e un folder cu un fișier SKILL.md (instrucțiuni) plus, opțional, resurse. Mecanismul-cheie: în context se încarcă doar descrierea skill-ului, iar conținutul complet abia când e invocat. Așa, baseline-ul de prețuri de transfer, formatul de citare a articolelor și tokenii de brand stau la un loc și îi folosesc mai mulți subagenți, fără să-i dublez în fiecare.

Pasul 4 — lucrătorii (subagenții din .claude/agents/)

Fiecare subagent e un simplu fișier .md în .claude/agents/. Are două părți: un frontmatter (între linii de ---) care îi spune sistemului cine e și ce unelte are, și un corp care e chiar system prompt-ul lui. Anatomia unui subagent real, brief-ul de management:

---
name: brief-ro
description: Brief executiv RO pentru management. Rulează
  DUPĂ validarea analizei.
tools: Read, Write
model: fable
---
<rol> Ești redactor de brief-uri fiscale pentru conducerea executivă.
Traduci analiza tehnică într-un material de decizie clar,
fără să pierzi precizia fiscală. </rol>
<context> Citești din output/analiza_validata.md (sursă de adevăr, deja filtrată pe mari
contribuabili și validată de mine). Nu reanalizezi ordinul. Brieful tău devine
la rândul lui sursă pentru brief-en și infografic, deci trebuie să fie complet
și corect de sine stătător. </context>
<competențe> - Sintetizezi pentru un cititor non-tehnic, dar exact pe termene și praguri.
- Ierarhizezi: pui obligația de depunere prin SPV și pragul de servicii (scădere
  la 100.000 EUR) sus, ca fiind cele mai importante.
- Formulezi acțiuni și decizii, nu doar descrieri. </competențe>
<sarcina> ~800–1000 cuvinte: context → ce se schimbă →
  impact pe dosar → ce trebuie făcut și până când → decizii solicitate managementului. </sarcina>
<guardrails> - Doar regimul marilor contribuabili. Fără plafoane de mici/mijlocii.
- Trimiteri la articole conform skill-ului citare-opanaf.
- Nu introduce cifre care nu sunt în analiza_validata.md. </guardrails>
<iesire> Scrie în output/01-brief-ro.md. În chat: doar
  3 rânduri rezumat + confirmare. </iesire>

Câmpul description e cel pe care orchestratorul îl citește ca să știe când să delege către acel subagent; tools limitează ce poate face (cel care traduce n-are nevoie de web, cel de research da); iar model alege creierul — pe cel de research și pe brief-uri i-am pus pe un model rapid, iar analiza grea și traducerea legală pe Fable, unde greșelile de terminologie chiar contează.

Pasul 5 — ordinea de procesare

Aici e miezul: subagenții comunică prin fișiere, nu prin context. Fiecare pornește cu context curat, iar singurul canal dinspre orchestrator e textul promptului — deci nu-i pasezi analiza în prompt, o scrii pe disc, iar el primește instrucțiunea „citește fișierul X, scrie rezultatul în Z”. Discul devine memoria partajată, iar fiecare subagent returnează în chat doar o confirmare de trei rânduri, nu tot textul — așa „zgomotul” fiecărui livrabil rămâne pe disc, nu în conversația principală.

Și nu e un fan-out plat de zece. E un graf cu dependențe: brief-ul EN pleacă din brief-ul RO finalizat (altfel divergează), infograficul tot din brief-ul RO, iar traducerea integrală e o ramură paralelă care depinde doar de textul oficial și poate rula odată cu analiza. Ordinea, pe scurt:

surse/opanaf-828-final.pdf
        │
        ├──► [ORCHESTRATOR · Fable] ──► analiza_validata.md  (validare umană ✋)
        │                                      │
        │                                      ├──► brief-ro ──► brief-en
        │                                      │            └──► infografic (web + slide)
        │                                      ├──► agenda-consultanti
        │                                      ├──► newsletter
        │                                      └──► prezentare 10 slide-uri
        │
        └──► [traducere-ro-en · ramură paralelă] ──► OPANAF integral EN

Echipa la treabă — cine ce a produs

Cu analiza validată, echipa s-a pus în mișcare. Fiecare subagent are un rol explicit, o poziție în pipeline, competențe distinctive și un „contract de output” clar — plus un guardrail redundant („exclusiv regimul marilor contribuabili”), peste faptul că oricum citește dintr-un master deja filtrat. Iată maparea completă a celor zece livrabile:

Și, totuși — ce spune OPANAF 828?

Un articol despre metodă ar fi gol fără miezul care a justificat tot efortul. Pe scurt, și strict pentru regimul marilor contribuabili — perimetrul analizei mele — iată ce schimbă noul ordin. Dosarul prețurilor de transfer nu mai e un document „de sertar”, prezentat doar la cerere, ci un livrabil anual depus obligatoriu prin Spațiul Privat Virtual, în 30 de zile lucrătoare de la termenul declarației anuale de impozit pe profit, sub semnătura reprezentantului legal.

Traducerea practică: mult mai multe fluxuri intră în documentare, screening-ul trebuie refăcut ca o matrice „afiliat × categorie de tranzacție”, iar anul fiscal 2026, deja în curs, este primul an documentat pe noile reguli. Motivul reformei, invocat în referatul de aprobare, e alinierea la actualizarea din 2022 a Liniilor directoare OECD și la rezultatele BEPS. Exact genul de schimbare pentru care „până luni” chiar înseamnă că trebuie să începi acum.

Ce am învățat

Echipa a livrat. Dar experimentul m-a lăsat cu câteva lecții care contează mai mult decât cele zece fișiere. Prima: izolarea de context nu e un moft tehnic, e ce face diferența de calitate. Dacă aș fi cerut toate cele zece documente într-o singură conversație, calitatea ar fi scăzut vizibil pe la al cincilea-al șaselea, mai ales când infograficul HTML ar fi vărsat sute de linii de cod în context. Fiecare subagent care pornește curat scrie ca și cum ar fi primul task al zilei.

A doua: puterea vine cu un cost. Fluxurile dense în subagenți pot consuma sensibil mai mulți tokeni decât o sesiune obișnuită — undeva spre 7x, pentru un ciclu cu research plus multe output-uri. Dacă bugetul contează mai mult decât viteza, secvențiezi ce se poate secvenția și paralelizezi doar ramurile independente. Nu tot ce poate rula în paralel merită să ruleze în paralel.

Și a treia, poate cea mai importantă pentru un contabil: munca grea o face echipa de agenți, dar analiza finală și acceptul rămân ale omului. Scriu rândurile astea sâmbătă. Deși pachetul a fost gata încă de a doua zi, complet și impecabil formatat, nu am trimis nimic — nici brief-ul, nici mailul către HQ, nici traducerea. Rezultatele vor pleca mai departe abia după ce voi valida totul pentru corectitudine, cel mai probabil luni. Un prag greșit sau un articol renumerotat într-un dosar de prețuri de transfer nu e o eroare cosmetică; e o expunere.

Nu vreau să hrănesc ceea ce presa a început deja să numească „AI slop” — teancuri de conținut generat automat și trimis mai departe fără ca cineva să-l fi citit cu adevărat. Un document care poartă semnătura mea rămâne responsabilitatea mea, indiferent cine sau ce l-a scris. Agenții mi-au dat înapoi timpul pe care l-aș fi pierdut formatând și traducând; îl investesc exact acolo unde contează — în verificarea conținutului înainte ca el să ajungă la cineva.

Nu am devenit programator și nici nu a fost nevoie. Am devenit ceva mai util pentru un contabil: omul care știe să pună o echipă de agenți la treabă — și, mai ales, să știe că nimic nu pleacă mai departe până când nu verifică, nu validează și nu își pune singur semnătura.

Așa că documentele există de sâmbătă, dar vor ajunge la CFO abia luni — după ce le trec eu prin filtrul final. Toate cele zece fișiere le găsești în arhiva .zip descărcabilă de mai jos — așa cum v-am obișnuit deja, în format editabil, ușor de actualizat / modificat după nevoile fiecăruia.