Numește rezultatul înaintea tehnologiei
O echipă vrea să transforme cererile primite în răspunsuri utile. Înainte să aleagă un agent, ar trebui să precizeze ce înseamnă util: răspuns complet, sursă identificabilă, informații lipsă semnalate și un pas următor clar. Acesta este un exemplu ipotetic, nu un rezultat de proiect. Dacă sarcina nu poate fi descrisă și evaluată, eticheta de agent nu o face mai clară. Poate doar să ascundă neînțelegerea sub o interfață convingătoare.
Când traseul este cunoscut
Anthropic distinge fluxurile cu pași predefiniți de agenții care aleg dinamic pașii și uneltele. Pentru exemplul nostru, clasificarea cererii, căutarea într-o sursă stabilită și redactarea unei propuneri pot forma un flux ușor de urmărit. Un om poate verifica propunerea înainte de trimitere. Întrebarea practică este dacă apare o situație importantă pe care această succesiune nu o poate trata, nu dacă un flux pare suficient de avansat.
Când următorul pas trebuie descoperit
Să presupunem că cererile sunt foarte diferite, iar informația necesară devine evidentă numai după prima verificare. Un agent ar putea alege ce sursă să consulte în continuare sau ce întrebare să întoarcă utilizatorului. Valoarea propusă este adaptarea parcursului. Pentru a o evalua, echipa ar trebui să observe cazurile în care alegerea dinamică produce un răspuns mai bun decât traseul fix și cazurile în care adaugă ocoluri inutile.
Definește limitele ca parte a produsului
Microsoft recomandă nivelul de complexitate care îndeplinește cerințele, luând în calcul costul și timpul. Într-un experiment, acestea pot deveni întrebări concrete: câte verificări sunt acceptabile, ce poate consulta sistemul și în ce moment cere ajutor? Separă pregătirea unui răspuns de dreptul de a-l trimite. Înregistrează motivul opririi și informațiile lipsă. Aceste alegeri fac comportamentul inteligibil pentru persoana care folosește produsul, nu doar pentru echipa tehnică.
Compară variantele pe aceeași sarcină
O evaluare utilă ar putea pune un apel simplu, un flux și un agent în fața acelorași exemple. Criteriile propuse: răspuns corect și complet, informații inventate, intervenții umane, cost și timp până la rezultat. Include și cereri neclare sau imposibil de rezolvat cu datele disponibile. Fără o asemenea comparație, mai mulți pași pot părea progres doar fiindcă sunt vizibili. Arhitectura merită extinsă când îmbunătățirea observată justifică efortul de operare și întreținere. O comparație repetată după schimbări arată și dacă o versiune nouă păstrează avantajul pe care echipa l-a observat inițial.