Kuvitellaan, että huoltoyhtiö saa viestin: ”Toimiston lämmitys ei toimi. Ehtiikö joku tänään paikalle?” Jonkun pitää selvittää sijainti, vian laatu, kiireellisyys ja se, mitä yhtiö pystyy lupaamaan. Lopuksi ihminen voi joutua vahvistamaan käynnin.
Tähän on houkuttelevaa piirtää heti neljä agenttia: yksi vastaanottaa viestin, toinen etsii ajan, kolmas tarkistaa säännöt ja neljäs vastaa asiakkaalle. Kaavio näyttää hienolta. Samalla syntyy neljä kohtaa, joissa olennainen tieto voi kadota.
- 01 / VIESTIKuvaa ongelma
- 02 / AGENTTIJäsennä pyyntö
- 03 / SÄÄNNÖTTarkista vapaat ajat
- 04 / IHMINENHyväksy varaus
Aloita työstä, älä agenttien määrästä
Kirjaa ensin päätökset. Mitä tietoja viestistä voi poimia? Mitkä faktat pitää hakea luotettavasta järjestelmästä? Mitkä säännöt ovat yksiselitteisiä? Missä tarvitaan ihmisen päätös?
Tässä esimerkissä yksi tekoälyagentti voisi tehdä viestistä ehdotuksen: osoite, ongelma, kiireellisyys ja puuttuvat tiedot. Tavallinen palvelu tarkistaa toimialueen ja vapaat ajat. Ihminen hyväksyy varauksen ennen kuin asiakkaalle luvataan mitään. Ensimmäinen versio voi olla näin yksinkertainen.
Selkeä sääntö ei parane sillä, että se kääritään agentiksi. Jos vastaus perustuu kiinteään laskentaan tai ehtoon, pidä se ennustettavana ja testattavana.
Milloin toinen agentti kannattaa lisätä?
Oletetaan sitten, että ajanvaraus kuuluu toiselle tiimille. Sillä on oma palvelu, julkaisutahti ja käyttöoikeudet. Viestin vastaanottajan ei tarvitse tietää, miten tiimi löytää vapaan ajan. Se lähettää selkeän tehtävän ja saa selkeän vastauksen. Tällaisessa rajassa agenttien välisestä viestinnästä voi olla hyötyä.
Googlen esimerkki eri ohjelmointikielillä toimivista agenteista havainnollistaa tätä: Python-agentti poimii sopimuksen tiedot ja Go-palvelu tarkistaa säännöt. Ne toimivat yhdessä A2A:n avulla, vaikka niiden toteutuskieli on eri. Opetus ei riipu kielistä: anna kullekin osalle vastuu, jonka se pystyy selittämään ja testaamaan.
A2A antaa itsenäisille agenteille yhteisen tavan kertoa kyvyistään, vaihtaa tehtäviä ja raportoida etenemisestä. Siitä on hyötyä, kun agentit todella ovat erillisiä. Jos kaksi vaihetta ovat saman pienen sovelluksen sisällä, funktiokutsu tai jono voi olla yksinkertaisempi.
Tee työn siirrosta selkeä
Lämmityspyyntöä siirrettäessä mukana pitäisi kulkea tunniste, poimitut faktat ja niiden lähteet, avoimet kysymykset sekä täsmällinen pyyntö seuraavalle vaiheelle. Vastauksesta pitää käydä ilmi, mitä tapahtui, mitä aikoja on tarjolla ja tarvitaanko ihminen mukaan. Seuraavan agentin ei pitäisi joutua kokoamaan tilannetta uudelleen pitkästä keskusteluhistoriasta.
Päätä myös, mitä tapahtuu, jos toinen palvelu on hidas tai poissa käytöstä. Aikakatkaisu jättää pyynnön odottamaan tarkistusta. Se ei saa muuttua huomaamatta vahvistetuksi varaukseksi. Tallenna tehtävän tila niin, ettei uusi yritys tee kahta varausta.
Tämä on moniagenttityön arkinen puoli: syötteet, tulokset, aikakatkaisut, uusintayritykset ja vastuut. Juuri niiden ansiosta järjestelmä toimii myös kiireisenä tiistaina.
Järkevä ensimmäinen versio
- Piirrä yhden oikean pyynnön kulku saapumisesta päätökseen.
- Käytä tekoälyä epäselvän syötteen käsittelyyn ja tavallista koodia selkeisiin sääntöihin.
- Määrittele vaiheiden välillä kulkevat tiedot ja palautettava tila.
- Lisää toinen agentti, kun sillä on oma tehtävä tai selkeä vastuuraja.
- Testaa epäonnistunut työn siirto ennen kuin juhlit onnistunutta.
Agenttien määrä ei ole tavoite. Tavoite on työnkulku, joka pitää ihmiset ajan tasalla ja hoitaa tehtävän loppuun.