Am realizat pentru prima dată că „dificultățile din era agenților AI nu se află în IQ”, într-un accident de plată foarte obișnuit.
O echipă a creat un serviciu de agenție, ajutând utilizatorii să execute automat un set de strategii: monitorizarea pieței, plasarea de comenzi în etape și reducerea pozițiilor atunci când se întâlnesc condiții de risc. Rezultatele au fost bune, așa că s-au hotărât să transforme perioada de probă gratuită în una plătită: abonament lunar + comision pe rezultat.
În ziua lansării a explodat.
Nu a fost atacat, nu a fost cădere de sistem, ci o problemă și mai stânjenitoare: utilizatorii întrebau în grup -
„Pe ce bază îmi reții acești bani?”
„Spui că ai terminat, care sunt standardele de finalizare?”
„Spui că m-ai ajutat să economisesc costuri, unde este dovada?”
„Comanda ta de astăzi este complet diferită de stilul precedent, ai schimbat cumva strategia pe ascuns?”
Vezi, aceste probleme nu au legătură cu „cât de inteligent este modelul”, toate se îndreaptă spre același lucru:
Odată ce agenția începe să perceapă taxe, lumea se transformă imediat din 'demonstrarea funcționalității' în 'contract de livrare'.
Dar esența contractului nu a fost niciodată „ce pot face”, ci:
Ce am făcut, cum am făcut, a reușit? Dacă apare o problemă, cine este responsabil, cum se calculează banii?
Aceasta este de asemenea esența pe care vreau să o exprim în această lucrare: Vanry nu ar trebui să fie descris ca un „stack pregătit pentru AI”, ci mai degrabă ca un sistem de **livrare și decontare** care permite agenților să facă afaceri pe termen lung.
Îți voi spune direct: pentru ca agenția să câștige bani, ceea ce trebuie să corecteze mai întâi nu este abilitățile, ci „posibilitatea de a percepe taxe”.
Cercul cripto iubește să prezinte agenții ca fiind viitorul super angajaților, dar angajații care pot fi angajați nu se bazează pe abilități de comunicare, ci pe sistem:
Ce ai livrat (posibilitatea de verificare)?
Care sunt limitele comportamentului tău (posibilitatea de constrângere)?
Cum gestionezi problemele apărute (posibilitatea de corectare)?
Cum se calculează costurile tale (posibilitatea de decontare)?
Cele mai multe produse ale agenților se blochează aici: sunt foarte atrăgătoare, dar când vine vorba de plată, se prăbușesc, iar în final nu rămâne decât să ne întoarcem la „instrumente gratuite/ recompense/ abonați pe termen scurt”, plafonul comercial fiind foarte jos.
Deci, dacă m-ai întreba să rezum poziția @Vanarchain într-o frază, aș spune asta:
Transformă ‘agenția care lucrează’ în ‘livrarea agenției’, transformând ‘livrarea agenției’ în ‘activități economice de decontare’.
Lista de contradicții: După ce agenții încep să perceapă taxe, cele mai frecvente probleme sunt cele trei tipuri de „certuri”.
Multe echipe dau vina pe eșecul perceperii de taxe pe „produsul care nu este realizat bine”. Dar de multe ori nu este o problemă de produs, ci costul de „certuri” te-a distrus.
1) „Spui că ai finalizat, dar eu nu recunosc.”
În lumea agenților, „finalizarea” nu este un limbaj natural, ci o definiție inginerescă.
Fără standarde clare de finalizare, nu poți avea facturare automată, cu atât mai puțin scara de percepere taxe.
2) „De ce este diferit de data trecută?”
Ceea ce este fatal pentru agenție nu este greșeala, ci devierea comportamentală: același utilizator, aceleași preferințe, după câteva zile pare că s-a schimbat cu o altă persoană.
Aceasta va distruge direct stabilitatea „abonamentelor” - utilizatorii preferă să facă manual, decât să își asume riscuri pe termen lung.
3) „Pe ce bază percepi taxe? Dacă apare o problemă, cine plătește?”
Odată ce se percep taxe, vor apărea controverse. Controversa nu este un lucru rău, rău este că nu există o lanț de dovezi, nu există limite de responsabilitate, nu există o cale de compensație executabilă.
În final, de obicei există doar două rezultate: fie tu pierzi bani și încerci să rezolvi, fie închizi accesul la perceperea taxelor.
Perceperea de taxe transformă toate „problemele blânde” în „facturi dure”. Iar valoarea Vanry constă în faptul că: creează o capacitate fundamentală care permite acestor facturi dure să funcționeze.
Prefer să scriu @Vanarchain ca o linie de producție, nu ca un grup de componente.
Imaginează-ți o afacere de agenție cât mai realistă: executarea externalizată de către agenție.
Nu are nevoie de abilități de a se lăuda pe rețele sociale, trebuie doar să livreze ca o echipă externalizată:
„Fac eu treaba pentru tine, tu plătești, eu ofer confirmarea, dacă apare o problemă, există o soluție.”
Această linie de producție poate fi scrisă brutal în patru propoziții:
A) Mai întâi să stabilim „verificarea”: fără verificare nu există perceperea de taxe.
Livrarea agenției trebuie să fie verificabilă:
Poți verifica pe baza sarcinilor (finalizare o dată), pe baza efectelor (îndeplinirea obiectivelor), pe baza riscurilor (activarea protecției).
Aici avem nevoie de un „proces de livrare structurat”, altfel va trebui mereu să ne bazăm pe explicațiile asistenței clienți.
În această poziție, Flows este mai mult un pistol de cuie care transformă livrarea în pași.
Acțiunile pot fi descompuse în pași, astfel încât să ai puncte de verificare; cu puncte de verificare, poți avea puncte de facturare; cu puncte de facturare, poți discuta despre taxe pe scară largă.
B) Apoi să rezolvăm „serviciile continue”: abonamentele necesită stabilitate, nu geniu.
Abonamentele se tem cel mai mult că azi sunt ca experții, iar mâine ca începătorii. Esența serviciilor continue este: contextul pe termen lung nu trebuie să se întrerupă, comportamentul nu poate fi lăsat la voia întâmplării.
myNeutron este ușor de înțeles aici: este mai mult un „dosar de client + context pe termen lung”.
Nu este pentru a impresiona memoria, ci pentru a reduce variația calității livrării - cu cât variația este mai mică, cu atât utilizatorii au mai mult curaj să se aboneze și să ofere permisiuni.
C) Apoi să ne ocupăm de „certuri”: controversele vor apărea, trebuie să ai dovezi sau să plătești.
Odată ce se percep taxe, vor apărea controverse:
„De ce faci asta?” „De ce percepi taxe pe această bază?” „De ce este diferit de data trecută?”
Aceasta nu este o problemă filozofică, ci o problemă de costuri post-vânzare.
Kayon devine valoros în această poziție:
Nu este doar explicabilă, ci aduce controversele de la „certuri verbale” la „materiale verificabile”, făcând returnările și împărțirea responsabilităților controlabile.
Poți să o înțelegi ca: reducerea timpului de certuri, reducerea probabilității de returnare, reducerea costurilor de „compensare haotică pentru a calma litigiile”.
D) În final, cum se pune banii în aplicare: decontarea fără confirmare este echivalentă cu a nu deconta.
În lumea agenților, singurul lucru care poate face echipele, finanțele și operațiunile să tacă este: confirmarea.
Dacă există o confirmare, atunci se poate face reconcilierea; dacă reconcilierea este posibilă, atunci plata este stabilă; dacă plata este stabilă, afacerea poate crește.
Plata/decontarea nu este doar o adăugare, ci ultima etapă a liniei de producție: „aprobarea”.
Agenția nu trebuie să funcționeze ca un portofel UX, trebuie să deconteze ca un sistem, să emită confirmări ca un sistem și să fie urmăribilă ca un sistem.
Majoritatea oamenilor care văd agenții AI întreabă: „Ce poate face?”
Vreau să întreb: „Are curajul să perceapă taxe? Poate să perceapă stabil?”
Deci, când mă uit la Vanry, mă preocupă mai mult:
Poate livrarea să fie verificată (fără a depinde de certuri)?
Pot fi reconciliate costurile (fără a depinde de muncă manuală)?
Pot fi dovedite controversele (fără a depinde de emoții)?
Poate fi corectată și executată o problemă (fără a depinde de rugăciuni)?
Acestea nu sună deloc romantic, dar determină dacă agenții pot intra în producție, dacă pot fi angajați pe termen lung, dacă pot percepe stabil taxe.
Concluzie:
Până la urmă, nu îmi fac griji că agenții nu sunt suficient de inteligenți, ci că, odată ce încep să ia decizii în locul oamenilor, să gestioneze fonduri, lumea se va transforma imediat în „contract de livrare”. Atunci, cei care vor supraviețui nu vor fi cei mai buni povestitori ai viitorului, ci infrastructura care poate rezolva problemele reale: **cum se face verificarea, cum se aliniază criteriile, cum se dovedesc controversele, cum se execută compensațiile, cum se reconcilierează confirmările** - acestea decid dacă agenția poate scala, dacă poate deveni cu adevărat un serviciu.
Deci, nu consider @Vanarchain un „alt discurs AI”, ci mai degrabă o privire asupra ordinii fundamentale a economiei agenților: să transformăm „ce se poate face” în „livrare”, să transformăm „livrarea” în „posibilitate de decontare”, să transformăm „posibilitatea de decontare” în „posibilitatea de scalare”. Dacă acest proces este realizat, $VANRY nu se bazează pe emoții pe termen scurt, ci pe drumul agenției de la jucărie la standardul industriei.
