Personal Agent Protocol lupaa oikotien yrityksiin – spesifikaatio puuttuu

11. lokakuuta 2026 klo 07.00|Kirjoittaja: QUASAn toimitus|4 min lukuaika| 1

Sierran 6. lokakuuta 2026 julkaisema ilmoitus kertoo, että yhtiö ja Meta kehittävät Personal Agent Protocolia Genesysin, Instinctin, Rocketin, Shopifyn, Stripen ja Walmartin kanssa ja aikovat julkaista ensimmäisen v0.1-spesifikaation myöhemmin lokakuussa; Genesysin toimitusjohtaja Tony Bates tiivistää tarpeen sanoin ”Brands need a trusted way to know who an AI agent represents”. Ehdotus antaisi henkilökohtaiselle tekoälyagentille tunnistetun ja rajatun yhteyden yritykseen, mutta teknisen määrittelyn puuttuessa sen toteutusta ei voi vielä arvioida valmiina standardina.

Yhteys voisi kulkea yrityksen verkkosivuston, API-rajapinnan tai oman agentin kautta. Asiakas päättäisi, saako hänen agenttinsa lukea tilitietoja vai myös muuttaa niitä, ja yritys rajaisi tarjolla olevat toiminnot. Nykyisessä asioinnissa henkilökohtainen agentti voi joutua avaamaan verkkosivuja ja täyttämään lomakkeita ihmisen tavoin. Jos tehtävä ei ratkea, yhteydenotto saattaa siirtyä puhelintukeen tai verkkokeskusteluun. Luvattu oikotie tarkoittaa tätä suorempaa asiointireittiä; kyse on vielä suunnitelmasta, jonka toteutustapa tarkentuu teknisessä määrittelyssä. Yrityksen päätösvalta säilyisi myös suorassa yhteydessä, sillä se määrittäisi tarjolla olevat toiminnot ja kanavat.

Kumppanit ulottuvat asiakaspalvelusta maksuihin

Nimetyt osallistujat tuovat samaan hankkeeseen eri puolia yritysasioinnista. Genesys toimittaa asiakaspalveluteknologiaa, Shopify verkkokauppa-alustaa ja Stripe maksupalveluja; Walmart on vähittäiskauppias ja Rocket toimii asuntokaupan sekä rahoituksen parissa. Instinct edustaa henkilökohtaisten agenttien puolta. Mukanaolo kertoo kehitystyöhön osallistumisesta, mutta ei vielä paljasta, minkä yrityksen sivustolla tai palvelussa ehdotettu yhteys avautuu ensimmäisenä.

Osallistujaluettelo ei ole aivan yhtenäinen. CellCogin julkistusten vertailun mukaan Metan David Singleton mainitsi myös NiCEn ja Decagonin, mutta jätti pois Instinctin, joka esiintyy Sierran listassa. Kyse on eri julkistuksissa nimetyistä kehittäjistä, ei vielä yhteensopivien palveluiden luettelosta. Ero on merkityksellinen siksi, että protokollan arvo riippuu myöhemmin siitä, ottavatko sekä henkilökohtaisten agenttien tekijät että asiointia tarjoavat yritykset saman mallin käyttöön.

Vierailusta tiliasiointiin: lupa ja kanava vaihtuvat

Ehdotettu asiointi alkaisi yrityksen sivustolta, josta henkilökohtainen agentti selvittäisi tarjolla olevat palvelut ja yhteydenottotavan. Se voisi avata istunnon ensin vierailijana ja kysyä tuotteen saatavuutta tai palautusehdoista. Tässä vaiheessa tilin tunnistamista ei tarvittaisi, koska kysymys koskee yleistä tietoa. Malli erottaa siten avoimen tiedonhaun niistä toimista, joissa yrityksen täytyy tunnistaa asiakas.

Tilikohtainen tehtävä nostaisi oikeuksien tasoa. Asiakas kirjautuisi yrityksen omalla sivulla tai käyttäisi agentille jo asettamiaan tunnuksia, minkä jälkeen hän valitsisi luku- tai kirjoitusoikeuden. Lukuoikeus sopisi esimerkiksi tilauksen tietojen hakemiseen; tilauksen muuttaminen edellyttäisi oikeutta tehdä muutoksia. Nämä ovat ehdotetun mallin käyttöoikeusluokkia, eivät vielä julkaistuja toimintokohtaisia lupasääntöjä. Yrityksen omat rajat määrittäisivät lisäksi, mitkä sen toiminnot ovat agentin saavutettavissa.

Istunto rakennettaisiin OAuth-valtuutuksen varaan, ja se jatkuisi asiointikanavan vaihtuessa. Ennen kirjautumista tehty kysymys ja kirjautumisen jälkeinen tilausmuutos voisivat kuulua samaan käyntiin. Asiakkaan tunnistaminen ja agentin valtuutus ovat tässä eri asioita: kirjautuminen yhdistää pyynnön tiliin, kun taas annettu käyttöoikeus määrittää, mitä agentti saa tilillä tehdä. Yritys päättäisi lisäksi, hoitaako agentti tehtävän tavallisella verkkosivulla, rajapinnan kautta vai keskustelemalla yrityksen oman agentin kanssa.

Esimerkiksi takuukäsittelyssä yrityksen oma agentti voisi olla sopiva vastapuoli, koska asia saattaa vaatia keskustelua. Rajapinta taas voisi palvella täsmällistä tietojen hakua. Ehdotuksen suora reitti ei siten edellytä, että jokainen yritys korvaa nykyisen verkkosivustonsa uudella käyttöliittymällä. Käytännön nopeushyöty riippuisi siitä, mitä reittejä yritys todella tarjoaa ja millaiset oikeudet asiakas antaa.

MCP ja A2A ratkaisevat eri osia samasta asioinnista

Metirin protokollavertailussa MCP liittyy agentin työkaluihin ja tietolähteisiin, A2A agenttien väliseen yhteyteen ja Personal Agent Protocol asiakkaan puolesta toimivan agentin pääsyyn yritykseen. Tämä on työnjako, ei paremmuusjärjestys. Yritys voisi tarjota henkilökohtaiselle agentille MCP-pohjaisen tai OpenAPIlla kuvatun rajapinnan sen jälkeen, kun asiakassuhde ja käyttöoikeuden rajat on sovittu ehdotetussa mallissa. Sama asiointitehtävä voisi silloin käyttää molempia.

A2A:ssa agentit löytävät toisensa, lähettävät viestejä ja hoitavat tehtäviä keskenään. Ehdotuksessa yrityksen oma agentti on yksi mahdollinen asiointikanava, joten nämäkin mallit voivat kohdata samassa palvelussa. A2A:n agenttien välinen viestintä ei kuitenkaan yksin kuvaa tämän ehdotuksen ydinkysymystä: kenen asiakkaan puolesta henkilökohtainen agentti asioi ja millä hänen sekä yrityksen antamilla oikeuksilla. Vertailu kertoo protokollien ilmoitetusta tehtävästä, ei vielä siitä, miten ne liitetään toisiinsa valmiissa toteutuksessa.

Ensimmäinen määrittely ratkaisee toteutuksen rajat

Julkistettu kuvaus kertoo istunnon etenemisen ja karkean jaon luku- sekä kirjoitusoikeuteen. Koneellisesti tulkittavat oikeudet, luvan peruuttaminen, agentin tunnistamiseen liittyvät todisteet ja eri kanavien yhteinen tilankäsittely vaativat kuitenkin täsmälliset säännöt, jotta riippumattomat toteutukset voisivat toimia keskenään. Ilman teknistä tekstiä ei voi arvioida, millä ehdoilla yritys hyväksyisi agentin pyynnön tai miten se estäisi pyynnön menemisen asiakkaan valtuutusta pidemmälle. Jos asiakas haluaisi sallia toimitusosoitteen korjauksen mutta estää tilauksen peruuttamisen, pelkkä kirjoitusoikeus ei vielä kerro, voidaanko nämä toimet erottaa. Sama lupa olisi tulkittava johdonmukaisesti myös silloin, kun istunto siirtyy verkkosivulta yrityksen rajapintaan.

Myöhemmäksi kuvattuun kehitykseen kuuluvat tarkemmat toimintokohtaiset luvat, yritykseltä agentille lähtevät ilmoitukset sekä maksamiseen liittyvät laajennukset. Ne ovat mahdollisuuksia, eivät ilmoitettuja ensimmäisen version ominaisuuksia. Suunnitteilla ovat myös työpajat ja viitetoteutus kehittäjille. Seuraava konkreettinen käänne on ensimmäisen spesifikaation julkaisu: vasta sen säännöt näyttävät, miten asiakkaan lupa, yrityksen rajat ja kanavien välillä jatkuva istunto voidaan toteuttaa yhteensopivasti.

Lue myös:

Jaa: