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; Governance is implemented by the service, not prescribed by REST.
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.	Efficient binary messaging and typed service contracts; supports TLS and authentication.	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.	Structured XML messaging; can be combined with schema validation and WS-* security/policy standards.	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 can browse today; the future I am exploring gives negotiated exchange a much larger role. 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

REST, GraphQL, gRPC and SOAP describe different parts of an interface, not interchangeable governance packages. Applications can implement policy, billing and negotiation over them. The comparison below is about what each provides directly, not a benchmark of compliant implementations.

Architecture	Negotiation	Governance	Performance	Monetisation	Flexibility
REST	Application-defined; stateless requests can carry proposed terms.	Service-defined authorisation and 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.	Service-defined; encryption and typing do not establish usage policy.	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	Application-defined; SOAP messaging alone does not negotiate terms.	Separate policy/security standards and application controls.	Low. Verbose and heavy.	Application-defined billing and settlement.	Low. Poor developer usability and declining support.

Sources for the technical distinctions: GraphQL authorisation, gRPC authentication and SOAP’s messaging framework. The architectural preference is my interpretation.

Interpreting the fit

REST can carry declared purpose and support detailed service-side policy; it does not standardise the meaning of those terms.
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-based enterprise systems, with additional security and policy standards, offer lessons for the controls 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 enterprise policy standards express 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”

My current preference is GraphQL as a 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 can be useful, though it is not a requirement for agentic exchange.

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. SOAP defines a messaging framework. Enterprise systems added standards and application controls for security, policy and transactions around it. Those systems offer ideas worth carrying forward: explicit terms, validation and audit.

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 my proposed 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 is where models reason and applications use protocols such as MCP and ACP, 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 can express the terms of a purpose-aware exchange. It cannot prove the caller’s actual intent or prevent every downstream use after data is delivered. The design needs authenticated parties, policy enforcement, agreed obligations and ways to investigate misuse.

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 channel configured for security, such as gRPC with TLS, with application-level records for traceability.
Settlement, Any financial or reputational outcomes are logged, billed, or credited automatically.
Audit, The interaction is recorded for future reference, supporting checks against data-use agreements and regulatory requirements.

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 implemented through service controls and agreements. Caching managed manually through headers.	Each request carries an intent field (`citation`). The AIP gateway rejects training-related access and requires fresh responses and communicates cache restrictions. 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. Published records can support scrutiny without exposing sensitive request data.	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-based systems used additional standards to express terms.

The missing piece is a shared way to agree why, under what terms, and how value returns to the source.

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.