What Is poppy.json? The /.well-known File That Tells AI Agents How to Work With Your Company

The Personal Agent Protocol project published Draft 0.1 of its specification on October 9, 2026, defining poppy.json, a JSON file companies host at https://{domain}/.well-known/poppy.json so AI agents can discover in one request how to work with them. The file carries a protocol_version, organization name and domain, an OAuth issuer under auth, and lists of agent, apis (openapi or mcp) and web interfaces, with optional extensions such as operations. The draft places the trust anchor in the company's OAuth server rather than the JSON file alone, requiring agents to fetch the file over HTTPS and verify that organization.domain matches the originally requested domain.

What Is poppy.json? The /.well-known File That Tells AI Agents How to Work With Your Company poppy.json is the discovery file in the Personal Agent Protocol Poppy : organization, OAuth issuer, MCP and OpenAPI APIs and extensions, with a worked example. poppy.json is a small JSON file a company publishes at https://{domain}/.well-known/poppy.json so that a person's AI agent can find out, in one request, how the company wants agents to work with it. It is the discovery step of the Personal Agent Protocol PAP, also called Poppy . The Draft 0.1 specification https://personalagentprotocol.org/docs/spec was published on October 9, 2026, and the project calls the whole thing changeable, so treat the details below as a draft. What the file is for Before an agent can sign in, call an API, browse a site or start a conversation, it has to know what exists. poppy.json answers four questions: who is this company, which OAuth server do I authenticate against, which interfaces are on offer APIs, a website, a company agent , and which optional features does it support. For the bigger picture, see what PAP is https://contextiq.trango-compute.com/blog/what-is-personal-agent-protocol-pap-sierra-meta . The fields | Field | Required? | What it holds | |---|---|---| | protocol version | Yes | "major.minor" , for example "0.1" | | organization | Yes | name and domain ; the domain must match the host the file was fetched from ignoring www. | | auth | Required if agent , apis or web.browser session endpoint is present | issuer an HTTPS URL for the OAuth server , plus optional direct , device and mediated sign-in blocks with their scopes, and custom scopes | | agent | One of agent , apis , web is required | protocols : a list of objects with a type such as "poppy" , an HTTPS endpoint for conversations, and an optional resource | | apis | One of the three is required | A list; each item has a type "openapi" or "mcp" , a url , a short description , and an optional resource | | web | One of the three is required | browser session endpoint : where an agent's browser joins a session | | extensions | No | Optional features, each with a version ; the built-in one is operations , and third-party ones use domain-prefixed names such as example.com/gift-wrap | A worked example fictional Illustrative. Northwind Outfitters is a made-up company, and these URLs do not exist. The shape follows the Draft 0.1 field list above; the spec text is the authority on exact values. { "protocol version": "0.1", "organization": { "name": "Northwind Outfitters", "domain": "northwind.example.test" }, "auth": { "issuer": "https://auth.northwind.example.test", "direct": { "scopes": "poppy:read", "poppy:write" }, "device": { "scopes": "poppy:read" } }, "apis": { "type": "mcp", "url": "https://mcp.northwind.example.test/mcp", "description": "Order lookup and returns" }, { "type": "openapi", "url": "https://api.northwind.example.test/openapi.json", "description": "Product catalog and stock levels" } , "web": { "browser session endpoint": "https://northwind.example.test/poppy/browser-session" }, "extensions": { "operations": { "version": 1 } } } Read it as a menu. An agent that only needs stock levels can use the OpenAPI description. One that needs to look up an order can use the MCP server. Both authenticate against the single issuer in auth , and a customer can sign in directly in a browser read and write or on another device read only . What an agent checks before trusting it The draft puts the trust anchor in the OAuth server, not in the JSON file alone. Before using a poppy.json , an agent must: 1. Fetch it over HTTPS. Redirects are allowed, but every destination must be HTTPS, and organization.domain must still match the domain originally requested. 2. Fetch the company's OAuth Authorization Server Metadata RFC 8414 . 3. Confirm the metadata's issuer exactly equals auth.issuer , and that its poppy domains list includes organization.domain . That last check ties a domain to an issuer from both sides, which is meant to stop one company's file from pointing agents at another company's login. It also means publishing poppy.json is not enough: your authorization server metadata has to carry poppy domains . Common mistakes the rules imply - Declaring apis or agent with no auth block. The draft requires auth whenever those are present. - A domain that does not match the host. organization.domain must equal the host the file is served from. - A redirect to plain HTTP. Every redirect destination must be HTTPS. - An issuer mismatch. auth.issuer and the metadata's issuer must match exactly, including any trailing slash. - No poppy domains in the OAuth metadata. Agents are required to look for it. - Treating the file as the whole integration. It only describes; sign-in, DPoP-bound tokens and the interfaces themselves are still yours to build. How it relates to other discovery files Several well-known files now exist for agents, and they answer different questions. poppy.json describes how a person's agent should authenticate and which interfaces a company offers under PAP. An agent-card.json describes an A2A agent's identity and skills. llms.txt is a plain-text guide for language models. Our overview of making a website discoverable to AI agents https://contextiq.trango-compute.com/blog/make-website-discoverable-ai-agents-llms-txt-agent-cards covers the others. A company can publish several. Where ContextIQ fits The Agent Protocol Inspector https://contextiq.trango-compute.com/agent-readiness-detector scans a URL for MCP servers, A2A agent cards and ARD catalogs. It does not read poppy.json today. If your poppy.json lists an MCP server, you can scan that server's URL to see what an agent would discover there. The OIDC Inspector https://contextiq.trango-compute.com/oidc-inspector shows what your authorization server publishes, but it does not check PAP-specific fields such as poppy domains . Sources Follow Trango Compute on LinkedIn We post updates on new tools, context engineering patterns, and LLM cost research. Follow on LinkedIn https://www.linkedin.com/company/trango-compute