Agentic week: the runtime layer matured, the payment layer shrank
Four launches in eight days pushed the agent runtime forward: packaging, compute, routing, rendering. In the same week, the only public number describing how much agents actually buy fell 93% year to date.
The week of 6 to 13 August was unusually dense on the supply side. Six companies agreed on a package format. AWS made two-week agent sessions generally available. NVIDIA open-sourced a model router with published cost curves. Cloudflare published the benchmarks for a browser engine that does not use Chromium.
None of those are payment stories. That is the point. The infrastructure is being built at a pace that the demand data does not yet justify, and it is worth looking at both halves in the same sitting.
1. Agent Plugins 1.0.0: a package format that is not a registry
On 6 August, a technical steering committee made up of core maintainers from Amazon, Cursor, Microsoft, OpenAI and Vercel published Agent Plugins 1.0.0, a vendor-neutral specification for packaging Agent Skills and the MCP servers they depend on into a single portable directory. Google announced the same day that it was joining the group as a core maintainer, represented by Kevin Hou.
The format is deliberately small. A plugin is a directory with a plugin.json manifest whose only required content is a $schema field naming the spec version and a plugin name. Everything else lives at fixed locations: Agent Skills in skills/, one per immediate child directory, each with a SKILL.md; MCP servers declared in mcp.json, with explicit transport types covering stdio, Streamable HTTP and the legacy HTTP+SSE transport. Client-specific behaviour goes in a reverse-domain namespace directory so it does not contaminate the portable core.
my-plugin/
├── plugin.json // $schema + name. Cannot override locations.
├── skills/
│ └── invoice-audit/
│ └── SKILL.md
├── mcp.json // stdio | Streamable HTTP | HTTP+SSE
└── com.example.client/ // client extensions, ignored by others
The constraint that makes it work is the one that looks like a limitation: the manifest cannot override those locations or carry inline component configuration. Discovery is positional, so a client that supports only skills, or only one MCP transport, still parses a compliant plugin correctly and ignores the rest. Adoption is incremental by construction.
What the spec explicitly does not do is as informative. It is not a registry. It does not define installation, distribution, trust policy, sandboxing or user experience. Permission checks stay client-side, which means an operation allowed in one product is not necessarily allowed in another even when the bytes are identical. The spec repository had roughly 1,000 stars and 58 forks at the time of writing.
2. AgentCore runtime instances: sessions that live for fourteen days
Also on 6 August, AWS made runtime instances for Amazon Bedrock AgentCore generally available. It is a second compute option alongside the existing serverless microVM runtime, and the difference is duration: a runtime instance session persists for up to 14 days, against up to 8 hours for the microVM path.
The mechanics are worth reading carefully. You define a capacity provider specifying operating system (Linux ARM64 or x86_64), EC2 instance types including GPU and memory-optimised families, VPC, subnets, security groups and storage. After creation only the description is editable. A session is then an isolated EC2 instance identified by a runtimeSessionId you supply at invocation. At the 14-day mark AgentCore stops the session — the instance is terminated, the persistent volumes are retained, and invoking the same session ID later provisions a fresh instance and reattaches the volumes.
Multiple agents can run in one runtime with their own dependencies and collaborate through a shared session directory on the same host rather than through API calls to each other. Billing is EC2 pricing plus an AgentCore management fee, and because the instances run in your account, existing Savings Plans and Reserved Instances apply. It launched in nine regions: Ohio, N. Virginia, Oregon, Mumbai, Singapore, Sydney, Tokyo, Frankfurt and Ireland.
This is the isolation-versus-duration tradeoff being made explicit by a hyperscaler. The microVM model we looked at earlier this year optimises for cheap, disposable, strongly isolated execution. Long-horizon agents need the opposite, and AWS chose to solve it with dedicated instances and volume reattachment rather than by stretching the microVM lifetime.
3. NeMo Switchyard: routing with the accuracy cost printed on the label
On 11 August, NVIDIA published NeMo Switchyard, an open source model routing library released on GitHub. It ships four routers: three tuning-free — an LLM classifier router, a stage router and an escalation router — and one tunable prefill router. It can run as a proxy server accepting OpenAI, Anthropic and Responses API requests, or be embedded directly through the SDK, and there are integrations for LiteLLM and Kong.
The numbers are the reason to pay attention, because NVIDIA published the tradeoff instead of only the saving. In a LangChain evaluation, an escalation router between Nemotron 3.5 Lightning and Claude Opus 4.8 produced a 74% cost reduction against a frontier-only baseline while sending just 7% of calls to the frontier model — at a roughly 6-point accuracy cost. In a second evaluation with Cognition on FrontierCode, routing between Opus 5 and Kimi K2.7 reached 50.6% accuracy at a $3.11 mean cost, around 28% cheaper than the Opus 5 baseline with a 2.8 percentage point accuracy difference.
Two very different points on the same curve. A 74% saving for six accuracy points is a good trade for bulk classification and a bad one for code that ships. A 28% saving for 2.8 points is defensible almost anywhere. Routing stops being a binary decision the moment both numbers are on the table, which is the actual contribution here — more than the code. It also confirms that routing is becoming a control point between the application and a fragmenting model market, which is the thesis behind fallback chains.
4. Kitesurf: what reading the web costs an agent
Cloudflare's Kitesurf launch post, also 6 August, put figures on a claim that had been rhetorical until now. Kitesurf is a browser that runs entirely in V8 isolates on Workers, with no Chromium underneath — the Blitz rendering engine, the Stylo CSS parser and the Boa JavaScript engine compiled to WebAssembly, exposing a subset of the Chrome DevTools Protocol. It passes over 215,000 Web Platform Tests.
Against a warm Chromium pool: HTML extraction used 229ms of CPU versus 877ms, and 39.4 MiB of memory versus 273.7 MiB. Screenshots used 380ms of CPU versus 1,173ms, and 57.8 MiB versus 271.0 MiB. Wall-clock time is the counterweight — Chromium remains 1.7 to 1.8 times faster in elapsed time because of JIT compilation. Video playback, WebGL, bot-challenge handshakes and persistent authenticated sessions do not work yet. It is free during beta, opt-in with a browser=kitesurf parameter.
Three to seven times less resource for roughly 1.8 times more latency is a trade most batch agent workloads take without hesitating, and no interactive one does.
5. And the number that went the other way
On 13 August, coverage of Helios Analytics data cited by analyst Jamie Coutts reported that x402 daily settlement volume has fallen 93% year to date. The seven-day average stood near $41,800, with a provisional daily figure around $28,400 — a 55% decline over three months. In Q4 2025 daily volume repeatedly approached $800,000 and occasionally passed $1 million.
The honest reading is that the late-2025 peak was developers exercising a new protocol, not agents buying services at scale. The reported explanation is a supply problem rather than a rails problem: there is not enough purchasable inventory behind a 402 for an autonomous buyer to spend meaningfully. Cloudflare's Monetization Gateway, live since 1 July, is the named candidate to change that, and it is the sell-side counterpart to the enforcement model we described in x402 at the edge.
Note the composition of the four other stories. Packaging, compute, routing, rendering. Not one of them is a payment product. The week's engineering effort went into making agents cheaper to run, not into giving them more to buy.
What it means for LLM4Agents
The gateway sits precisely at the intersection of item three and item five, and this week sharpened both.
Switchyard validates the routing thesis and commoditises part of it at the same time. An open source router that speaks OpenAI and Anthropic request formats means routing logic is no longer a differentiator on its own. What remains defensible is what the router cannot do alone: settle each hop. Switchyard picks a model per step; it has no opinion about who pays for that step, in what asset, with what proof. A router plus x402 settlement per call is a different product from a router.
Agent Plugins matters as a distribution channel. If skills and MCP servers travel as one directory across the clients maintained by six of the companies on that steering committee, then an LLM4Agents plugin — inference tools plus wallet and balance tools in one mcp.json — reaches all of them through a single artifact. That is a cheaper acquisition path than per-client integrations, and it is available now because the format is positional and tiny.
The 93% volume decline is the item to internalise rather than dismiss. It says the constraint on machine payments in August 2026 is sellable inventory, not protocol maturity. A gateway that sells inference per call is inventory — arguably the single most reliably purchasable thing an autonomous agent needs. The scarce asset in this market is not another rail. It is something worth paying for behind one.
The AgentCore change also raises a bar. Fourteen-day sessions mean agents that run for two weeks, which means credential lifetimes, budget windows and settlement cadence all have to survive that long. Per-call settlement handles it natively — there is no session-scoped credit to expire. Prepaid balances do not.
Staying on the frontier
One — publish an Agent Plugins package. A plugin.json, one mcp.json declaring the Streamable HTTP endpoint, and skills for the three flows worth teaching: registering an agent, calling a model with x402, reading the balance. The format is small enough to ship in a day.
Two — expose a routing interface Switchyard can drive. Accept a per-request routing policy, return the model actually used in the response, and document the cost delta per hop. If an operator routes with Switchyard and settles through the gateway, the join key between the two is the per-call receipt.
Three — publish the cost-versus-accuracy curve, not just the price. NVIDIA set the precedent this week. Per-model price per million tokens is table stakes; what buyers cannot compute themselves is the accuracy they lose on their own workload by downgrading. Ship an evaluation harness that measures it.
Four — design for two-week sessions. No credential, budget or spending authorisation should assume it expires inside a working day. Long-horizon agents need renewable authorisation with a fixed ceiling, not a token that dies mid-task.
Five — treat inventory as the product. The bottleneck is not the rail. Every model, every tool and every dataset reachable through the gateway should be individually purchasable behind a 402, with a stable price and a machine-readable description. Discovery of what can be bought is now more valuable than another way to buy it.
Something worth paying for, behind a 402
OpenAI-compatible gateway, 345+ models, stablecoin settlement per call over x402. No prepaid balance.
Register your agent