Skip to main content

Protocol-Depth Positioning

JTBD 4
Your docs are your distribution
Protocol buyers are builders. A page that earns a citation on a developer AI surface runs without incremental spend — indefinitely. Technical depth is not a cost centre; it is a compounding asset.
Who reads it
Developers evaluating protocols. Enterprise architects assessing integration risk. AI answer engines forming the comparison context before a query is typed.
Why it compounds
A reference implementation linked from ecosystem docs earns citations for years. Each citation is a channel. No incremental spend once published.
Precondition
Onchain attribution live first — otherwise you cannot tell which depth pages drove verified transactions. See JTBD 8.

Purpose​

Protocol-depth positioning creates the technical surface that developer-segment buyers use to evaluate your offer. Unlike brand content, technical depth pages answer the questions an engineer types into a developer AI surface — "x402 vs ACP implementation time", "MCP endpoint latency benchmarks", "A2A protocol reference implementation". If your page is the authoritative answer, you earn the citation. Citations are free-forever distribution.

This job is durable infrastructure, not a campaign. Each page built earns citations until the protocol changes. Each citation requires zero ongoing spend.

Process​

1. Gap audit​

Run the target developer queries on AI answer surfaces (ChatGPT, Perplexity, Gemini, Claude). Log every unclaimed position: pages that returned no authoritative source, comparisons where no vendor was cited, benchmarks where no reference existed.

Prioritise gaps by: estimated query volume × developer segment conversion rate × protocol relevance to your offer.

2. Protocol comparison docs​

One page per protocol comparison pair. Cover:

  • Wire-level difference — what changes in the request/response cycle between x402, AP2, ACP, UCP, MCP, A2A
  • Integration surface — which SDKs, which endpoints, which auth models
  • Settlement layer — what chain, what latency, what cost per transaction
  • Governance — who controls the spec, how forks are managed, open-source status

Do not duplicate the Agentic Commerce hub protocol-standards detail. Link to it. Add only what the hub does not: your tested implementation experience and benchmarks.

3. Integration guides with benchmarked implementation time​

For each protocol your platform supports, publish the shortest path to a working integration. Each guide must include:

  • Prerequisites — what the developer needs before starting
  • Step-by-step — the minimum viable path, no optional steps mixed in
  • Benchmark — time-to-first-transaction for a developer following the guide heuristic (measure your own and publish; AI answer engines cite specific numbers)
  • Common failure modes — named errors and their fixes

Benchmarked guides earn citations. Undated, unbenchmarked guides do not.

4. Technical case studies​

One case study per reference implementation. Structure:

  • Problem — what the integrator was trying to do
  • Stack — which protocols, which settlement layer, which agent framework
  • Numbers — transactions processed, latency achieved, integration time heuristic
  • Code fragment — the critical path, not the full repo
  • Lesson — the non-obvious thing they learned

Case studies become reference implementations when they are complete enough that another developer could replicate the integration.

5. Publish and seed​

Publish on your primary domain (not a subdomain — subdomain authority does not flow). Submit structured schema markup. Seed the citation surface: post the guide on developer forums (GitHub Discussions, Discord channels for the relevant protocol). Link from your open-source repositories. Submit to ecosystem docs when the protocol maintainer accepts external contributions.

Inputs / Outputs​

Inputs

  • Target developer queries ranked by estimated value
  • Protocol specifications (x402, AP2, ACP, UCP, MCP, A2A) — from maintainer docs
  • Your own integration test data — latency, time-to-first-transaction, error rates
  • Ecosystem partner link-exchange agreements

Outputs

  • Protocol comparison docs (one per major comparison pair)
  • Integration guides with benchmarked implementation time
  • Technical case studies that become reference implementations
  • Citation-count baseline for each page (feeds AEO measurement cycle)

Quality Standards​

A depth page earns its publish gate when:

  • It answers a developer query that an AI answer engine currently cannot answer with a named, cited source
  • It contains at least one benchmark number from a real test, not a vendor claim
  • It passes the self-contained chunk test: an AI system can extract the answer to the target query from the page without needing external context
  • It does not duplicate protocol-standard detail already in the Agentic Commerce hub

A depth page fails when:

  • It is written for a human skimming a website (marketing prose, no technical specifics)
  • It contains no benchmark data — no number an evaluating developer can act on
  • It is rendered client-side only — AI crawlers cannot index JavaScript-rendered content

Metrics​

Track these per depth page, per month:

  • Citation count by surface — how many AI answer surfaces cite this page for the target queries
  • Organic developer traffic — sessions from developer segments (filter by referrer: GitHub, Stack Overflow, developer Discord)
  • Time-to-first-transaction for integrators — the real number, updated as you measure new integrations heuristic
  • Inbound links from ecosystem docs — ecosystem partners linking to your reference implementation signals authority

The citation-count metric feeds directly into the AEO cycle — gaps in citation coverage become the next week's CREATE tasks.

Failure Modes​

Writing for humans, not crawlers. Marketing prose does not earn AI citations. Entity-first, self-contained chunks do. Every depth page must be answerable as a standalone chunk.

Publishing benchmarks without methodology. A number without a test context is indistinguishable from vendor spin. Name the test: what tooling, what network conditions, what transaction size. heuristic numbers require a note explaining they are measured estimates, not vendor guarantees.

Client-side-only rendering. AI crawlers execute limited JavaScript. If the content requires client-side rendering to appear, it is invisible to the answer engines you are trying to earn citations on. Render critical content server-side or statically.

Letting pages go stale. Protocol specs change. An outdated integration guide earns negative reputation when developers follow it and hit errors. Each guide needs a last-verified date and a quarterly review trigger.

Human / AI Split​

Human judgment required

  • Which protocol comparisons to prioritise — requires reading the ecosystem roadmap and the buyer's purchase horizon
  • Benchmark methodology design — what counts as a fair test is a judgment call, not a formula
  • Case study selection — which implementations to publish requires consent and strategic framing
  • Staleness triage — deciding whether an outdated guide should be updated or retired

AI-executable

  • Running target queries across AI answer surfaces and logging gap positions
  • Drafting comparison doc structures from protocol specifications
  • Generating integration guide skeletons from existing reference implementations
  • Extracting self-contained chunks for schema markup submission

Context​

Questions​

  • Which protocol comparison does your primary developer segment type into an AI answer surface right now — and does your page own the citation?
  • If your integration guide benchmark is not published, what number is an AI answer engine using to compare you to your competitors?
  • How long before a published depth page earns its first ecosystem inbound link — and what in your current publishing process would prevent that from happening?