Which API architecture powers the agentic web

This note follows from The end of crawling, which argued that the open web of discovery is giving way to a web of negotiation.

If information will soon be accessed through consent and structured exchange rather than extraction, the next question is architectural: which type of API is best suited to power that future?

From crawling to negotiation

The traditional web was a world of extraction. Crawlers roamed public pages, harvesting whatever was accessible. Visibility was rewarded; structure was optional.

That model no longer scales or handles the complexity of an agentic web.

As large language models, agents, and knowledge systems interpret rather than index, the foundation of data exchange must shift from open scraping to consented retrieval. In this new environment, information is not discovered by force, it is granted by design.

APIs become the medium of that grant: structured, auditable, and bound by purpose.

The future of the web will depend on how well these APIs can define not just what data is shared, but why, under what terms, and to whose benefit.

What is an API

An API (Application Programming Interface) is the structured language by which systems agree to exchange information. It specifies what can be requested, how it is returned, and what rules govern that exchange.

Historically, APIs have been connectors, functional links between one database and another. They defined access, not intent. The assumption was simple: if you had the key, you could use the data.

That assumption is breaking.

As information becomes both an asset and a liability, the next generation of APIs must encode purpose, consent, and accountability directly into their design.

The current API landscape

APIs are not a single technology but a family of architectural styles, each optimised for a different mode of interaction.

Type	Definition	Strengths	Limitations
REST	Resource-oriented, stateless communication using standard HTTP methods.	Simple, widely adopted, flexible.	Inefficient for complex or nested queries; weak governance controls.
GraphQL	Query language allowing clients to specify exactly what data they need.	Efficient, reduces over-fetching; strong schema and type system.	Complex caching and rate-limiting; lacks native enforcement of data-use policy.
gRPC	Binary protocol over HTTP/2, designed for high-speed system-to-system communication.	Extremely fast, structured, secure; ideal for microservices and AI infrastructure.	Requires tight coupling between client and server; limited browser compatibility.
Webhooks	Event-based notifications triggered when predefined actions occur.	Lightweight, near real-time updates; efficient for alerts and triggers.	One-way communication only; lacks governance or negotiation layer.
Streaming APIs	Continuous, real-time data flow between systems.	Perfect for analytics, monitoring, and financial feeds.	Resource intensive; complex to monetise or control.
SOAP	XML-based protocol designed for formal, secure enterprise communication.	High compliance and security standards; strong schema enforcement.	Verbose and slower; declining in mainstream use.

What the agentic web demands

The web that is emerging is not defined by pages or links, but by transactions of intelligence. Models and agents do not browse; they negotiate. Every exchange carries intent, and every request has consequence.

This creates a new kind of interface between organisations and systems. Information is no longer something to be indexed, it is something to be licensed.

Each interaction becomes a structured transaction that must handle four fundamental dimensions:

Scope

What data is being requested? An agent must declare the specific context and type of information it seeks. This may include constraints such as freshness, depth, or commercial sensitivity.

Terms

Why is the data being requested, and how will it be used? Each request must include a declared use case such as:

Citation (used to inform an answer or reference source)
Commerce (used in a transaction or product comparison)
Training (used to improve or fine-tune a model)
Research (used for evaluation or testing)

Governance

Who is allowed to access the data, and under what controls? Governance includes permissioning, authentication, compliance, and auditability. It ensures data owners retain oversight of what has been shared, when, and for what purpose.

Measurement

What is the outcome of the exchange? Measurement captures how data contributes to visibility, commerce, learning, or other forms of value. It transforms the API from a simple data conduit into an instrument of feedback and accountability.

Comparing API types against future needs

Each API architecture was designed for a specific moment in the web’s evolution. REST simplified connectivity. GraphQL optimised data retrieval. gRPC accelerated internal communication. None, however, were built to manage purpose, consent, or negotiation.

Architecture	Negotiation	Governance	Performance	Monetisation	Flexibility
REST	Low. Requests are fixed and stateless.	Moderate. Supports authentication but limited in intent or policy.	Moderate. Reliable but inefficient for complex data.	Low. Needs external billing or tracking.	High. Easy to adopt and extend.
GraphQL	Moderate. Queries can express scope and detail.	Low. No native controls for usage or consent.	High. Efficient and structured.	Low. Monetisation handled outside schema.	High. Excellent for structured, nested data.
gRPC	Moderate. Can handle declared actions and permissions.	High. Encrypted, structured, and strongly typed.	Very high. Low latency and built for systems-to-systems.	Moderate. Could integrate transactional calls.	Low. Requires predefined schema and coupling.
Webhooks	Low. One-way communication.	Low. Relies on manual configuration and endpoint security.	Moderate. Event-based and responsive.	Low. Hard to meter or monetise.	Moderate. Simple and adaptable for alerts.
Streaming APIs	Moderate. Supports continuous delivery.	Low. Hard to enforce use rules once data flows.	High. Designed for real-time systems.	Low. Metering is complex and resource heavy.	Moderate. Excellent for analytics but not for control.
SOAP	High. Policy-driven with strict schema and security.	High. Strong compliance and validation.	Low. Verbose and heavy.	High. Built for enterprise transactions.	Low. Poor developer usability and declining support.

Interpreting the fit

REST remains the most common but offers little control over purpose or policy.
GraphQL brings flexibility and structure, yet lacks native mechanisms for consent or monetisation.
gRPC aligns well with the secure, high-speed requirements of agentic systems but is not yet suited for open interoperability.
SOAP, though legacy, foreshadowed the kind of compliance and audit trail the next web will require.

If the future of information exchange depends on declared purpose and controlled access, none of these architectures fully qualify on their own.

Each provides part of the answer: GraphQL defines what, gRPC manages how, and SOAP enforces terms. The agentic web will need an architecture that can do all three simultaneously.

The likely architecture

The agentic web will not emerge from a single architecture but from a synthesis of the strongest existing models. Each contributes an essential property: structure, speed, and accountability.

GraphQL, defining the “what”

GraphQL offers the most suitable framework for describing what an agent is requesting and why it needs it. Its query language allows precise selection of data fields, making it ideal for purpose-based retrieval.

Rather than requesting entire endpoints, an agent can specify exactly what is required to fulfil a task. This granularity is critical when managing privacy, licensing, or consent.

Yet GraphQL’s openness also exposes its weakness. It cannot inherently control the intent behind a query. A model could request information for legitimate reference or covertly for training, and the system would not know the difference. Governance, audit, and value exchange all sit outside the protocol.

gRPC, defining the “how”

Where GraphQL structures queries, gRPC defines how systems communicate. It provides a high-speed, binary channel for secure, low-latency interaction between services. In an environment where agents and models exchange data continuously, gRPC’s structured efficiency becomes a requirement rather than an advantage.

Its limitation lies in accessibility. gRPC is not web-native and depends on pre-defined schema contracts between participants. It is excellent for trusted, closed networks, but less suited for open ecosystems where agents must dynamically discover and negotiate with unfamiliar systems.

SOAP, defining the “terms”

SOAP represents a different lineage. It was designed for enterprise governance, built around compliance and security. Though cumbersome by modern standards, it introduced ideas that will return in the agentic era: policy enforcement, strict validation, and transaction auditing.

Its value is conceptual, not practical. The future will not reuse SOAP, but it will relearn from it. The next generation of interfaces will need SOAP’s rigour without its rigidity.

The synthesis

The most likely path forward combines the strengths of each:

Role	Model	Purpose
Structure and Scope	GraphQL	Define what data is requested and for what intent.
Communication and Security	gRPC	Ensure efficient, verifiable exchange between agents and organisations.
Governance and Terms	SOAP (conceptual)	Encode rules, permissions, and compliance into the transaction.

The hybrid of GraphQL for structure and gRPC for execution forms the technical core, while a new governance layer provides the missing legal and ethical boundary.

This is where the Agentic Interface Protocol (AIP) will sit, embedding policy, consent, and value into the transaction itself.

The role of the AIP

Within the architecture of the agentic web, the AIP sits inside the Organisation Layer, the part of the system responsible for governance, control, and measurement. (See The three layers of the agentic web for context.)

It defines how external agents, models, and browsers can interact with brand systems under declared terms of use.

If the Model Layer (through the MCP and ACP protocols) is where reasoning occurs, the Organisation Layer is where permission and accountability live. The AIP connects the two, turning data exchange into an auditable, enforceable relationship between human organisations and intelligent systems.

The function of the AIP

The AIP introduces a meta-protocol that operates above existing API architectures such as GraphQL or gRPC. It does not replace them; it governs them.

Where GraphQL defines what to access and gRPC defines how, the AIP defines why and under what terms.

Each transaction through the AIP carries a small but critical payload of metadata:

Metadata element	Purpose	Example
Intent	Declares why the request is being made.	`intent: "citation"` or `intent: "training"`
Permission	Confirms what level of access is granted.	`access: "public"`, `access: "partner"`
Monetisation	States whether the transaction carries a financial exchange.	`pricing: "pay-per-retrieval"`
Governance Rule	Defines the data owner’s restrictions.	`training_allowed: false`
Audit Trail	Logs who requested what and when.	`request_id`, `agent_id`, timestamp
Measurement Signal	Captures the value outcome of the interaction.	`impression: true`, `purchase: completed`

This metadata transforms a standard API call into a purpose-aware contract, enabling both sides to participate with clarity and trust.

How it could operate

Request, An agent issues a query through GraphQL (or similar), including declared intent and purpose metadata.
Negotiation, The AIP gateway evaluates the request against organisational policy, pricing, and governance rules.
Execution, If approved, the transaction is processed through a secure channel such as gRPC, ensuring the exchange is encrypted and traceable.
Settlement, Any financial or reputational outcomes are logged, billed, or credited automatically.
Audit, The interaction is recorded for future reference, ensuring compliance with data-use agreements and regulatory frameworks.

Why it matters

The AIP introduces the missing layer of trust between human organisations and machine intermediaries. It embeds policy, consent, and measurement into every interaction, creating a structured framework for data sharing that aligns technical systems with business logic.

In practical terms, it enables:

Organisations to define how their data may be used.
Models to declare their purpose transparently.
Ecosystems to measure and monetise value without manual intervention.
Regulators to audit and verify compliance in real time.

The AIP transforms APIs from open connections into governed relationships. It shifts the web from extraction to negotiation, from visibility to accountability.

Applied use cases

To understand how the AIP could operate in practice, it helps to view it through specific use cases. Each represents a different type of data owner with distinct goals, risks, and incentives.

Use case	Goals	Current approach (REST / GraphQL / gRPC)	With AIP	Outcome
B2B Marketer	Allow citation and discovery; restrict training access; ensure live price retrieval; no financial transactions.	Product data exposed via REST or GraphQL. Use policies defined in documentation, not enforceable by protocol. Caching managed manually through headers.	Each request carries an intent field (`citation`). The AIP gateway rejects training-related access and enforces `no-cache` for live data. All calls logged in an audit ledger.	Controlled discovery and compliance. Proof of responsible data use without added friction.
Publisher	Prevent training access; allow citation or summarisation for revenue; require monetisation and audit.	Paywalls, API keys, and third-party payment systems used separately. Logging and reporting managed manually.	Requests include declared purpose and payment type (`intent: citation`, `pricing: pay-per-retrieval`). The AIP gateway executes payment, logs access, and tracks revenue attribution.	Unified control, monetisation, and compliance within a single protocol.
Retailer	Enable product discovery and comparison; permit commerce intent; maintain live stock and price accuracy; measure conversions.	REST or GraphQL APIs handle listings and stock but rely on external affiliate tracking. Pricing accuracy depends on caching.	Each query includes `intent: commerce`. The AIP enforces real-time data pulls and triggers revenue-share events upon purchase. All performance metrics logged and reported.	Real-time commerce with verifiable attribution and accurate pricing.
Government / Open Data	Maximise transparency and accessibility; prevent misuse or commercial exploitation; require traceable access logs for accountability.	Open datasets served through public REST endpoints. Limited oversight or tracking of downstream use.	The AIP gateway defines usage rules (`intent: research`, `commercial_use: false`) and maintains an open audit ledger of all access. Compliance can be verified publicly.	Transparent access with traceable usage and built-in accountability for public data.

The AIP does not replace REST, GraphQL, or gRPC. It unifies them under a shared framework of governance, consent, and measurement. Each transaction becomes a verified record of purpose, permission, and value.

Incentive models

The exchange of information in the agentic web will not be driven by technology alone. It will depend on incentive alignment, the reason an organisation allows its data to be accessed at all.

Entity type	Primary incentive	Data behaviour	AIP functionality	Value measurement
B2B Brands	Visibility, citation, lead generation.	Open access to informational data, restricted access for proprietary materials.	Purpose-aware access (`intent: citation`) and audit control to prevent training use.	Attribution tracking and discovery analytics.
Retailers / E-commerce	Product sales and conversion.	Open exposure of catalog data, real-time accuracy required for stock and pricing.	`intent: commerce` with real-time data enforcement and transaction linkage.	Conversion tracking and revenue attribution per agent.
Publishers / Media	Monetised consumption and licensing.	Controlled access to articles or archives, strict prohibition on training use.	`pricing: pay-per-retrieval` or `subscription` fields with mandatory ledger logging.	Revenue by source, content performance, and compliance reporting.
Government / Open Data Providers	Transparency, accountability, and research access.	Broad accessibility with public verification and non-commercial use clauses.	`intent: research` and open audit ledger for traceable public use.	Engagement metrics, compliance validation, and policy reporting.
Education / Research Institutions	Knowledge dissemination and collaboration.	Moderate openness, governed by attribution and citation terms.	`intent: citation` with required attribution metadata.	Citation tracking and usage analytics.
AI Model Developers	Accuracy, reliability, and source diversity.	Consumption of verified, trustworthy data under defined use rights.	Adherence to AIP policies for training, licensing, and consent.	Model performance improvement and compliance audits.

When incentive alignment is handled at the protocol level, cooperation becomes the default rather than the exception.

Where this leads

The web is evolving from an environment of open discovery to one of negotiated exchange. What began as a network of documents is becoming a network of contracts. Every data interaction will carry purpose, permission, and provenance.

Crawling rewarded exposure. The agentic web will reward clarity, clarity of intent, structure, and value. Information will flow not because it is public, but because it is trusted.

APIs are the foundation of this shift. They turn data into a service, and a service into a relationship. When combined with the governance capabilities of the AIP, they also make that relationship accountable.

In practical terms:

Organisations will define how their data can be used and for what intent.
Models and agents will declare their purpose before accessing information.
Transactions, whether financial or reputational, will be measured and verified.
Regulators will have a transparent record of every exchange.

This architecture reintroduces responsibility into automation. It aligns human systems of governance with machine systems of intelligence.

The shift in structure

Old web	New web (agentic)
Crawling and indexing.	Negotiation and transaction.
Visibility as the goal.	Value and compliance as the goal.
Pages optimised for humans.	Interfaces optimised for agents.
Access defined by openness.	Access defined by permission.
Limited transparency on usage.	Full auditability of intent and outcome.

The agentic web will not appear suddenly. It will emerge gradually as existing APIs become more aware of the context and consequence of their exchanges. The Agentic Interface Protocol represents a framework for that transition, a way to bring intent, governance, and value into the same conversation.

It is not about replacing today’s APIs, but about redefining what they mean.

What’s still open

If the next web is to be built on negotiation rather than extraction, which API architecture can hold not just data, but intent, permission, and value?

GraphQL defines what is requested.
gRPC defines how it is delivered.
SOAP once defined the terms.

None yet define why.

That missing layer will become the foundation of the agentic web. An Agentic Interface Protocol that governs how data moves between organisations and intelligent systems. A system where every interaction carries context, every transaction leaves a record, and every exchange is both useful and accountable.

Information will no longer be scraped or served. It will be shared, audited, and earned.

This field note is part of an ongoing exploration. Future notes will extend into adjacent areas: decentralised architectures, the economics of API-level monetisation, security and compliance, and a move from concept to early specification of the AIP itself.