Undeva în fișa unui client, în mijlocul unei notițe obișnuite despre un apel obișnuit, se află o propoziție ca aceasta: “Bugetul e strâns acum, am convenit să îi contactăm din nou peste două luni ca să revenim asupra subiectului.”
Scrisă o dată. Niciodată recitită. Nu pentru că cineva a uitat că e importantă, ci pentru că nimic din ea nu semăna cu o sarcină. Nu era o intrare în calendar. Nu era un memento. Era doar o propoziție, care făcea ceea ce fac propozițiile din notițe: stătea acolo, tehnic adevărată, funcțional invizibilă.
Voiam să știm dacă sistemul putea sesiza singur așa ceva, fără ca cineva să trebuiască să-și amintească să revină și să transforme manual propoziția într-o sarcină.
Ce am construit de fapt, și ce nu am făcut în mod deliberat
Instinctul cu o funcție de acest fel e să lași AI-ul să se ocupe de tot procesul — să citească notița, să stabilească data, să decidă că e depășit termenul, poate chiar să redacteze urmărirea. În schimb, am separat lucrurile în mod deliberat.
Singura sarcină a modelului este înțelegerea limbajului: să citească notițele recente ale unui client și să recunoască un angajament orientat spre viitor, ceva de genul “revenim peste două luni” sau “îi contactăm din nou după ședința lor de consiliu.” Estimează întârzierea implicită în termeni simpli. Atât. Orice calcul real de date — termenul limită, dacă azi l-a depășit deja — se întâmplă ulterior, în cod obișnuit și determinist. Modelul nu face niciodată calcule și nu ia niciodată decizia finală despre ce e depășit. El citește. Codul decide.
Această separare contează mai mult decât pare. Înțelegerea limbajului este exact genul de sarcină vagă, dependentă de context, la care un model se pricepe. Calculul datelor este exact genul de sarcină la care nu vrei ca un model să improvizeze, nici măcar puțin.
Testul real
Nu ne-am limitat să verificăm dacă endpoint-ul returnează ceva ce pare rezonabil. Am scris o notiță reală pe o fișă reală de client: “…am convenit să îi contactăm din nou peste 2 luni ca să revenim asupra bugetului.” Am apelat endpoint-ul. A extras corect angajamentul, a calculat o întârziere implicită de 60 de zile și a ajuns la un termen limită exact 60 de zile după marca temporală reală a notiței, marcat corect ca nefiind încă depășit.
Mic, și exact asta e ideea. Sistemul nu a avut nevoie să i se spună că există un angajament de găsit. A citit o propoziție pe care o persoană a scris-o pentru sine, nu pentru un formular, și a extras din ea un termen real.
Partea ușor de trecut cu vederea
Notițele din Craft11 pot fi doar adăugate. Nimeni nu le editează, nimeni nu le șterge, nici măcar Stark. Este același principiu care păstrează onestă latura brută a fiecărei fișe: ce ai scris cu adevărat rămâne exact așa cum ai scris. Când a trebuit ulterior să eliminăm notița de test, nu a existat un buton de ștergere la care să apelăm, pentru că nu ar trebui să existe unul. A fost nevoie de o operațiune directă pe baza de date, mai întâi confirmată, apoi anulată imediat.
Pentru noi asta e un mic inconvenient în timpul testării. Este exact același motiv pentru care funcția de detectare a angajamentelor este de încredere: citește text uman real, neschimbat, necurățat, nu o versiune sanitizată a lui.
De ce merită făcut acest lucru, în general
Nimic din toate astea nu înlocuiește un manager de sarcini. Înlocuiește acel mod specific și tăcut de eșec în care singura urmă a unei promisiuni este o propoziție pe care nimeni nu o va reciti vreodată. Sistemul nu are nevoie să scrii altfel, să-ți structurezi notițele sau să-ți amintești să marchezi ceva. Are nevoie doar să notezi ce s-a întâmplat cu adevărat, așa cum ai scrie pentru tine însuți, iar el se ocupă de observat.