Agentit ovat aina ensimmäisen päivän palkattuja. On aika suunnitella niiden mukaan.

Vuoteen 2027, 74% yrityksistä odotetaan käyttävän agenteja jollain tasolla, recent Deloitte -tutkimuksen mukaan. Vuosien ajan olemme suunnitelleet ja rakentaneet ohjelmistoja parantaaksemme ihmisten kokemusta sovelluksiemme, verkkosivujemme, käyttöjärjestelmien ja asiakirjojen läpikäymisessä. Nyt käyttäjä ei ole lainkaan ihminen. Tämä on laajempi muutos kuin pelkkä siirtyminen koontinäytöistä ja hallituista työnkulkuista, jotka on suunniteltu ihmisten tehtäviin. Olemme tilanteessa, jossa meidän on suunniteltava agenttien toimintaympäristöjä ja samalla suunniteltava ihmisten työnkulkuja, jotta agenttien kokemus näissä ympäristöissä voidaan ohjata tehokkaasti.  

Me olemme vielä alkuvaiheessa oppimassa, mitä agenteilta oikeasti tarvitaan, jotta ne olisivat toistettavasti ja luotettavasti menestyviä. Instinkti on käsitellä agenttien integrointia pelkästään kehotteena tai käyttöliittymäongelmana. Hyvin hallitun suoritusympäristön suunnittelu on meille kulttuurisesti uutta. Kuitenkin hyvän suunnittelun ja hyvän hallinnan perusperiaatteet eivät ole muuttuneet: meidän on annettava agenteille selkeä konteksti, yksiselitteinen suuntaus ja eksplisiittinen tarkoitus.

Kontexti: Miksi koodaus tuli ensin

Konteksti on väistämättä tärkein syöte, jos haluamme agenttien toistettavan toimittavan haluamallamme tasolla. Ohjelmistokehityksessä on tallennettuna enemmän kontekstia kuin melkein missään muussa alassa: repositoriot, API-skeemat, järjestelmien väliset suhteet, koodikatselmukset ja yhteisökeskustelut. Joten on loogista, että tekoälyn eturintaman laboratoriot aloittivat koodauksesta. Se on yksi harvoista aloista, joissa merkittävä osa kontekstista on jo kirjattu. 

Kuten jokainen uusi palkattu ohjelmistotiimissä kertoo, vaikka kaikki data olisi käytettävissä, agenteilla on yhä puutteita institutionaalisessa muistissa, joka on upotettu kirjoittamattomiin sääntöihin, joita kukaan ei ole koskaan dokumentoinut. Tämä aukko on laajalle levinnyt: 43 % kehittäjistä on huolissaan siitä, että tekoälytyökalut eivät sisällä riittävää kontekstia heidän erityisestä projektistaan tai koodikannastaan. Hiljainen tieto kattaa kaiken arkipäiväisistä konventioista, kuten suosituista kirjastoista tiettyihin tehtäviin, korkeiden riskien operatiivisiin varjoihin: myöhäisillan korjaus, joka pysyy ikuisesti, tai näennäisesti tyhjä tietokantasarakke, joka salaa tukee räätälöityä tulosraporttia. Tämä konteksti elää vanhemman insinöörin mielessä, äskettäisessä Slack-ketjussa tai ei missään. Se on harvoin itse koodikannassa.  

Jos näin on ohjelmistojen, yhden parhaiten dokumentoidun alan, kohdalla, on helppo ymmärtää, miksi agentit kamppailevat tehokkaasti suoriutua alusta alkaen monilla muilla toimialoilla. Terveydenhuollossa ja oikeudessa suuri osa institutionaalisesta tiedosta, joka muokkaa päivittäistä työtä, opitaan ja sisäistetään. Se elää ihmisten kokemuksessa eikä muodollisessa dokumentaatiossa. Oikeusagentti ei välttämättä tiedä tietyn kumppanin suosimaa rakennetta, sävyä tai argumentaatiota tiivistelmälle, kun taas terveysagentti ei ehkä ymmärrä paikallisia työnkulkuja ja eskalaatiokäytäntöjä, joita kiireinen klinikka käyttää tukemaan kliinikkojen johtamaa triagea. Pelkkä dokumentaatio ei voi sulkea tätä aukkoa, koska haaste ei ole pelkästään tiedon saatavuus; kyse on kontekstin siirtämisestä. Antaaksemme agenteille, mitä ne tarvitsevat menestyäkseen, meidän on perehdytettävä ne samalla tavalla kuin uusi palkattu.

Suuntaus: Miksi osmoosi ei toimi

Uuden tiimijäsenen perehdytys vaatii enemmän kuin oikeiden materiaalien ja pääsyn tarjoamista. Kun olemme sitoutuneet heidän menestykseensä, annamme selkeän suuntauksen siitä, mitä tehdä uusilla materiaaleilla ja pääsyllä: odotukset, selkeys siitä, mitä yritämme saavuttaa, ja palautetta matkan varrella. Tuon saman ajattelutavan agenteille. Annan selkeän, tarkkaan määritellyn suuntauksen (tehtävään nähden). Tämä pätee kaikkiin tiiminjäseniin, riippumatta heidän kokemuksestaan. Silti uudessa palkkaustilanteessa suuntaus täytyy viedä pidemmälle, koska he eivät vielä omaa institutionaalista kontekstia.

Ajattele agenttia kuin uutta palkattua, joka ei koskaan lakkaa olemaan uusi. Se on innokas ja kykenevä (ja rehellisesti sanottuna, sillä on rajaton energia), mutta se ei pysty omaksumaan ja säilyttämään yhtä monta kirjoittamatonta sääntöä kuin ihminen ajan myötä. Ihmiset oppivat osmoosin ja kokemuksen kautta, kun taas agentit oppivat arkkitehtuurista, joka on eksplisiittisesti rakennettu niiden työympäristöön.

Uuden palkatun kanssa voit sulkea tämän aukon ajan myötä kysymysten, palautteen ja uusien oivallusten avulla, jotka he keräävät organisaation prosesseista ja mieltymyksistä matkan varrella. Kirjaimellisia kahvinkeittokeskusteluja tai tiimi-ruokailuja. Agentin kanssa sinun täytyy rakentaa tämä aukon sulkeminen suunnitteluun itse. Tämä voi sisältää: 

• Antamalla agentille jäsennellyn kontekstiruutukan, joka erottaa kestävät säännöt, tehtäväkohtaiset faktat ja relevantin historian sen sijaan, että pudottaisiin kasa asiakirjoja sen syliin. 
• Määrittelemällä sen oikeudet ja päätösrajat etukäteen: mitä se voi tehdä itsenäisesti, mikä vaatii hyväksynnän, ja mitä sen ei saa koskaan käyttää. 
• Sijoittamalla muutaman konkreettisen esimerkin vahvasta tuloksesta suoraan kokemukseen, jotta agentilla on selkeä malli siitä, miten työ tulisi tehdä.
• Jakamalla aiemmat umpikujat, joihin olet törmännyt.

Hyvin hallitun agenttiympäristön suunnittelu ei ole mallin työn helpottamista. Se on ihmisen insinööritiimin suojaamista näkymättömältä tekniseltä velalta. Mutta vaikka hyvin ohjattu agentti voi noudattaa ohjeita täydellisesti, se voi silti menettää kohdan. Suuntaus kertoo, mitä tehdä, mutta ei kerro, miltä “hyvä” näyttää. Tämä aukko on se, missä tarkoitus astuu kuvaan.

Aikomus: Miksi agentit ajelehtivat keskelle

On tärkeää muistaa, että agentit ovat mallinnuslaitteita, jotka on koulutettu valtavilla tietomäärillä ja ovat luonnostaan taipuvaisia tuottamaan tilastollisen keskiarvon. Ilman selkeää, eksplisiittistä tarkoitusta, tuo keskiarvon tuotos on juuri se, mitä agentti palauttaa. Kysy agentilta “lisää käyttäjän todennusrajapinta”, ja se generoi oppikirjan mukaisen Express-reitin perus-salasanan hashauksella. Se toimii, mutta se täysin ohittaa tiimisi räätälöidyn todennuspalvelun, ohittaa vaaditun telemetrian ja rikkoo standardoidun virheformatoinnin. Se on riittävä ominaisuus paperilla, mutta kontekstista riippuen se on arkkitehtoninen virhe käytännössä. Tämän kaltaisten “bugin” helppoa on tuoda.

Estääksemme tämän, suuntaus on yhdistettävä aktiiviseen tarkoituksen tarkistukseen ja lokitukseen. Suojakaiteiden ei tulisi tarkistaa vain, kääntyykö koodi, vaikka se on tärkeää. Suojakaiteiden on eksplisiittisesti pakotettava mielipiteelliset standardit, reunatapauksen säännöt ja toimialakohtainen konteksti, jotka nostavat geneerisen tuloksen tuotantovalmiiksi. Lokit ovat tärkeitä järjestelmän tilan indikaattorina meille ihmisille. Tämä jäljitettävyys on kriittinen luottamuksen kannalta. 

Ihmisvuorovaikutuksessa on paljon tilaa epävarmuudelle. Joku voi jakaa sinulle ensimmäisen version, ja yhdessä voitte keskustella siitä, mikä on vahvaa ja mitä tarvitsee parantaa. Tämä toimii, koska emme odota ihmistyöntekijöidemme olevan itsenäisiä koneita. Jotta voimme todella hyödyntää agenttien työtovereiden voiman ja lupauksen (jotka meidän on toimittava autonomisemmin…), voimme suunnitella monia näitä suuntaavien tarkistusten mekanismeja. Takaisin ja eteenpäin tapahtuva keskustelu on edelleen tarpeen, mutta sen ei voi olla täysin manuaalista työtä. Selkeät hyväksymiskriteerit ja tarkistussäännöt etukäteen mahdollistavat agentin sisäisten palautesilmukoiden ajamisen. Suunnittelu virheiden ehkäisemiseksi on toinen järkevä UX-periaate, jonka voimme soveltaa tässä uudessa maailmassa: antaa agenteille mahdollisuus merkitä alhainen luottamus ennen toiminnon sitoutumista sen sijaan, että hiljaisesti valitsisivat parhaan arvauksen.

Missä metafora katkeaa

Uuden palkatun kehys toimii, kunnes se ei enää toimi. Ihmisen palkkauksessa kokemus johtaa pätevyyteen, mikä johtaa harkintaan. Kun näet uuden palkatun sisäistävän “miksi” kontekstin ja suuntauksen takana, se rakentaa luottamusta ajan myötä, ja yleisesti ottaen tämä on kumulatiivista. Agentilla ei ole paikkaa, johon kerätä ja tallentaa tätä kokemusta.

Uuden palkatun ensimmäinen viikko ja sadas viikko näyttävät erilaisilta. Agentin ensimmäinen tehtävä ja tuhatteinen näyttävät identtisiltä, ellei suunnitella ja rakenneta jotain, mikä tekee niistä erilaisia. Tämä on uusi suunnitteluhaasteemme.

Agentin vastuu riippuu suunnittelusta

Jos vastuu ei voi asua agentissa, sen on asuttava sen ympärillä olevassa tukirakenteessa. Se tiivistyy samoihin kolmeen kysymykseen, jotka esittäisin ennen kuin antaisin työn mille tahansa uudelle palkatulle: Millainen konteksti sillä on? Millainen suuntaus olen antanut? Mikä on todellinen tarkoitukseni?

Seuraavan kerran, kun annat tehtävän agentille, älä tarkista vain tulosta. Tarkista ensin omat syötteesi. Annoitko sille kontekstin, jonka uusi palkattu tarvitsee ensimmäisenä päivänä? Oliko suuntauksesi riittävän tarkka selviytymään kirjaimellisesta tulkinnasta? Oliko tarkoituksesi tarpeeksi selkeä, ettei “keskimääräinen vastaus” ollut paras mahdollinen?

Selkeän ohjauksen (tavuissa?) avulla tapahtuu jotain mielenkiintoista: agentin ei tarvitse pitkää rataa tullakseen luotettavaksi. Konteksti, suuntaus ja tarkistus, jotka rakennat etukäteen, määrittelevät sen toiminnan jokaisessa tehtävässä. Uusi palkattu ansaitsee luottamuksesi ajan myötä; agentin on ansaittava se jokaisella kerralla suunnittelemassasi järjestelmässä. Vastuu ei ole jotain, mihin se kasvaa, se on sisäänrakennettu alusta alkaen. Kysymys ei ole, milloin agenttisi on valmis suurempaan vastuuseen. Se on, oletko suunnitellut sen ansaitsemaan vastuun jokaisessa yksittäisessä tehtävässä.