AAM vs the alternatives.

Anthropic's protocol for giving an LLM a set of pre-installed tools at startup. The agent runtime loads each MCP server into context before the conversation starts.

You're building a focused agent that uses ~5 tools you control end-to-end (e.g. an internal IT helper that uses your custom company API). The user has the agent installed locally and can configure it.

The agent needs to discover and act on sites it's never seen before, in real time, without a pre-installation step. AAM is runtime-discoverable; MCP is install-time-bound. A power user with 30 services can't fit 30 MCP servers in context — but they can have the agent fetch 30 manifests on demand, only when relevant.

We ship `examples/mcp-bridge` — install one MCP server, get every AAM site. AAM and MCP are friends, not rivals; the bridge proves it.

Browser-as-a-service for agents. Run headless Chromium, click DOM elements, fill forms by selectors, screenshot the result.

The site you're targeting refuses to provide a structured surface. You need to scrape, fill, or extract from rendered HTML. Site owners are hostile or absent.

The site owner WANTS to support agents. AAM gives them a way to: declare actions explicitly, get structured input/output instead of brittle selectors, monetize agent traffic, audit who did what. Pixel-clicking is ~30% reliable; AAM is the consenting alternative.

An agent runtime can use both: AAM where available, browser fallback where not. Most likely future state for any general-purpose agent.

Hosted scraping infrastructure with pre-built actors per site (Amazon, Twitter, Google Maps). Pay per record extracted.

You need to extract public data at scale from sites that have no API. Site owners aren't in the loop.

You want to TAKE ACTIONS on a site (book, order, submit) — not just read it. AAM is action-oriented and consent-based; scraping is read-only and adversarial. AAM also gives you proper auth handoff and payment rails, which scraping fundamentally can't.

Different lanes. Apify reads sites that don't want to be read; AAM does business with sites that do.

Stripe's emerging product for letting agents pay on a user's behalf — buyer-side wallet with limits, audit, and dispute handling.

You're building an agent that needs to pay across many sites. You want Stripe's risk + dispute infrastructure on the buyer side.

AAM is the merchant side. You're a site that wants to ACCEPT agent traffic and possibly charge for it. AAM declares 'this action costs $0.05 USDC' or 'this action returns a Stripe Checkout URL'; the agent (potentially using Stripe's Agent Wallet on the buyer side) handles payment.

Strongly complementary. Stripe Agent Wallet on the buyer side + AAM on the merchant side = a working agent commerce loop. We use Stripe Connect for AAM-routed paid actions today.