Prime the pump for an agent-native web.

Most of the web still assumes a human is the one reading it. Agents are arriving anyway, and they do not browse. They discover, evaluate, invoke, verify, and pay. The services that win that traffic will be the ones that stop publishing pages for agents to interpret and start publishing capabilities for agents to call.

That is the central move. Everything else in this guide is groundwork that improves one ratio:

agent preference = (task value x success rate x trust x distribution)
                   / (integration effort x latency x price x risk)

The ratio is a reasoning aid, not a measured benchmark. It earns its keep by forcing one question about every artifact you publish for agents: which term does this move? Here are the eight moves that move it most.

1. Give every service a machine-readable storefront

A domain should answer six questions without a human reading anything:

• What information do you have?
• What actions can you perform?
• What inputs do those actions require?
• What will they cost?
• What permissions and side effects are involved?
• How can the result be verified or reversed?

Start with structured data on the pages you already have. Schema.org describes entities, relationships, and actions, and JSON-LD is the format Google recommends for structured data. For a service, expose endpoints close to:

• /openapi.json for the API description
• /docs/agents for integration notes written for machine consumers
• /sandbox for a safe place to practice
• /status for machine-readable health

For a remotely callable agent, the A2A specification publishes an Agent Card at /.well-known/agent-card.json: identity, skills, endpoints, authentication requirements, and supported protocols, in one discoverable document.

2. Support the three interface layers

Do not bet everything on one protocol. Three layers are settling out, and they complement rather than compete:

• OpenAPI describes conventional HTTP APIs. "Here are my endpoints."
• MCP standardizes how AI applications connect to tools and data. "Here are the tools and resources a model can use."
• A2A handles discovery and delegation between separate agents. "Here is the specialized agent another agent can hand work to."

A service that publishes all three lets an integrator adopt at whichever layer they operate, with almost no translation cost.

3. Publish small, typed capabilities

A weak agent interface looks like this:

do_anything(prompt: string)

It cannot be ranked, secured, priced, evaluated, or recovered. A stronger commerce surface exposes narrow, named operations:

search_inventory
get_current_price
get_quote
reserve_item
purchase_item
check_order_status
cancel_order

A reservation contract might look like:

{
  "item_id": "sku_123",
  "quantity": 2,
  "maximum_total": 12000,
  "currency": "USD",
  "expires_at": "2026-07-22T18:00:00Z",
  "idempotency_key": "agent-task-8492"
}

And its response:

{
  "reservation_id": "res_9281",
  "total": 11400,
  "currency": "USD",
  "expires_at": "2026-07-22T18:00:00Z",
  "requires_confirmation": true,
  "cancellation_supported": true
}

Every capability should specify input and output schemas, whether it reads or changes state, required authorization scopes, expected price and latency, confirmation requirements, idempotency behavior, retryable versus terminal errors, a cancellation or compensation operation, and data freshness and provenance. That list is the difference between a tool an agent can plan around and a black box it has to gamble on.

4. Make safe action easier than browser automation

Agents will not become a durable transaction channel if every action requires handing over unrestricted account access. The safer alternatives are already known: narrow task-specific scopes, short-lived credentials, explicit user consent, spending and quantity limits, dry-run or quote modes, confirmation before consequential actions, immutable audit records, idempotency keys, revocation, and human escalation for ambiguous cases.

Delegated, limited access is what OAuth exists for, and the OAuth 2.1 draft centers exactly this: access granted on behalf of a resource owner, bounded by scope. A useful authorization request is not "Allow this agent to access your account?" It is "Allow Travel Agent X to reserve one refundable room, up to $350, for August 12 to 14, without completing payment?" The second version makes authority inspectable and bounded, and it survives an audit.

5. Give agents the information required to choose you

Human landing pages say fast, trusted, and affordable. Agents need fields they can compare:

{
  "price_model": "per_completed_booking",
  "estimated_price": 0.30,
  "p95_latency_ms": 1800,
  "availability": 0.9995,
  "coverage": ["US", "CA"],
  "supports_dry_run": true,
  "supports_cancellation": true,
  "data_updated_at": "2026-07-22T16:40:00Z"
}

Alongside the comparable fields, publish known limitations, service-level targets, rate limits, supported jurisdictions, data-retention policy, version and deprecation dates, example successful and unsuccessful calls, and a machine-readable status endpoint. The competitive unit this converges on is cost per successfully completed task, not cost per API call or per token.

6. Seed demand in one vertical, not everywhere

The cold start is real. Agents will not integrate against a surface just because it exists. The strategy that works is vertical, not universal:

• Step 1. Pick one repeated, valuable workflow: freight quoting, appointment scheduling, procurement, travel changes, compliance checks.
• Step 2. Define five to ten normalized capabilities for that workflow.
• Step 3. Integrate several providers yourself, even where their current interfaces are poor.
• Step 4. Expose one consistent agent-facing contract.
• Step 5. Route work by price, reliability, and user constraints.
• Step 6. Send providers measurable traffic, conversions, and revenue.
• Step 7. Show them which calls failed and which capabilities agents requested.
• Step 8. Let providers replace your adapter with a native implementation.

The loop compounds. More providers bring better coverage and completion, which makes agent workflows more useful, which brings more agent traffic and transactions, which sharpens the financial case for native interfaces, which brings more providers. Do not begin with a generic agent directory. Begin with a vertical transaction graph that already produces outcomes.

7. Create public proof

Agents and their developers need evidence that an integration works before they route real tasks through it. For each capability, maintain an evaluation set that covers normal requests, missing or contradictory inputs, stale inventory, authorization failures, duplicate submissions, timeouts, partial completion, cancellation, provider outages, and adversarial instructions.

Then publish the aggregate metrics and their direction of travel: discovery-to-first-success time falling, first-call success rate rising, end-to-end task completion rising, human correction rate falling, authorization abandonment falling, cost per completed task falling, retry recovery rising, repeat-agent usage rising, and unauthorized-action rate holding at zero.

Public, reproducible evaluations persuade. Claiming to be agent-ready does not.

8. Avoid the dead ends

Do not build the ecosystem around scraping unstable interfaces, giant untyped prompt endpoints, hundreds of overlapping tools, hidden prices or rate limits, long-lived master credentials, actions without confirmation or rollback, silent schema changes, opaque errors, content written only to manipulate model citations, or agent-only claims that contradict the human-visible page. Every one of those pushes the preference ratio the wrong way for every agent that touches you.

What we run ourselves

Rarefied Earth applies this pattern at company scale before arguing for it at web scale. Groundwork, the operating substrate we deploy, serves a company's brand, voice rules, operating charter, current priorities, and module inventory to any MCP client through a read-only, per-tenant, rate-limited connector. An agent working for that company starts from published capability instead of a blank page. The thesis in this piece is the same shape pointed outward: a web where domains publish what they can do, what it costs, and what proof exists that it works.

Honest limits

• The protocol layer is young. MCP and A2A are moving targets, and OAuth 2.1 is still an IETF draft. Design for versioning and deprecation from day one.
• The preference ratio is a reasoning aid, not measured data. Agent-traffic benchmarks mostly do not exist yet, so instrument your own completion and correction rates rather than quoting anyone else's.
• Agent-initiated payment is the least settled piece. Publish quotes and reservations even if the final payment confirmation stays with a human for now.
• The cold-start work in move six is real integration labor with real cost. Nothing here removes it. The point is to spend it where a transaction graph already produces outcomes.

The web starts working for agents when useful domains emit a clear machine proposition: here is what I can do, here is the contract, here is the current price, here is the authority required, here is proof that it worked, here is how to undo it. That is the groundwork. The pressure that makes everyone else follow comes from attaching real traffic and revenue to it.