Ipinapakita ng draft ng Poppy kung paano makaa-access ang mga personal na ahente sa mga account ng kumpanya

Inilathala ng Sierra ang draft 0.1 ng Personal Agent Protocol, o Poppy, noong Oktubre 9, tatlong araw matapos ipahayag ang proyekto kasama ang Meta at iba pang partner. Ginagawang mga iminumungkahing tuntunin ng bagong dokumento ang malawak na pangako noong paglulunsad: kung paano hanapin ang interface ng ahente ng kumpanya, tukuyin ang isang personal na ahente, papasukin ang customer, at panatilihin ang iisang pagbisita sa website, mga API, at ahente ng kumpanya.

Draft pa rin ito. Sinasabi ng espesipikasyon na maaaring magbago ang anumang bahagi bago magkaroon ng matatag na bersyon, kabilang ang mga pagbabagong hindi magkatugma. Nagpangalan din ang Sierra ng 35 karagdagang design partner. Hindi pinatutunayan ng pakikilahok sa proseso ng pagdidisenyo na nag-deploy na ng mga interface ng Poppy ang mga kumpanyang iyon.

Ang malaking pagbabago

• Ano ang nagbago: Inilarawan ng anunsyo noong Oktubre 6 ang paraan para makipag-ugnayan ang mga personal na ahente sa mga negosyo. Inilalatag naman ng draft noong Oktubre 9 ang mga iminungkahing palitan ng pagkakakilanlan, pahintulot, at session na kailangang ipatupad ng kumpanya at ahente.
• Bakit ito mahalaga: Maaaring pahintulutan ng customer ang isang ahente na asikasuhin ang mga gawain sa account habang tinutukoy ng kumpanya ang ahente at nililimitahan ang access nito. Iniuugnay ng draft ang kontrol na iyon sa pag-browse sa website, mga API, at mga pag-uusap, bagaman kumpanya ang pumipili kung aling mga channel at pahintulot ang iaalok.
• Ano ang dapat bantayan: May kongkretong mga interface nang masusuri ang mga tagapagpatupad, kasabay ng mga tuntunin sa pagbabayad, notification, at attachment na hindi pa nareresolba. Nagpaplano ang Sierra ng mga design workshop at isang reference implementation sa susunod na buwan; wala sa dalawa ang ebidensiya pa ng malawak na interoperability.

Nagsisimula ang pagtuklas sa domain ng kumpanya

Ayon sa draft na espesipikasyon, naglalathala ang kalahok na kumpanya ng /.well-known/poppy.json sa HTTPS. Inililista ng dokumentong iyon ang organisasyon at OAuth issuer nito, mga sinusuportahang paraan ng pag-sign in, at anumang website session endpoint, OpenAPI o MCP API, o endpoint ng pag-uusap sa ahente ng kumpanya na iniaalok nito. Hindi kailangang ialok ng kumpanya ang bawat ruta. Gagamitin ng ahente ang file para tuklasin kung ano ang mayroon, sa halip na ituring ang website bilang tanging pasukan.

Hindi sapat ang file lamang para pahintulutan ang isang ahente. Dapat tumugma ang domain ng organisasyon sa domain na hiniling ng ahente. Dapat ding suriin ng ahente ang metadata ng OAuth server: dapat tumugma ang issuer nito sa file, at kailangang kasama sa listahan ng poppy_domains ang domain ng organisasyon. Layunin ng mga pagsusuring ito na pigilan ang hindi kaugnay na domain na angkinin ang issuer ng ibang kumpanya at makatanggap ng mga token.

Tinutukoy ng personal na ahente ang sarili nito sa pamamagitan ng HTTPS na client_id URL na naghahatid ng metadata ng client nito, kabilang ang mga pampublikong signing key at pinapahintulutang redirect address. Maaaring magtakda ang kumpanya ng paunang pagpaparehistro, mag-block o magbawi ng agent ID, at limitahan ang paggawa ng session. Mga kontrol ito na ibinibigay ng draft sa kumpanya; hindi nito inaatasang tanggapin ng bawat kumpanya ang bawat ahente.

Maaaring maging account session ang guest session

Nagtatalaga ang personal na ahente sa user nito ng matatag at opaque na ID na natatangi sa bawat kumpanya at nagsisimula ng session gamit ang pirmadong assertion. Nagbabalik ang kumpanya ng session token na hindi naka-sign in. Dahil dito, nakikilala nito ang parehong ahente at user sa iba't ibang session nang hindi itinuturing na naka-sign in ang tao. Ipinagbabawal ng draft ang pagbuo sa user ID mula sa pangalan, email address, o numero ng telepono, kahit gumamit pa ng keyed hash.

Para sa access sa account, inaanunsyo ng kumpanya ang mga sinusuportahan nitong paraan ng pag-sign in. Gumagamit ang direktang pag-sign in ng OAuth authorization page at PKCE sa browser ng user. Sa device sign-in, pinupuntahan ng user ang page ng kumpanya gamit ang link at code. Pinahihintulutan naman ng mediated sign-in ang ahente na isumite sa tinukoy na endpoint ng kumpanya ang mga kredensyal na ibinigay ng user; hiwalay at opsyonal itong ruta na may tahasang tuntunin sa paghawak ng kredensyal at paglilimita ng bilis. Kinikilala ng draft ang limitasyon sa tiwala: hindi laging mabeberipika ng kumpanya kung tao, at hindi ahente, ang kumumpleto sa direktang pahina ng pag-sign in.

Ipinapahayag ang mga pahintulot bilang mga scope. Tinutukoy ng Poppy ang malalawak na poppy:read at poppy:write scope, habang pinahihintulutan ang kumpanya na mag-alok ng mas makitid na custom scope. Hindi maaaring magbigay ang kumpanya ng higit sa hiniling ng ahente o higit sa pinahihintulutan ng partikular na paraan ng pag-sign in. Pinahihintulutan ng account token, na inilalabas matapos mag-sign in, ang ahente na kumuha ng mga kasunod na naka-sign-in na session token sa loob ng mga inaprubahang scope. Kung kailangan ng gawain ng higit na access, kailangang mag-sign in muli ang user para sa mga scope na iyon.

Mahalaga ang pagkakaiba ng dalawang token. Maikli ang bisa ng session token at ginagamit ito para sa mga API call at pag-uusap. Mas matagal ang bisa ng account token, isang OAuth refresh credential na ginagamit lamang sa mga token at revocation endpoint ng kumpanya. Sinasabi ng draft na dapat itong ilayo ng ahente sa konteksto ng modelo, mga mensahe, log, at URL. Binabawi ng pag-sign out ang account token at isinasara ang mga session na nakakabit dito; maaari ring tapusin ng kumpanya ang mga session na iyon. Maaaring manatiling balido ang mga dati nang inilabas na session token, kaya ipinapayo ng draft sa mga kumpanya na suriin ang estado ng session sa bawat kahilingan o gumamit ng mas maiikling bisa ng token.

Isang session, tatlong posibleng ruta

Iminumungkahi ng Poppy ang iisang session ng kumpanya para sa aktibidad ng user sa pamamagitan ng personal na ahente. Para sa mga OpenAPI call at pag-uusap sa ahente ng kumpanya, ipinapadala ng ahente ang session token sa authorization header. Karaniwang itinatali ng draft ang mga token na iyon sa key na hawak ng ahente gamit ang mga DPoP proof, na sinusuri ng kumpanya sa bawat kahilingan. Tahasang eksepsiyon ang MCP: gumagamit ang authorization nito ng bearer token na limitado sa nakalistang MCP server, at para lamang sa mga MCP API pinahihintulutan ng draft ang bearer na anyong iyon. Mga kinakailangan ito ng protocol, hindi patunay na ligtas ang isang implementasyon.

Iba ang paraan ng pagsali ng pag-browse sa website sa parehong session. Kung naglalathala ang kumpanya ng browser session endpoint, nagpapadala ang browser ng ahente ng panandaliang pirmadong assertion at tumatanggap ng sariling session cookie ng kumpanya. Ipinatutupad naman ng website ang kasalukuyang estado ng pag-sign in at mga scope ng session. Kung wala ang endpoint na iyon, nagba-browse ang ahente bilang karaniwang bisitang naka-sign out. Inilarawan ng launch account ng Sierra ang iisang pagbisita sa iba't ibang channel; tinutukoy ng draft ang magkakaibang kredensyal para sa trapiko ng browser at API sa loob ng pinagsasaluhang session na iyon.

Maaaring ilista ng kumpanya sa discovery file nito ang mga OpenAPI description, MCP server, at endpoint ng pag-uusap. Inilalarawan ng draft ang format ng pag-uusap ng Poppy para makipag-usap sa ahente ng kumpanya at magsama ng tao kung kailangan. Ipinauubaya nito sa bawat API ang sarili nitong schema. Kumpanya ang nagpapasya kung aling mga ruta ang ilalantad at maaari nitong limitahan ang ginagawa ng ahente kahit naka-sign in ang session.

Mga bagay na hindi pa napagpapasyahan ng draft

Binabanggit sa pahina ng mga bukas na paksa ng protocol ang tatlong malaking kakulangan: mga pagbabayad, push notification kapag walang bukas na kahilingan, at mga attachment gaya ng resibo, label, larawan, o form. Sinasabi nitong hindi kumpleto ang listahan. Gumagamit ang mga halimbawa ng draft ng mga kathang-isip na kumpanya at placeholder na kredensyal.

Inilalarawan sa post ng Sierra noong Oktubre 9 ang isang demonstrasyon sa kumperensiya na kinasasangkutan ng Muse ng Meta at Rocket. Salaysay ito ng Sierra tungkol sa itinanghal na demonstrasyon, hindi independiyenteng audit ng deployment sa produksyon. Sinasabi ng Sierra na magdaraos ito ng mga design workshop at maglalathala ng reference implementation sa susunod na buwan. Sa ngayon, inilathalang panukala ang Poppy na may detalye sa implementasyon at lumalawak na talaan ng mga design partner. Nakadepende ang praktikal na saklaw nito sa kung aling mga kumpanya at tagabuo ng personal na ahente ang magpapatupad ng magkakatugmang bersyon at kung anong access talaga ang iaalok nila.

Mga pinagmulan at karagdagang babasahin

• Espesipikasyon ng Personal Agent Protocol, draft 0.1, na-update noong Oktubre 9, 2026. Pangunahing pinagmulan para sa mga tuntunin sa pagtuklas, pagkakakilanlan, pag-sign in, scope, token, session, at channel. Tahasan nitong pinahihintulutan ang mga pagbabagong hindi magkatugma bago ang matatag na bersyon; kathang-isip ang mga halimbawa nito.
• Mga bukas na paksa ng Poppy, na-update noong Oktubre 9, 2026. Pangunahing talaan ng mga pagbabayad, push notification, at attachment na hindi saklaw ng kasalukuyang draft; sinasabi ng pahina na maaaring may lumitaw pang ibang puwang.
• Anunsyo ng Sierra noong Oktubre 9. Itinatala ang petsa ng paglalathala, 35 karagdagang design partner, iniulat na demonstrasyon sa kumperensiya, at planong mga workshop/reference implementation. Mga pahayag ito ng Sierra, hindi ebidensiya ng deployment.
• Panimula ng Sierra noong Oktubre 6. Ipinapakita kung ano ang iminungkahi ng paunang anunsyo at ang pagbabagong dala ng sumunod na teknikal na draft.