Learning Path

Four patterns are visible in what companies publicly shipped for agents through 2025 and 2026: developer-tools companies rewrote documentation to be machine-readable; platforms shipped official MCP servers rather than leaving integration to third parties; agentic commerce reorganized around the merchant’s own checkout after the fully-in-chat version underperformed; and security research established that there is no clean boundary between a user’s instruction and the untrusted content an agent reads. The first two are cheap and worked. The third says where transactions actually happen. The fourth constrains everything else.

A note on method. This page describes publicly observable work — things companies shipped, published, or documented — and what the pattern implies. It deliberately contains no performance metrics, conversion figures, or before-and-after numbers, because credible measurements of agent-driven outcomes are not publicly available for most of these efforts. Where the specific attribution is uncertain, the pattern is described without naming a company.

1. Documentation rewritten for machine readers

The earliest and most widespread pattern came from developer-tools companies, and it was driven by a specific, measurable pain: coding agents were writing wrong code against their products. Whatever a model absorbed during training was frozen at some past version, and the current documentation — rendered by a client-side app, wrapped in navigation, split across interactive tabs — was hard to read at runtime.

The response converged on a few moves that are now common across the category: publishing an llms.txt index of documentation, serving a plain-markdown representation of every docs page alongside the HTML one, and shipping official MCP servers that let an assistant query current documentation instead of recalling old training data. Several developer platforms adopted some or all of this; the convergence is the interesting part, not any single company’s version.

The lesson

Documentation stopped being a support cost and became a distribution channel. If an assistant cannot read your current docs, it will confidently generate code against a version of your product that no longer exists, and the developer will experience that as your product being broken. The work is unglamorous — a text representation, a stable index, no client-side rendering requirement — and it has the best effort-to-effect ratio of anything on this page.

2. Platforms shipping their own MCP servers

The second pattern is platforms publishing first-party MCP servers for their own products rather than waiting for community wrappers. Cloud providers, databases, developer platforms, design tools, and SaaS applications all did versions of this through 2025 and 2026, and the motivation is consistent: a third-party wrapper generated from an API spec exposes your endpoints, not your capabilities, and gets your authorization model wrong.

What distinguishes the good implementations from the mechanical ones is visible in the tool list. A wrapper offers dozens of tools named after routes. A designed server offers a small number named after the things users ask for, with descriptions that say when not to call them, schemas that make invalid calls impossible to express, and consequential operations marked as such so the host application knows to ask the user first.

The lesson

Owning the integration means owning the authorization model, the scoping, and the audit trail — which is exactly what you cannot delegate to a community wrapper. It also means the tool surface is a product decision. Treat the tool list the way you would treat a UI: fewer, clearer, task-shaped affordances, and no exposed internals.

3. Agentic commerce: the retreat that clarified everything

The most instructive story of 2026 is a partial failure. OpenAI’s Instant Checkout launched on the premise that the entire purchase — discovery, selection, payment — could happen inside the chat interface. Around March 2026, after weak conversion, it was scaled back to a different shape: discover in chat, buy on the merchant’s own site.

What is telling is what survived. The Agentic Commerce Protocol — the specification for how an agent and a merchant exchange product, cart, and order information — did not go away with the in-chat checkout. The plumbing was sound; the placement of the transaction was not. Meanwhile the merchant side consolidated: Google’s Universal Commerce Protocol coalition, with Shopify and major retailers, became the centre of gravity, and Universal Cart launched in May 2026.

Two plausible readings, and both point the same direction. Buying involves trust, account state, loyalty, returns, and payment credentials that live with the merchant; stripping the transaction out of that context removed reassurance the customer needed. And merchants had little enthusiasm for a model that made them a fulfillment backend for someone else’s storefront.

The lesson

The agent’s strength is discovery, comparison, and reducing the option space — not necessarily executing the final consequential step. For most services the practical implication is asymmetric investment: make the reading path excellent, so agents can find and correctly describe what you sell, and make the handoff into your own checkout frictionless rather than trying to relocate the transaction elsewhere. Build against a protocol if it fits, but design so that a change in where the transaction happens does not invalidate the work.

4. Prompt injection: the constraint on all of it

Brave’s security research is the cautionary case, and it should be read before designing any agent-facing capability. In August 2025 Brave documented indirect prompt injection against Perplexity’s Comet browser: content embedded in a web page — not typed by the user — was interpreted by the agent as instructions and acted upon. In October 2025 they demonstrated “unseeable” screenshot-based injections, where the instruction is present in what the agent perceives but not in what the human sees.

The finding that matters is more general than any single bug: there is no clean boundary between a trusted user instruction and untrusted page content. Both arrive as text in the same context window. An agent that reads the open web while holding the authority to act on the user’s behalf is structurally exposed, and no amount of filtering fully closes that gap. This is not a defect of one browser; it is a property of the architecture.

The lesson, for services rather than agent vendors

Do not rely on the agent to be the safeguard. Enforce authorization, scoping, and limits on your side, where they cannot be argued out of by injected text.
Keep consequential operations behind explicit user confirmation regardless of how they were invoked. “The agent asked nicely” is not authorization.
Remember that user-generated content on your own site is an injection surface for every agent that reads it. A review field, a support thread, or a profile bio can carry instructions aimed at someone else’s assistant.
Scope grants tightly enough that a successful injection has a small blast radius. This is the practical reason least privilege is on the principles list.

What the four have in common

The cheapest work — making content and documentation machine-readable — produced the clearest wins. The ambitious work — relocating transactions into the assistant — ran into the parts of a purchase that are about trust rather than mechanics. The security research says the constraint is structural rather than temporary, so the responsible design keeps enforcement on the service side. That ordering is a reasonable default for planning your own work: readability first, owned capability surface second, autonomous consequential action last and carefully.

Implementation Patterns Back to Applications

Stay Updated

Analysis of AI search, crawler policy and agent standards — sent when there is something worth reading, roughly twice a month. Unsubscribe anytime.