The person's side of Poppy.

The Personal Agent Protocol (Poppy) covers how a personal agent identifies itself to a company, gets the person's permission, and acts in their account. It doesn't define where the person's memory, shared moments, and relationships live. We think Field can fill that gap with three optional, domain-named extensions, and we'd like to bring them to the design workshops Sierra announced for the coming month.

Field and Jeffers Seven Labs are not affiliated with, endorsed by, or partnered with Sierra, Meta, or any Poppy design partner. This is an independent proposal against Poppy draft 0.1 (October 9, 2026). Companies in the examples are fictional.

How it fits

Poppy's own extension rules.

Poppy draft 0.1 lets anyone add optional features as extensions. Extensions defined by the protocol itself have plain names (today there is one, operations). Anyone else must name an extension with a domain they control, such as example.com/gift-wrap.

A company lists the extensions it supports under extensions in its /.well-known/poppy.json, each with a version (the major version) and its own settings, such as an endpoint.
A personal agent lists the extensions it supports under extensions in its client metadata document.
Either side ignores extensions it doesn't support. A company that needs one can refuse a request with extension_required.

So the three proposals below are named under fieldmemory.app/, carry "version": "0" while they're design-only, and change nothing in Poppy's core.

Three proposed extensions

Grants, moments, and places.

In every case the rule is the same: grants travel, data doesn't. The company gets a scoped, expiring, audited grant that it redeems at the person's Field host, never a copy of the person's memory.

fieldmemory.app/memory-grant

Scoped, expiring, audited reads of the person's memory. The company asks for what it needs (for example, stay preferences). The person approves on their own device. The agent hands the company a one-time grant offer, which the company redeems at the Field host for a token limited to exactly that scope and time window. Every read is logged in the person's Field.

// Company: /.well-known/poppy.json
"extensions": {
  "fieldmemory.app/memory-grant": {
    "version": "0",
    "endpoint": "https://api.hotel.example/poppy/field-grants",
    "accepts": ["stay.preferences"] } }

// Grant offer the agent passes to that endpoint
{ "grant_offer": "fgo_9Lr…",
  "field_host_issuer": "https://auth.host.example",
  "sub": "pw_Ht4…",
  "authorization_details": [{
    "type": "fieldmemory.app/memory-grant",
    "read": ["stay.preferences"],
    "not_before": 1791660000, "expires_at": 1791921600,
    "audit": "every_read" }] }

Why both win: the company gets current, consented preferences without building and securing yet another profile; the person shares one slice, for one window, and can see every read.

fieldmemory.app/moment

Shared moments between people and the companies that were part of them. A person can invite a company into a moment they convened (a trip, an event) as a contributor. The company adds its items, such as an itinerary or event photos, next to the family's own, attributed and never merged. It reads nothing unless the grant also says so.

// Agent → company: an invitation into one moment
{ "authorization_details": [{
    "type": "fieldmemory.app/moment",
    "moment": "m_8Zt1",
    "role": "contributor",
    "contribute": ["itinerary", "photos"],
    "read": [],
    "expires_at": 1792526400 }] }

Why both win: the company's part of the experience lands in the customer's lasting memory without running accounts or a photo service; the person gets one record of the moment, with everyone's contributions side by side, and can withdraw their own at any time.

fieldmemory.app/place-capability

Capability, not identity. A place (a hotel room, a rental car) issues what the person may do there as a W3C Verifiable Credential bound to the person's pairwise key for that place. The person's device presents proof of possession. The place learns that this holder may unlock room 412, and nothing about who they are.

{ "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "PlaceCapability"],
  "issuer": "https://hotel.example",
  "validFrom":  "2026-11-02T15:00:00Z",
  "validUntil": "2026-11-05T11:00:00Z",
  "credentialSubject": {
    "id": "urn:fieldmemory.app:pw:Ht4…",
    "capabilities": ["room:412:unlock", "room:412:thermostat"] } }

Why both win: the place stops collecting and storing identity it doesn't need (less liability, faster check-in); the person reveals only what the moment needs, and access ends at checkout on its own.

Examples are illustrative. Field names, types, and the credential context are proposals and will change in discussion.

Reuse, not reinvention

Standards Poppy and the web already use.

→OAuth and DPoP. Poppy already runs on OAuth with DPoP-bound tokens (RFC 9449). Field hosts redeem grant offers with OAuth Token Exchange (RFC 8693), company authentication via private_key_jwt, and a DPoP proof.
→Rich Authorization Requests (RFC 9396). Poppy defines two broad scopes, poppy:read and poppy:write, and lets companies add their own. Field proposes carrying the exact grant in authorization_details, so a broad scope is a floor, never a wildcard.
→W3C Verifiable Credentials 2.0. Place capabilities and attestations (over 18, licensed driver) are VCs or SD-JWT VCs with selective disclosure, presented by the person, never pulled.
→MCP. Poppy lets companies offer MCP APIs with Bearer tokens bound to one server. A Field host exposes the person's memory the same way: an MCP server that enforces the grant on every call and returns an audit reference.
→Pairwise IDs. Poppy requires a stable, opaque User ID per company that isn't derived from personal information. Field's per-counterparty pairwise ID meets that rule and can serve as the same value.
→Sign-in. An agent signs in to a person's Field with Poppy's Device Sign-In, approved on the person's own device. Field would not offer Mediated Sign-In.

What we'd like to discuss

Questions for the workshops.

01Is a domain-named extension the right home for person-held memory grants, or should grant offers be a general Poppy pattern?
02Would Poppy welcome authorization_details (RAR) as the way to say exactly what a sign-in covers?
03How should a company signal that it accepts a time-boxed grant instead of an account sign-in?
04Where do shared, multi-person moments fit in Poppy's conversation and session model?

Workshop organizers, implementers, and companies: field@jeffers-seven.com or @fieldmemoryapp. See also the Field protocol overview.

Poppy sources: specification and extensions, draft 0.1, updated October 9, 2026.