A memo · October 2026
Why we're building Index
In 1874, John Wanamaker's Philadelphia store became the first in the United States to put a price tag on every product. One price, written down, the same for everyone who walked in. It answered the question every shopper carries before they ask it.
A century and a half later, an agent is asking on the shopper’s behalf. The model can understand the request. The current price and availability still have to come from the merchant.
Ask an agent to find a waterproof trail shoe, size 10, under $140. Understanding the request is one step. Finding the moss pair in size 10, available for your postcode and within budget after tax and shipping, takes current merchant data. That data is spread across separate catalogs and store systems.
Where the protocols hand off
MCP gives agents a standard way to use tools. Personal Agent Protocol (PAP) describes how an agent discovers a participating company’s interfaces, starts a session and obtains user-granted access. The protocol is still in draft. These protocols help agents work with businesses. Index is being built to help them find the right product across those businesses.
With PAP, a company publishes a discovery document at a standard address. It tells an agent how to connect. A cross-platform catalog answers the question that comes before that: which store has the right item, in stock, at the right delivered price?
Discovery
index.
Find the right item, check stock and compare delivered prices.
Access
PAP
Connect to a participating company with the access it allows.
Transaction
Purchase
Continue through a supported purchase flow, in the agent or at the store.
Index focuses on finding and verifying offers across merchants. It returns the information an agent needs and a supported next step. How the purchase is completed is separate from discovery.
What finding out costs today
Today, an agent can browse store pages, compare listings and look for the right variant. Each store presents that information differently. Checking stock and delivery costs adds more steps, and a page alone may not show the final total.
The agent needs to know where an answer came from, when it was checked and what is still unknown. A plausible price is not enough to make a purchase decision.
What we're building
One API call: a shopping request in, a structured product answer out.
intent
“waterproof trail shoes, size 10, under $140”
{
"merchant": "alpinestore.com",
"match": "Trail Runner X",
"variant": "size 10 / moss",
"price": "$119.00",
"landed_cost": "$129.00",
"in_stock": true,
"ships_in": "2 days",
"checked_at": "2026-10-14T17:36:02Z",
"product_url": "https://alpinestore.com/p/trail-runner-x?size=10&color=moss"
}The example shows the answer we’re building toward: the store, the matching product, exact variant, price, total delivered cost, stock status, shipping window, when it was checked and a link to the product at the store. Anything we cannot verify should be marked unknown. Response speed remains a target, not a published result.
Freshness depends on access to current merchant data. Catalog structure helps find a match; a check against the merchant’s available sources helps confirm price and stock when the agent asks.
Coverage will depend on the catalogs we can reach and what each merchant lets us verify. We want agents to see that distinction clearly: what was found, what was checked and what still needs confirmation.
The API is the product. Build it into an agent, or connect with MCP where supported. We’re designing the handoff to use PAP where a merchant supports it. One catalog layer, with a choice of how to connect.
Why now
Agents are becoming a way people find and buy products. Protocols are making it easier for them to connect to businesses. The next step is reliable catalog data across those businesses, so an agent can move from understanding a request to finding a product the person can actually buy.
If you’re building an agent that helps people find and buy products, or making a catalog available to agents, we’d like to hear from you.