De ce se pierd deciziile luate în chaturile cu AI și unde să le păstrezi

Deciziile luate într-o conversație cu ChatGPT sau Claude se pierd pentru că un chat nu are stare. Nimic din el nu marchează un rând ca „asta am decis”, nimic nu leagă acel rând de munca pe care o afectează, iar un chat nou pornește gol. Soluția e ca AI-ul să noteze decizia acolo unde trăiește munca, ca o evidență scurtă cu motivele ei, iar următoarea sesiune să citească aceste evidențe înainte să acționeze.

Noi facem Weft. Informațiile despre alte produse provin din paginile lor oficiale, verificate pe 27 octombrie 2026. Ideea că un fir de discuție „nu are stare” vine din articolul Hypertask despre firele din Slack. Ghidul de față o aplică la chaturile cu AI.

De ce dispar deciziile luate cu ChatGPT sau Claude?

Petreci patruzeci de minute cu un asistent cântărind doi furnizori de baze de date, două modele de preț sau două feluri de a structura un API. Te oprești la unul. Raționamentul e bun, asistentul e de acord, iar tu treci la următorul lucru.

O săptămână mai târziu, concluzia e tot în acel chat, undeva deasupra altor două sute de mesaje. Un chat nou nu știe nimic despre ea. Un coleg n-a văzut-o niciodată. Iar dacă a doua zi deschizi alt client AI, de exemplu un agent de programare în terminal, acel client pornește de la zero și s-ar putea să-ți propună vesel exact varianta pe care ai respins-o.

Nu e o problemă de disciplină. O conversație e o succesiune de mesaje. Nu are un câmp pentru „decis”, nici proprietar, nici legătură cu o sarcină și nici vreun mod de a spune „asta a înlocuit ce am spus marți”. O întrebare decisă și una abandonată arată la fel odată ce au dispărut în sus.

Nu rezolvă deja memoria chatului asta?

Nu pentru treaba asta. Mulți asistenți își pot aminti acum lucruri despre tine de la un chat la altul, iar asta e util pentru preferințe și context general. Dar acea memorie aparține unui singur produs și unui singur cont. E scrisă ca s-o folosească acel asistent, nu ca o evidență pe care un om s-o poată revizui rând cu rând, iar alt client AI nu o poate citi. Nici nu spune despre ce sarcină era o alegere sau ce alegere anterioară a înlocuit.

Un jurnal de decizii are alte cerințe. Trebuie să poată fi găsit de oamenii și agenții care lucrează la proiect, să poată fi citit de orice client AI preia munca mai departe, să fie legat de acea muncă și să fie onest cu istoria: când o decizie se schimbă, cea veche ar trebui să rămână vizibilă, cu motivul pentru care a fost înlocuită.

Ce contează ca o decizie care merită înregistrată?

Înregistrează o alegere atunci când cineva ar fi putut alege în mod rezonabil altfel și alegerea va modela munca de mai târziu. Exemple bune:

• Alegerea unui instrument, furnizor sau unei biblioteci în locul alteia.
• Renunțarea intenționată la ceva („fără program de recomandări trimestrul ăsta”).
• Stabilirea unei reguli pe care munca trebuie s-o respecte („toate prețurile afișate cu TVA inclus în UE”).
• Schimbarea unei alegeri anterioare, cu motivul.
• O lecție învățată pe pielea ta („nu rula migrarea în timpul programului de lucru”).

Nu înregistra:

• Idei pe care le-ai lansat și nu le-ai adoptat.
• Pașii muncii în sine (aceia își au locul în sarcină și în rezultatul ei).
• Orice cu care omul n-a fost încă de acord, dacă nu e marcat clar ca propunere.
• Fapte pe care oricine le poate căuta din nou într-un minut.

Un test util: dacă o sesiune AI nouă ar fi pe punctul să anuleze această alegere, ai vrea să se oprească și să citească de ce? Dacă da, înregistreaz-o.

Cum arată o evidență bună a unei decizii?

Păstreaz-o scurtă și păstrează motivele. Formatul de mai jos e o versiune ușoară a MADR (Markdown Architectural Decision Records), pe care o folosește instrumentul record_decision din Weft:

Titlu:           Încărcarea fișierelor: object storage, nu baza de date
Rezultat:        Fișierele încărcate merg în object storage; baza de date păstrează
                 doar cheia fișierului și metadatele.
Status:          accepted
Context:         Utilizatorii atașează fișiere de până la 50 MB. Păstrarea lor în
                 baza de date ar face backupurile lente și mari.
Variante:        1. Object storage  + ieftin, backupurile rămân mici
                                    - încă un serviciu de configurat
                 2. Coloană în BD   + un singur loc pentru tot
                                    - backupurile cresc cu fiecare încărcare
Consecințe:      Avem nevoie de URL-uri semnate pentru descărcări.
                 Ștergerea unei sarcini trebuie să-i șteargă și fișierele.
Revizuiește când: Avem nevoie să căutăm în conținutul fișierelor.
Sarcină:         Încărcarea fișierelor

• Titlul numește decizia, ca s-o poți găsi parcurgând lista.
• Rezultatul e o singură propoziție pe baza căreia poate acționa un nou venit.
• Contextul e ce era adevărat la momentul respectiv. E partea care dispare prima din memorie.
• Variantele listează doar ce a fost cântărit efectiv, nu alternative inventate ulterior.
• Consecințele includ dezavantajele pe care le-ai acceptat, ca nimeni să nu le „descopere” mai târziu ca buguri.
• Revizuiește când spune ce ar face alegerea greșită.

Cum păstrează Weft evidența unei decizii?

Weft e un panou de sarcini la care clienții tăi AI ajung prin MCP, la https://letsweft.com/api/mcp. Trei dintre cele 32 de instrumente ale lui se ocupă de decizii:

• record_decision primește un titlu și un rezultat, plus context, până la cinci variante cu avantaje și dezavantaje, consecințe și condiția în care trebuie revizuită. Poate fi legată de o sarcină (taskId) sau de un proiect. Evidențele sunt imuabile: ca s-o schimbe, AI-ul înregistrează o decizie nouă, cu supersedesId spre cea veche, iar evidența veche rămâne, marcată ca înlocuită.
• get_context întoarce deciziile și lecțiile în vigoare din spațiul de lucru, cele mai noi primele, împachetate într-un buget de tokeni (implicit 800 de tokeni). Poate fi restrâns la un proiect sau la o sarcină. Fiecare rând are data, o decizie înlocuită nu apare niciodată, iar rândurile care n-au încăput sunt numărate, nu ascunse.
• get_task_history în modul decisions listează fiecare decizie înregistrată despre o sarcină, inclusiv verdictele de revizuire și motivele lor.

record_decision are și o a doua utilizare: transmiterea unui verdict dat de om în conversație despre munca ce așteaptă revizuirea lui (acceptat, de refăcut, abandonat sau amânat). Descrierea instrumentului îi spune AI-ului că aici e mesagerul, nu cel care decide, așa că nu trebuie să-l folosească niciodată ca să-și accepte propria muncă.

Pentru că evidențele nu sunt niciodată editate pe loc, istoria rămâne onestă. Dacă schimbi furnizorul în martie, decizia din ianuarie e tot acolo, marcată ca înlocuită, iar evidența din martie spune de ce.

Cum îi cer AI-ului meu să înregistreze deciziile?

Conectează Weft la clientul tău AI, apoi lipește o instrucțiune ca aceasta la începutul unui chat sau în instrucțiunile personalizate ori în fișierul de proiect al clientului, dacă are așa ceva:

Când facem o alegere reală în acest chat (alegem o variantă în locul alteia,
renunțăm la ceva sau schimbăm o alegere anterioară), înregistreaz-o în Weft cu
record_decision înainte să mergem mai departe:
- title: decizia, numită în câteva cuvinte
- outcome: alegerea, într-o singură propoziție
- context: ce era adevărat și a impus alegerea
- options: doar variantele pe care chiar le-am cântărit, cu avantaje și dezavantaje
- consequences: ce urmează, bune și rele
- confirmation: când ar trebui s-o revizuim
- taskId sau project: sarcina sau proiectul la care se referă
Dacă schimbă o decizie anterioară, trimite supersedesId în loc să editezi.
Nu înregistra discuții de complezență, presupuneri sau lucruri cu care n-am fost de acord.
Dacă nu m-am angajat încă, folosește statusul "proposed".
La începutul oricărei munci netriviale, apelează întâi get_context și spune-mi
ce decizii anterioare se aplică.

Conectarea durează un minut. În ChatGPT, Weft e o aplicație publicată în directorul de pluginuri, disponibilă pe orice plan, inclusiv Free (configurare). În Claude Code e o singură comandă (configurare). Claude.ai și Claude Desktop îl adaugă ca un conector personalizat. Autentificarea e prin OAuth în browser, așa că nu ai nicio cheie de copiat, iar Weft emite refresh tokenuri, deci clientul își reînnoiește singur autentificarea. Paginile de configurare pentru alți clienți, inclusiv Cursor și Codex, sunt în documentație.

Ce se întâmplă când a doua zi trec de la ChatGPT la Claude Code?

Iată cazul pentru care e construită instrucțiunea.

1. Luni planifici o funcție în ChatGPT. Decizi să stochezi încărcările în object storage, nu în baza de date, iar ChatGPT apelează record_decision cu contextul, ambele variante și consecințele, legată de sarcina „Încărcarea fișierelor”.
2. Marți deschizi Claude Code în repozitoriu. Dacă nu l-ai conectat încă: claude mcp add --transport http weft https://letsweft.com/api/mcp.
3. Îi ceri să preia sarcina cu încărcările. Înainte să scrie cod, apelează get_context pentru acea sarcină sau get_task_history în modul decisions și primește înapoi evidența de luni.
4. Construiește pe object storage în loc să redeschidă întrebarea. Dacă găsește un motiv real pentru care alegerea e greșită, poate propune o decizie nouă care o înlocuiește pe cea de luni, iar tu decizi.

Ambii clienți citesc același panou și aceleași decizii, pentru că evidența trăiește în Weft, nu în vreunul dintre chaturi. Fiecare conexiune OAuth e un actor separat, iar panoul arată numele cu care s-a înregistrat fiecare client, așa că poți vedea ce conexiune a creat ce sarcină. Pentru rularea mai multor agenți pe un singur panou fără ciocniri, vezi mai mulți agenți AI, un singur panou.

Unde ar trebui să ajungă deciziile din ChatGPT?

Patru locuri obișnuite, comparate după ce are nevoie un jurnal de decizii:

Ideea nu e că chatul sau documentele ar fi rele. Chatul e locul unde gândești. Decizia trebuie copiată din chat în ceva cu stare, în momentul în care e luată, de partea care e deja în conversație: AI-ul.

Înlocuiește asta documentația sau wikiul nostru?

Nu. Weft nu are documente sau wiki și nici nu încearcă să fie așa ceva. Explicațiile lungi, ghidurile de onboarding și documentele de design își au locul în instrumentul tău de documentație. O evidență de decizie e intenționat mică: o alegere, motivele ei și ce a înlocuit-o. Dacă echipa ta ține deja evidențe de decizii într-un wiki și fiecare client AI pe care îl folosești îl poate citi, s-ar putea să fie de ajuns. Weft e util când deciziile se iau în chaturi cu AI, iar următorul cititor e adesea tot un AI. Dacă iei în calcul Notion pentru asta, vezi alternative la Notion pentru sarcini cu AI.

Alte două limite, spuse cinstit. Weft nu-ți citește chaturile: o decizie e înregistrată doar când AI-ul apelează record_decision, de aceea contează instrucțiunea de mai sus. Iar AI-ul poate judeca greșit ce contează ca decizie, așa că citește din când în când get_context și înlocuiește ce a greșit.

Cât costă?

Înregistrarea și citirea deciziilor merg pe planul Free, care include 50 de sarcini active și 200 de apeluri de instrumente AI pe lună. Fiecare apel record_decision sau get_context se numără ca un apel. Pro costă 7,87 € pe loc pe lună sau 66,55 € pe loc pe an, cu TVA inclus, cu sarcini și apeluri nelimitate (prețuri). Weft nu are credite AI: gândirea se petrece în propriul tău client AI, iar Weft doar păstrează panoul și evidențele lui.

Nu pot să-i cer pur și simplu lui ChatGPT să rezume deciziile la sfârșitul unui chat?

Poți, și ajută. Dar rezumatul trăiește tot în acel chat sau unde îl lipești. Nu e legat de sarcină, alt client AI nu-l poate citi, iar când decizia se schimbă nu rămâne nicio evidență a ce a înlocuit. Înregistrarea fiecărei decizii în momentul în care e luată evită toate trei problemele.

Va înregistra AI-ul decizii fără să i se ceară?

Descrierea instrumentului record_decision îi spune AI-ului să-l folosească ori de câte ori utilizatorul face o alegere reală în conversație, așa că unii clienți o vor face. Nu te baza pe asta. Instrucțiunea lipită o face explicită și poți oricând să spui „înregistrează decizia asta”.

Poate fi editată o decizie dacă a fost înregistrată greșit?

Nu pe loc. Evidențele sunt imuabile. Înregistrează o decizie corectată, cu supersedesId spre cea greșită. Evidența veche rămâne, marcată ca înlocuită, iar get_context nu o mai afișează.

Au deciziile nevoie de o sarcină?

Nu. O decizie poate fi legată de o sarcină, de un proiect sau de niciunul. Legarea de o sarcină înseamnă că get_task_history o arată lângă acea muncă, iar get_context poate fi restrâns la ea.

E același lucru cu memoria de lucru din Weft?

Nu. Memoria de lucru (notițe scurte învățate) e o funcție Pro separată. Evidențele de decizie vin din record_decision, iar codul nu le restrânge la Pro.

Ce fac dacă folosesc mai mult de un client AI?

Acesta e motivul principal să faci asta. ChatGPT, Claude Code, Cursor sau Codex conectați la același spațiu de lucru Weft citesc toți aceleași decizii prin get_context, așa că al doilea client nu redeschide întrebările pe care primul le-a închis.