Kui me seni UX-ist rääkisime, pidasime tavaliselt silmas toote seda osa, mida disainer oli hoolega lihvinud: kasutajaliidest, nuppude asukohta ja sujuvat onboardingut. See oli inimese kogemus süsteemiga.

See pilt pole aga enam ammugi nii lihtne.

AI-agendid – iseseisvad süsteemid, mis märkavad probleeme, planeerivad tegevusi ja viivad neid ellu – ei suhtle tarkvaraga läbi meie ilusa kasutajaliidese. Kõige parema meelega tegutsevad nad ainult rakenduse API kaudu. Tihtilugu ei näe nad kodulehekülge ega reageeri JavaScriptiga tehtud animatsioonidele. Nende “silmis” on toode täpselt nii hea ja kasutajasõbralik, kui arusaadav on selle API, dokumentatsioon ja autentimise loogika.

API kasutuskogemus on nüüd rohkem kui kunagi varem väga oluline osa toote UX-ist. See pole enam pelgalt arendajate pärusmaa. Agentide jaoks mõeldud “kasutajakogemust” tuleb hakata teadlikult tootearenduse sisse disainima.

Esmamulje, mis ei kujune enam brauseris

Kui kaalusin meie enda ettevõttes AI-agentide viimist OpenAI pealt Gemini arhitektuurile, ei saanud valikul määravaks mitte tehisintellekti nutikus ega isegi hind. Määravaks sai hoopis minu esmakogemus platvormi kasutuselevõtmisel.

OpenAI oli asja lahendanud nii triviaalselt: lood arendajakonto, vajutad “Create API key” ja andmed lendavad. Võttis aega max kaks minutit.

Gemini puhul oli protsess (vähemalt tollal) järgmine: kõigepealt oli vaja GCP arendaja kontot, siis teha uus GCP projekt, otsida menüüst üles API & Services, lülita daseal spetsiifilised API-d sisse ja alles siis sai hakata pusima, et luua mingeidki API võtmeid. See teekond oli koostatud niivõrd ebamugavalt ja bürokraatlikult, et jätsin asja lihtsalt sinnapaika.

Seda teksti kirjutades kontrollisin, kuidas asjad täna käivad ja tõsi – Google on vahepeal süsteemi kõvasti lihtsamaks ja inimsõbralikumaks teinud. Ent otsus oli selleks ajaks juba ammu langenud. Kogu meie integratsioon jookseb endiselt OpenAI mudelil lihtsalt seetõttu, et nendega alustamine takistas kõige vähem tööd. Kõik meie ostetud raha API tokenite eest läheb Open AI-le, lihtsalt selle pärast, et API võtme tegemine oli Gemini puhul liiga tüütu.

See ongi seesama “uus esmamulje”. Pole tähtis, kas uue konto puhul saadetakse ilus tervitusmeil või mitte – kui arendaja (või lausa agent ise) murrab ligipääsude konfigureerimisel piike, lüüakse tihtipeale käega juba kohe alguses.

Tänane API-võtmete haldus kuulub endiselt eelmisesse kümnendisse

Kui me ise Kordonit GRC jaoks kasutame, siis teeme seda väga tihti läbi ai agentide nagu Claude Code. Meie igapäevane loogika on selline: teeme Kordoni rakenduses uue API-võtme, anname selle Claude’ile ette koos baasteadmistega Kordoni API kohta, laseme mudelil asjad korda ajada ja koheselt pärast seda kustutame API-võtme. Kõik need AI platvormid küll ütlevad, et vestluseid ei salvestata aga kuidagi parem tunne on teades, et isegi kui keegi selle API võtme sealt kätte saab, siis see enam ei toimi.

Osa võtmeid elabki meil seega kõigest tunde või päevi. Ja nii peabki. Kui mudelile jagatud autentimisinfo peaks kogemata AI vestluslogidesse vedelema jääma, pole see lihtsalt laiskus, vaid päris reaalne ja mõõdetav turvarisk ettevõttele.

Me saame endale pidevat uute võtmete loomise vabadust lubada ainult seepärast, et süsteemis on uue võtme loomine valutu ja kiire. Igal Kordoni kasutajal saab samaaegselt olla töös palju paindlikke API-võtmeid, ning integratsioonide selgeks eraldamiseks on meil sootuks eraldi agendi- ja botikontod. Kuna API-võtme roteerimine vajab napilt paari nupuvajutust, ei püüa täna enam keegi vabanduseks aastatevanuseid “globaalseid võtmeid” igavesti elusana hoida.

Võrdluseks Pipedrive. Neil on üks paremaid API-sid ja suurepärane dokumentatsioon, aga seal peitub üks murekoht: igal kasutajal saab olla korraga vaid üks API-võti. Kui on vaja see vana võti välja vahetada, tuleb uus võti käsitsi uuendada igal pool – n8n töövoogudes, Zapieri integratsioonides ja kõikjal mujal, kuhu see kunagi kleebitud sai. Kuna võtme roteerimine on lahendatud nii töömahukalt, jäetakse see praktikas tihti lihtsalt tegemata.

See ei olnud suur mure ajal, kui igal tiimil eksisteeris vaid paarkümmend hoolikalt hallatud püsivat integratsiooni. Täna on aga pilt teine. Agendid saavad ja vajavad API-võtmeid igapäevaselt ning võtmeid aina koguneb. Kui nende vahetamine on keeruline, jäävad vanad võtmed aktiivseks keskkondades, kus keegi enam täpselt ei teagi, millele need reaalselt ligipääsu annavad.

Vahepeal arvati pikalt, et API-võtmed on iganenud lahendus ja tulevik kuulub ainult sissejuurutatud OAuth protokollile. Paraku ei toimi OAuth tehisintellekti agentidega kaugeltki sama sujuvalt ja valutult. Pendel on tagasi liikunud – peame programmide ligipääsud ja API-võtmete halduse uuesti läbi mõtlema nii, et need töötaksid ühtmoodi hästi nii agentide, süsteemiintegratsioonide kui ka inimeste jaoks.

Agendid avavad uksed väljaspool ametlikku funktsioonide nimekirja

Kordoni API ja AI-agentidega töötades on selgelt välja joonistunud üks muster: agendid suudavad edukalt ära teha asju, mille jaoks pole tootes veel eraldiseisvaid funktsioone ehitatudki.

Andes agendile tööriistana kaasa Kordoni skill’i – lühikese ülevaate sellest, kuidas platvorm töötab ja mida API teha võimaldab – suudab ta lahendada keerulisi töövooge, mida me ei ole kunagi otseselt disaininud. Agent oskab lugeda koosolekute märkmeid ja tuletada sealt vajalikke turvameetmeid. Ta suudab kõrvutada varasid ja seotud nõudeid, et prioritiseerida tarnijate hindamist, või analüüsida turvaleide, tuues juurde kogu vajaliku riski- ja andmekonteksti Kordoni objektimudelist.

Seda kõike suudavad nad aga mitte seepärast, et need täpsed töövood oleks arendajate poolt koodi valmis kirjutatud. Agendid saavad sellega hakkama, sest andmed on omavahel loogiliselt seotud, API katab laialdaselt kogu platvormi ning agent oskab sealt ise järeldusi teha.

Kui mudel suudab platvormil iseseisvalt tegutseda, osutub toote tegelik võimekus oluliselt suuremaks, kui hinnakirja lehel olev funktsioonide nimekiri võiks lubada. See ei juhtu aga iseenesest – tarkvara peab olema selle jaoks teadlikult ehitatud. Kõige keerulisem pole seejuures isegi mitte tehniline API katvus, vaid just kontseptuaalne kiht: oskus aidata agendil mõista, mida ja millises järjekorras on süsteemis üldse mõtet teha.

Suurepärase agendikogemuse (Agent UX) kolm kohustuslikku osa

Seega oleme me jõudnud arusaamiseni, et hea agendisõbralik lahendus vajab kindlasti neid järgmiseid kolme komponenti.

1. Toote filosoofia ja funktsioonide dokumentatsioon

Mitte lihtsalt ülevaade sellest, millised funktsioonid eksisteerivad. Vaja on selgitust, kuidas need funktsioonid on mõeldud koos töötama ja mis on nende tegelik eesmärk.

Agent, kes teeb üksikuid API-päringuid ilma laiemat konteksti tajumata, tegutseb ebaefektiivselt või kogunisti valesti. Aga agent, kes mõistab, miks on riskid seotud turvameetmetega, miks on tarnijatel tervisemõõdikud ning miks peab tõendusmaterjal kuuluma just selle ülesande juurde, mis selle tekitas – selline agent suudab teha paremaid otsuseid, ilma et inimene peaks iga sammu detailideni ette kirjutama.

Just sellepärast lõime universaalse Kordoni skill’i, mille saab Claude’ile või mõnele teisele agendile tööriistaks anda. See ei ole pelgalt API dokumentatsiooni koopia. Tegu on kontseptuaalse kaardiga: millised andmeobjektid süsteemis tegelikult eksisteerivad, kuidas need omavahel seotud on ja millised tegevused on teatud olukordades üldse loogilised. See on kontekst, mis aitab agendil laiemalt mõelda ja järeldada, mitte vaid pimesi käske täita.

2. Lühike ja agentidele sobiv dokumentatsioon

Alguses andsime Claude’ile lugeda kogu ametliku dokumentatsiooni aadressil kordon.app/learn. See töötas, aga aeglaselt. Põhjus on lihtne – see API dokumentatsioon on kirjutatud inimesele, kes istub reede pärastlõunal rahulikult lahendamata probleemi kallal ning tahab asjasse peensusteni süveneda.

Lõpuks tegime API dokumentatsiooni põhjal agentidele eraldi Kordon-API skilli (tehniliselt võttes tegi seda muidugi Claude ise). Skillis, mis Claude endale ise kirjutas on palju lühem ja konkreetsem, kui esialgne API dokumentatsioon. Nähtavasti AI ei vaja isegi murdosa sellest kontekstist, mis klassikalises API dokumentatsioonis inimese jaoks kirjas on. Mudelil on vaja teada vaid tuumikobjektide arhitektuuri, peamisi päringupunkte ja asjakohaseid staatusekoode. Kõik muu osutub tihtipeale infomüraks, mis muudab agendi tegevuse asjatult aeglaseks.

Kui täna uut API dokumentatsiooni kirjutada, tasub mõelda, milline see välja näeb olukorras, kus lugejaks on LLM, mitte arendaja. Meile tundub, et kombinatsioon kahest - detailne dokumentatsioon inimesele ja AI-le, koos minimalistliku API skilliga on päris hea lahendus.

3. Lihtne API-võtmete haldus

API-võtmete loomine peab olema kiire ning nende eemaldamine veelgi lihtsam. Kui võtme roteerimine on valus ja ebamugav protsess, siis seda lihtsalt ei tehta. Praktikas tähendab see, et vanad API-võtmed jäävad aktiivseks logifailides ja väliskeskkondades, kus keegi ei tea enam täpselt, millele need ligipääsu omavad.

Praktiline ja agentisõbralik võtmehaldus võiks näha välja selline:

  • Eri kontotüübid ja mitme võtme tugi: Igal kasutajal võib olla paralleelselt kasutusel mitu võtit. Ideaalis on olemas eraldi lahendus AI-agentidele ja süsteemiintegratsioonidele (näiteks botikontod), et hoida inimese tegevus masina omast eraldi.
  • Täpselt piiritletud õigused: Agendile loodud API-võti ei tohiks vaikimisi pärida kasutaja laialdasi administraatoriõigusi. Süsteem peab võimaldama seadistada konkreetseid kitsaid ligipääse – näiteks anda agendile loa riskiregistri andmeid ainult lugeda, aga mitte muuta.
  • Automaatne aegumine: Ajutiste analüüside jaoks loodud ligipääsudele peab saama määrata aegumistähtaja. Nii välistatakse igavesti elus püsivad rändvõtmed ka siis, kui inimene unustab need käsitsi tühistada.
  • Kasutuse jälgitavus: Süsteem võiks näidata, millal API-võtit viimati kasutati. See teeb hüljatud võtmete tuvastamise ja sulgemise lihtsaks ning kaotab ära klassikalise hirmu tüüpi “äkki kuskil midagi läheb katki, kui ma selle kustutan”.
  • Sõltumatu roteerimine: Ühe kompromiteeritud või vananenud võtme kustutamine ei tohiks nõuda kõikide alluvate integratsioonide samaaegset ümberseadistamist.

Lõppkokkuvõttes on see tavaline turvaküsimus, mis paistab lihtsalt välja nagu arendajate mugavuse probleem. Kui meeskonnad API-võtmeid regulaarselt ei vaheta ega kustuta, on põhjus enamasti väga proosaline – see protsess on lihtsalt liiga tüütuks tehtud.

Agendikeskne kasutuspind on teadlik tooteotsus

Enamik tarkvaratiime on siiani ehitanud korraliku REST API, kirjutanud sinna juurde asjaliku dokumentatsiooni ja lugenud projekti lõppenuks. Mõnda aega see toimiski. Ehk ajal, kui API tarbijaks oli arendaja, kes tegi läbimõeldud integratsiooniotsuseid, oli see ootus igati kohane.

Täna tarbivad neid samu API-sid aga AI-agendid. Nad langetavad iseseisvalt otsuseid töövoogudes, mille inimene on seadistanud võib-olla vaid ühe korra. See on kasvatanud ootusi süsteemide arusaadavusele ning muutnud viletsa arendajakogemuse hinna varasemast palju kõrgemaks. Samas on õnnestumisest saadav võit tohutu – hästi lahendatud API toel suudavad agendid edukalt teostada ülesandeid, mida toote ametlik funktsioonide nimekiri pole kunagi otseselt toetanud.

Visuaalne kasutajaliides ei kao kuhugi. Ent API on muutunud liideseks, millest tarkvara järgmiste põlvkondade loomisel lihtsalt ei saa enam mööda vaadata. Seetõttu tuleb API kasutuskogemusse suhtuda juba algusest peale täpselt sama tõsiselt, nagu disainiksime valmis mingit uut ja kriitiliselt olulist klienditeekonda.