Asistenți agentici: integrarea sigură a Gmail și Calendarului

Declarația mea: construirea asistenților agentici siguri și utilizabili care acționează pe calendare, Gmail și aplicații conectate necesită proiectarea unui runtime centrat pe permisiuni, separarea planificării de acțiune și încorporarea fluxurilor de audit și revenire în stratul de execuție încă din prima zi. Acest articol oferă o listă de verificare de inginerie concisă și prompturi care pot fi utilizate pentru a ajunge acolo.

PROIECTAREA PERMISIUNILOR PENTRU ASISTENȚI AGENTICI

Începeți cu OAuth per utilizator și scope-uri cu privilegiu minim. Utilizați OAuth legat de utilizator în loc de un cont de serviciu partajat, cu excepția cazului în care un administrator cere în mod explicit delegarea domeniului. Documentația Google privind scope-urile granule este baza; mapați fiecare capacitate a agentului la un singur scope OAuth și documentați intenția în format lizibil pentru oameni pentru acel scope. Păstrați token-urile departe de prompturi. Stocați-le într-un vault și injectați acreditivii doar la momentul apelului într-un serviciu de execuție care aplică politica.

Am observat că echipele care tratează permisiunile ca experiență utilizator (UX) a produsului, cu ecrane clare de consimțământ și previzualizări ale scope-urilor, primesc mult mai puține bilete de suport. O problemă cu care ne-am întâlnit este proliferarea token-urilor din logică de reînnoire naivă; centralizați reînnoirea și rotiți token-urile de reînnoire în mod regulat.

PLANIFICARE VERSUS ACȚIUNE

Împărțiți asistentul în două: un planificator și un actuator. Planificatorul produce un plan de acțiune discret: citirea firurilor recente, propunerea a două ore pentru întâlniri, redactarea unui email de schiță. Actuatorul execută doar după o verificare a politicii și, pentru acțiuni sensibile, un pas de confirmare umană. Acest model împiedică modelul să improvizeze operațiuni privilegiate și face autorizarea audibilă.

Compromis practic: latență mai mare pentru aprobarea umană versus risc mai mic. Pentru multe acțiuni de calendar și email, o pauză de 30 până la 60 de secunde cu un om în procesul de aprobat este acceptabilă. Pentru sarcini cu frecvență mare, aprobările pe loturi funcționează mai bine decât clicurile per acțiune.

TESTE, JURNALIZARE ȘI RECUPERARE

Fiecare acțiune trebuie să producă o intrare de audit imuabilă care să conțină intenția solicitată, output-ul planificatorului, decizia politică, apelul actorului și răspunsul API returned. Păstrați un format de comandă reexecutabil astfel încât să puteți reexecuța și reveni. Oferiți o opțiune de anulare cu un singur clic pentru ultimele N acțiuni și un flux de recuperare care creează evenimente compensatorii, de exemplu, anularea unui eveniment și trimiterea unui follow-up corector.

Am observat că limitările la nivel de prompt eșuează fără un motor de politici extern. În practică, modelele vor sugera schimbări care par plauzibile dar încalcă politica. Un poartă de execuție care refuză orice scriere când încrederea este sub un prag calibrat reduce aceste incidente.

LISTA DE VERIFICARE PENTRU PRODUS ȘI INGINERIE

1. OAuth per utilizator cu scope-uri minime și text de consimțământ explicit. 2. Vault pentru token-uri și serviciu de execuție care injectează acreditivii la runtime. 3. Separarea planificatorului de actuator cu verificări ale politicii. 4. Escaladare umană pentru acțiuni sensibile. 5. Jurnale de audit imuabile și format de acțiune reexecutabil. 6. Fluxuri de revenire și compensatorii cu interfețe clare de utilizator.

Legătura UX a produsului cu modelele de flux de lucru descrise în Proiectarea fluxurilor de lucru om-AI și folosiți introducerea privind diferențele agenților în Agenți AI vs chatbots pentru a justifica separarea planificatorului de actuator.

Încercați și voi. Prompturile de mai jos demonstrează output-ul planificatorului versus instrucțiunile sigure ale actuatorului. Așteptați planuri concise de tip JSON din partea planificatorului și confirmări scurte din partea actuatorului.

Acest prompt cere modelului să producă un plan restricționat de ore candidate pentru întâlniri și un raționament; folosiți-l ca planificator. Așteptați 2 până la 3 intervale candidate și un raționament de o propoziție.

Ești un planificator de întâlniri. Utilizatorul are 3 intervale libere astăzi: 10:00 AM, 2:30 PM, 4:00 PM. Returnează exact trei ore candidate pentru întâlniri în format ISO cu un raționament de o propoziție pentru fiecare și o notă de confidențialitate de o linie spunând dacă invitația implică emailuri externe.

Acest prompt este pentru actuator. Se așteaptă un token de confirmare umană și o verificare explicită a politicii înainte de a crea evenimentul.

Actuator: dat fiind token-ul de confirmare umană X și planul planificatorului Y, apelează Calendar.CreateEvent cu câmpurile {start,end,attendees,summary} doar dacă policy_check(policy_id:calendar_write) returnează pas. Dacă policy_check eșuează, returnează codul de eșec și acțiunea umană necesară.

Un contraargument este că controalele stricte încetinesc adoptarea. Estimarea mea este că atunci când echipele impun aceste modele, retenția utilizatorilor devreme se îmbunătățește pentru că încrederea crește, chiar dacă activarea inițială este mai lentă. Compromisul este clar: introducerea rapidă fără aceste controale creează riscuri măsurabile și costuri de remedie mai mari.