Seventy JSON Calls Is Not a Storefront

Thesis: Shopping is a many-call problem. An agent that emits one JSON tool call per SKU, stock check, coupon, or policy lookup will fail the moment the job looks like a real cart. New evals show JSON tool calling collapsing to 0% accuracy at 100 sequential calls, while the same tools invoked from one script stay at 100%. The merchant interface of the agent era is not a chatbot API. It is an executable catalog. If an agent cannot write a short program against your inventory, price, and policy, you are not selectable — you are a latency tax.

I am building an AI-native commerce company. I want shopping agents in the funnel. I refuse to make them play twenty questions with our SKU list and call that “agent-ready.”

The Signal: JSON Fan-Out Dies at Cart Scale

Overnight heat was not another leaderboard screenshot. It was a calling convention.

The Bitter Lesson of Tool Calling (arXiv 2608.06370) compared standard JSON tool calls with a code-first setup: the model writes one Python script that invokes the same tools. Across 14 models on a 309-task BFCL v4 subset, programmatic calling matched or beat JSON in 11. The gap that should make every merchant sit up is the high-call regime. For Claude Sonnet 5, JSON issued every required call through a fan-out of 70, then started dropping calls. At 100 calls it fell to 0% enumeration accuracy. Python stayed at 100%. Sequential chains were faster for 13 of 14 models because dependent calls can run inside one script instead of burning another model turn after every tool result.

Builder X compressed it cleanly: JSON tool calling is an unnecessary bottleneck for capable agents. Shopping is that bottleneck wearing a cart.

Parallel overnight chatter made the same pattern commercial without the bench. Operators keep saying your catalog can look agent-ready while stock is a lagged spreadsheet — an AI shopper that cannot bind availability in one pass oversells you or skips you. Agent storefronts are already selling browse + stock + checkout as one surface, not a brand FAQ. And the price war (US labs cutting rates as open weights catch up) does not save a 70-turn fan-out. Cheaper tokens invite more agents to try — and to abandon whoever answers one SKU at a time.

I already argued that machine-readable merchants will eat brand-only merchants, that portable agent skills are not your commerce product, and that the write path is not a plugin. Stack the next layer. Structured fields get you seen. A skill package gets you invoked. Authority keeps money from leaking. An executable catalog is how you stay selected when the agent stops chatting and starts computing.

What the eval measured	What a merchant P&L should hear
JSON dies at ~70-100 sequential calls	A 20-SKU compare + stock + coupon + quote is already in the danger zone
One script keeps 100% enumeration	Agents will prefer surfaces they can program against
Extra model turns for every tool result	Your “agent API” is a token tax and a timeout

Why a Storefront Is a High-Call Job

Humans browse. Agents enumerate.

A human lands on a PDP, glances at three alternatives, and buys or leaves. An agent given “navy performance polo, ships by Friday, easy returns, under $80” does not glance. It lists, filters, binds, and quotes. That is 20 SKUs, 20 availability checks, shipping promises, return windows, coupon stack, tax, and a cart commit. Count the tools. You are already on the JSON cliff the paper measured.

If your agent surface is “ask me one question, I return one JSON object,” you have built a chatbot with SKUs attached. The agent that matters will write a loop. If your API cannot survive that loop — rate limits that look like DDoS, stock that is a nightly dump, policy buried in HTML, coupons that only exist in a browser cookie — the agent will not negotiate. It will route. Preference is the path with the fewest failed tool calls.

Unit economics make this worse, not better. Every extra model turn is COGS on the buyer side and infra on yours. A 70-call JSON fan-out is 70 chances to timeout, see stale inventory, or drop the coupon that closed the basket. A chat-shaped catalog manufactures empty shelves in software — the item existed; the agent could not bind it before the rate limit gave up.

Distribution follows the same math. Platforms can flip “agents can see your catalog” on by default. That is reach. Reach without a scriptable bind is a demo. The merchant who ships quote, hold, and policy as functions will look cheap and reliable. The merchant who ships 70 chat completions will look premium and broken.

Operator Playbook: Think Big, Step Small, Do Smart

Think big. The front door of commerce is becoming a program the buyer’s agent writes against your store. Preference will go to merchants whose catalog, inventory, and policy are callable as a unit: one script, one quote, one receipt. Everyone else will be a latency tax the agent learns to skip.

Step small (Monday morning). Do not rebuild the platform. Pick one quote path.

Write the cart as a function, not a conversation. Inputs: SKU list or intent, quantity, ship-to, one coupon. Outputs: price, tax, ship promise, return window, availability, quote_id. If an agent still needs seven tool calls to learn whether you can fulfill, you do not have a catalog. You have a FAQ.
Make availability a bind, not a field. A in_stock: true boolean from last night is a lie waiting for a flash sale. Expose live stock or a short-TTL hold. If you cannot hold, say so in the quote. Agents that cannot bind will either oversell you or leave.
Cap the chat surface. Keep JSON tools for one object: “get this SKU.” Put compare, stack, and quote behind a batch or script endpoint. The paper’s lesson is not “ban JSON.” It is “stop making the model take another turn for every dependent lookup.”
Log failed enumerations. When an agent asks for 15 SKUs and you answer 8, that is not a partial success. It is a lost shortlist. Count dropped calls the way you count cart abandonment.
Do not open the write path to the script. Quote and hold are not refund and markdown. An executable catalog is a read-and-reserve contract. Commit still hits a merchant-owned executor with a principal, a cap, and a receipt. Remix the query. Do not remix the till.

Do smart. Parallelize what is actually parallel — alt text, attribute cleanup — where one SKU does not depend on the next. Put a single quote assembler on price + stock + policy + coupon. That assembler is not another chatty agent. It is a narrower function: same inputs, same outputs, idempotent quote_id.

If you run a merchant stack this week, take your top 20 SKUs and a 30-line script, not a prompt. Can it list those SKUs, bind stock, attach the return window, apply one coupon, and return a cart quote without 20 sequential HTTP conversations? If not, fix that contract before you buy another “agent storefront” toggle. Kill criteria: more than ten model turns to quote a three-item cart; a quote that returned in-stock for a SKU you could not ship; a coupon that only worked in a browser.

The Claim Worth Arguing

A catalog that requires seventy JSON calls is not a storefront. It is a latency tax. Executable catalogs win the agent cart.

The counterexample I want: a merchant who exposed only one-shot JSON tools, let shopping agents fan out 50-plus calls per session, and still won shortlist and margin against a competitor who shipped a batch quote. If that exists at scale, I want the dropped-SKU logs.

Until then, I will build as if agents keep getting cheaper, call counts keep rising, and preference lives in a merchant-owned quote function — not in whichever chatbot wrapper shipped this morning.

If you disagree, bring the counterexample on X. Best failure mode wins — especially if your agent dropped the winning SKU at call 71.

Sources

Ishan Patel, Sahil Sen, Elias Lumer, Vamse Kumar Subbiah: The Bitter Lesson of Tool Calling (arXiv 2608.06370, Aug 6, 2026)
Secondary (X, Aug 15): builder summaries of the high-call JSON collapse vs programmatic tool calling
Secondary (X, Aug 14-15): operator posts on agent-ready catalogs vs live inventory, and agent storefronts that browse + check stock + checkout