Agentic Web: Weaving the Next Web with AI Agents

TL;DR

For thirty years the web optimized for human attention: PageRank ranked pages for human eyes, recommender feeds curated content for human scrolling, and the entire ad economy monetized human clicks. This paper argues that LLM-powered agents break that model. Instead of a human navigating pages, you delegate a goal (“plan a 3-day trip to Beijing”) to an agent, which decomposes it, discovers and calls services, coordinates with other agents, and returns a finished result. The authors organize this “Agentic Web” along three dimensions — Intelligence (the agent reasons/plans/learns), Interaction (agents talk to tools and to each other via new protocols like MCP and A2A), and Economics (services compete for agent invocation, not human clicks — the “Agent Attention Economy”). It is a survey, not a new algorithm, but it’s a usefully opinionated map: it names the architectural shift (Client-Server → Client-Agent-Server), the protocols that matter, the unsolved problems (agent discovery, cross-agent billing, security), and where the money moves. If you sell agentic systems, this is the territory map for the next five years.

Problem & Motivation

The concrete pain: today’s web infrastructure was built for humans, and agents are square pegs in round holes.

Walk through booking a trip the old way: you open five travel sites, compare fares, check loyalty points, reconcile your calendar, and stitch confirmation emails together. Every step is a human reading a human-facing page and clicking. The web’s primitives — HTTP request/response, stateless APIs, HTML rendered for eyeballs, hyperlinks declared in advance — all assume a human operator in the loop making each decision.

Now hand that whole job to an agent. Four things immediately break:

1. Discovery. Web resources live at stable IPs and domains. Agents are ephemeral — they spin up, do a job, vanish. When your agent needs a capability it doesn’t have (say, real-time flight pricing), how does it find a suitable collaborator agent or service in a vast, churning population? DNS doesn’t answer “who can price flights for me right now?”
2. Semantics. Today’s APIs give you syntactic interoperability — they define the shape of the JSON — but not semantic interoperability. A human dev reads the docs and figures out that uid means the user ID. An LLM agent has to infer intent from a schema with no machine-readable meaning, and it does so non-deterministically (formatting drift, hallucinated fields). HTTP/RPC carry data, not meaning.
3. Long-running, asynchronous, interruptible tasks. A deep-research agent or a trading-strategy agent runs for minutes to days, needs to pause for human confirmation on a risky step, and emits intermediate results. HTTP’s synchronous request/response model has no native concept of “suspend until the user approves.” You bolt on polling and webhooks and the system gets brittle.
4. Billing and economics. When one command spawns sub-agents that delegate to other agents that call paid services, who pays for what? There’s no auditable ledger that traces resource consumption across a fluid multi-party agent mesh, and no way to give a user a cost estimate before a potentially expensive task (“bill shock”).

Prior framings (the “Semantic Web,” generic multi-agent systems, plain LLM-agent papers) each touch a piece, but nobody had laid out the whole transition — capability layers, protocols, economics, and risk — as one coherent map. That’s the gap this survey fills.

What’s New (Core Contribution)

This is a survey/framework paper, so its contribution is conceptual structure, not a new model or benchmark. Four genuinely useful pieces of structure:

• The three-era framing with a shared lens (search → recommendation → action). Before: people described “Web 1.0/2.0/3.0” loosely. Now: a crisp argument that each era is defined by what gets optimized and monetized — PC Web optimized search (PageRank, PPC ads, human clicks), Mobile Web optimized recommendation (collaborative filtering → deep models, attention economy, human engagement), Agentic Web optimizes action (multi-agent orchestration, MCP/A2A, agent invocation). The through-line is attention flow: who/what the system competes to capture.
• The three-dimension model: Intelligence / Interaction / Economics. Before: agent capabilities were discussed as a grab-bag. Now: a layered stack where intelligence enables interaction, and interaction enables value creation. It’s a clean mental model for deciding which layer a given technique or product lives in.
• The Client-Agent-Server architecture and the Agentic Web Roadmap. Before: client-server. Now: the paper argues the classic two-party model is invalidated and proposes a concrete three-party reference architecture with named components — a Demand-Skill Vector Mapper (turns app needs into machine-readable skill vectors), a Real-Time Task Router (dispatches tasks to a distributed agent framework across edge/cloud), and a Cross-Agent Billing Ledger (metering, service chaining, privacy-preserving settlement).
• The “Agent Attention Economy.” Before: ad-tech competed for human clicks. Now: the paper names and develops the hypothesis that tools/services/agents will compete for agent invocation — spawning agent-facing recommendation engines, capability re-ranking, inter-agent referral networks, and auction-based ranking. For anyone selling AI services, this is the most commercially load-bearing idea in the paper.

It also gives the clearest side-by-side of MCP vs. A2A I’ve seen in a survey, and a layered threat/defense taxonomy for security. Be honest about the limits: there’s no new system built, no experiments, no numbers the authors generated themselves. The value is the map, not a measurement.

How It Works (Technically)

There’s no single algorithm here, so “how it works” means how the Agentic Web is wired — the architecture, the protocols, and one task traced end to end. This is the heart.

The three conceptual dimensions (the capability stack)

Think of it as three layers, each built on the one below:

• Intelligence Dimension — the cognitive engine inside a single agent. Five capabilities the paper calls out: contextual understanding (parse NL, semi-structured data, UI signals), long-horizon planning (multi-step strategies you revise as you go), adaptive learning (improve from feedback), cognitive/metacognitive processes (monitor and correct your own reasoning), multi-modal integration. Operationally this is your LLM + memory + planner + reflection loop. Knowledge lives both in-parameter (pretrained weights) and external (tools/APIs/RAG).
• Interaction Dimension — how the agent reaches outside itself. Two sub-problems: agent-to-resource (calling tools and services — this is MCP’s territory) and agent-to-agent (coordinating with peer agents — this is A2A’s territory). The key shift: from static hyperlinks declared in advance to runtime semantic discovery — the agent finds capabilities by meaning, not by a pre-wired URL.
• Economic Dimension — agents as economic actors that initiate transactions, form coalitions, and allocate resources without a human in the loop. This is where the Agent Attention Economy and cross-agent billing live.

A simple way to remember it: intelligence is what an agent is, interaction is what it does to the world, economics is what it exchanges.

Architecture & data flow

The paper’s structural claim is that classic client-server doesn’t survive: you need a middle tier that is an autonomous reasoner. The new shape is Client → Agent → Server, with the agent as master orchestrator.

flowchart TB
  subgraph Client["User Client"]
    U["User: 'Plan a 3-day trip to Beijing'"]
  end
  subgraph AgentTier["Intelligent Agent Tier"]
    P["Request Parser<br/>extract: dest, duration, intent"]
    O["Tool Orchestrator<br/>decompose into sub-tasks"]
    S["Result Synthesizer<br/>aggregate + check constraints"]
  end
  subgraph Backend["Backend Services (via MCP)"]
    W["Weather Service"]
    G["Travel Guide Service"]
    H["Hotel Service"]
    M["Map Service"]
  end
  U --> P --> O
  O -- MCP call --> W
  O -- MCP call --> G
  O -- MCP call --> H
  O -- MCP call --> M
  W --> S
  G --> S
  H --> S
  S --> U
  M -. direct low-latency channel .-> U
  O -. discover peer agents .-> A2A["Peer agents via A2A<br/>(AgentCard discovery)"]

Note the two pathways: synthesized results (weather + guide + hotel) flow through the synthesizer for high-level planning, while the interactive map streams directly to the client for low latency. That dual-path design — orchestrate centrally, but let the client talk straight to a service when latency or sensitivity demands it — is a pattern worth stealing for your own systems.

How MCP actually works (agent ↔ resource)

MCP (Model Context Protocol, Anthropic) standardizes how an agent calls tools/data. Four roles:

• Host — the LLM agent that talks to the user, reasons, and decides which tool to call. One host owns multiple clients.
• MCP Client — a connector; one client holds exactly one connection to one server.
• MCP Server — wraps a Resource and exposes its capabilities to the client.
• Resource — the actual tool/data/service (a filesystem, a dataset, an image generator).

The lifecycle is capability negotiation, then a request loop, then teardown:

1. Init / capability declaration. Client connects to a server and announces what it can do; the server replies with its capabilities (available tools, their input/output schemas, prompt templates, usage constraints). Now both sides know the boundary of what’s possible this session. This is the step that fixes the semantics problem — the agent gets machine-readable interface specs instead of guessing from human docs.
2. Request loop. The Host decides (from the user or from its own reasoning) it needs a capability → sends a strategic context request to a Client → Client turns it into an executive context request and hits the Server → Server runs the Resource and returns → Client passes result back to Host → Host updates UI or feeds the model. Repeat in parallel multi-loops.
3. Notification loop. If a Resource changes (e.g., a file updates), the Server pushes a notification so the Host stays current — this is how MCP supports liveness, not just one-shot calls.
4. Teardown. Host tells all Clients to end; Clients send session-end to Servers.

The payoff: instead of every LLM/tool vendor having a bespoke calling convention, MCP gives one Client-Server contract, killing fragmentation and raising semantic accuracy.

How A2A works (agent ↔ agent)

A2A (Agent-to-Agent, Google) handles direct collaboration between heterogeneous agents — different frameworks, different vendors. Four primitives:

• Agent Card — a public JSON document at a known URL describing an agent’s functions, endpoint, auth methods, and metadata. This is the discovery mechanism: an agent reads cards to find collaborators whose capabilities match the task. (Cards can embed Decentralized Identifiers (DIDs) for cryptographically verifiable identity without a central registry — “self-sovereign” auth.)
• Task — a unit of work with a unique ID whose status updates over multiple rounds. This is what makes long-running, stateful work first-class.
• Message — a communication object with a user/agent role, containing multiple Parts (text, files, structured data). Messages carry the current task ID and a list of related task IDs, creating a bidirectional link between messages and tasks — that’s how A2A traces context across multi-turn, multi-agent workflows.
• Artifact — the finished deliverable an agent produces (distinct from a Message, which is dialogue).

Workflow: client agent gets a query → creates a Task with an ID → fetches Agent Cards to find matching remote agents → exchanges Messages to collaborate → Task state updates in real time (client can subscribe to async progress events, including pause-for-user-confirmation) → result delivered as an Artifact.

MCP vs. A2A in one line: MCP connects an agent to tools/resources (vertical, loosely coupling task and message); A2A connects an agent to other agents (horizontal, tightly coupling task↔message for robust multi-party coordination). They’re complementary — in a real system an A2A mesh of agents each uses MCP to reach its tools.

Schematic: how "attention flow" reshapes across the three web eras. Toggle eras to see the path of value move from human-search → human-feed → agent-orchestration. Illustrative, not from the paper's data.

The algorithm, simplified

There’s no training loop to show, but the orchestration loop is the operational core. Here’s the Client-Agent-Server flow for the trip example, written the way you’d actually build it — agents discovered via A2A, tools called via MCP:

# The orchestration loop that IS the Agentic Web pattern.
# Stubs: llm(prompt)->str, mcp_call(server, tool, args)->dict,
#        discover_agents(capability)->list[AgentCard], a2a_send(card, msg)->Artifact

def handle_goal(user_goal: str):
    # 1. PARSE: turn a fuzzy human goal into structured intent
    intent = llm(f"Extract destination, duration, constraints as JSON:\n{user_goal}")

    # 2. DECOMPOSE: master agent breaks the goal into sub-tasks (this is planning)
    subtasks = llm(f"Decompose into independent sub-tasks:\n{intent}")  # e.g. weather, hotels, route

    results, direct_to_client = {}, {}
    for task in subtasks:
        # 3a. If we have a local/known tool, call it directly via MCP
        server = registry.match(task)              # capability discovery (the hard part)
        if server:
            out = mcp_call(server, tool=task.tool, args=task.args)
        else:
            # 3b. Otherwise recruit a peer agent: read AgentCards, pick one, delegate via A2A
            cards = discover_agents(capability=task.capability)   # just-in-time matchmaking
            best  = max(cards, key=lambda c: fit(c, task))        # skill/readiness/cost scoring
            out   = a2a_send(best, message=task)                  # async; can pause for user OK

        # some outputs (a live map) bypass synthesis and stream straight to the user
        (direct_to_client if task.low_latency else results)[task.name] = out

    # 4. SYNTHESIZE: fold results against the user's constraints into one coherent answer
    answer = llm(f"Assemble an itinerary from {results}, honoring {intent['constraints']}")
    return answer, direct_to_client

The two genuinely hard lines are registry.match(task) and discover_agents(...) — capability discovery and just-in-time matchmaking. Everything else is plumbing the field already knows how to build; discovery is the open research frontier (and, the paper argues, the seed of the Agent Attention Economy, because that’s exactly the function services will compete to influence).

Built on Prior Work

The paper is a synthesis, so its lineage is broad. The most load-bearing borrowings:

The intellectual move is consistent across the paper: take a human-centric web primitive and ask what it becomes when the active party is an agent.

Results & Evidence

Set expectations correctly: this paper has no experiments and reports no numbers the authors produced. It’s a survey + position paper. The “evidence” is (a) a comprehensive citation map of the field, (b) comparative tables (web eras; MCP vs. A2A; threat taxonomy), and (c) a worked architectural example (the Beijing-trip orchestration).

What the evidence does establish:

• That a real, citable body of work now exists across every layer it names (retrieval, planning, multi-agent, protocols, security) — the Agentic Web isn’t vaporware, the pieces exist.
• That MCP and A2A are emerging as de-facto standards with distinct, complementary designs.
• A coherent vocabulary and reference architecture other builders can adopt.

What it does not establish:

• That the Client-Agent-Server reference architecture (Demand-Skill Vector Mapper, Real-Time Task Router, Cross-Agent Billing Ledger) actually works at scale — it’s proposed, not built or measured.
• That the Agent Attention Economy will materialize as described — it’s a reasoned hypothesis.
• Any quantitative claim about agent reliability, cost, or task success in production. The benchmarks it cites (WebArena, Online-Mind2Web, WebJudge with ~85.7% human agreement) are other people’s results, included as field context.

Treat it as a well-sourced map, not a validated system. For a survey that’s exactly the right job — just don’t cite its architecture as a proven design.

How You’d Use It

For an AI services company, this paper is most useful as a product and positioning map. Concrete slots:

• Client offering: “agent-ize your services.” The Agent Attention Economy thesis says any business with an API will soon want to be discoverable and selectable by agents. That’s a service: wrap a client’s catalog/API in an MCP server with clean, semantically-rich tool descriptions so agents can find and call it reliably. This is a near-term, billable engagement that maps directly to the paper’s “agents compete for invocation” claim — you’re doing the client’s “agent SEO.”
• Internal: standardize your own agent stack on MCP + A2A. If you build multi-agent systems (you do), adopting these protocols now means your agents interoperate with the broader ecosystem (Claude/ChatGPT agents, partner agents) instead of being a walled garden. MCP for your tools, A2A for cross-org agent collaboration.
• The dual-path orchestration pattern. The trip example’s “synthesize most things, but stream latency-sensitive or sensitive-data things directly client↔service” is a clean architectural pattern for any agent product where some sub-results are interactive (maps, live data) or carry payment/PII you don’t want flowing through the LLM context.
• Risk/governance consulting. The paper’s layered threat taxonomy and red-teaming/defense sections are a ready-made checklist for a “secure your agentic deployment” offering — prompt injection across layers, controllable generation, inference-time guardrails, evaluation.
• Roadmap framing for clients. The three-era / three-dimension story is a genuinely good slide for explaining to a non-technical client why they should invest now and what changes. Use it as the narrative scaffold.

The honest caveat: the heavy infrastructure pieces (cross-agent billing ledgers, SRZ-aware networks) are research-grade and not buildable as products yet. Sell the MCP-wrapping, the orchestration, and the security work — those are real today.

Build Your Own (Minimal Recipe)

The smallest thing that captures ~80% of the value is a Client-Agent-Server orchestrator with real MCP tool calls and a stub A2A discovery step.

Build order:

1. Stand up an MCP server for one tool. Use the official mcp Python SDK. Expose one real capability (e.g., a weather lookup or your own internal API). Get the capability-declaration handshake working — this teaches you the semantic-contract idea fast.
2. Write the orchestrator agent (the Host). An LLM loop that: parses a goal → decomposes into sub-tasks → for each, picks a tool and calls it via your MCP client → synthesizes. Use any agent framework you like (LangGraph is a natural fit for the plan/route/synthesize graph) or roll the loop by hand — it’s ~the snippet above.
3. Add a trivial registry + matchmaker. A dict mapping capability → MCP server is enough to start. The interesting version replaces registry.match with an embedding-similarity search over tool descriptions — that’s your toy “capability discovery,” and it’s where the real research lives.
4. Add one peer-agent delegation via A2A. Stand up a second agent with an Agent Card (a JSON file at a URL), have the orchestrator read the card and delegate one sub-task. Now you have a 2-agent mesh.
5. Add the dual path. Mark one sub-task low_latency=True and route its result straight to the client UI, bypassing the synthesizer.

The two hard parts: (a) capability discovery/matchmaking — naive keyword match is fine for a demo, but ranking many candidate tools/agents by fit, readiness, and cost is genuinely unsolved; (b) making the LLM emit reliable structured tool calls — MCP’s machine-readable schemas help a lot, but you’ll still need validation/retry. Reach for: mcp SDK, an A2A SDK or just JSON-over-HTTP, LangGraph or your own loop, and an embedding model for discovery.

How to Improve It

Limitations are the leverage. Five concrete, testable directions:

1. Build the missing discovery layer and measure it. The paper names just-in-time matchmaking as the core open problem but proposes nothing concrete. Take a population of MCP servers/AgentCards, embed their capability descriptions, and benchmark retrieval-style discovery (recall@k of the right tool, end-to-end task success). This is a publishable, productizable gap.
2. Prototype the Cross-Agent Billing Ledger. The economic model is hand-waved. A real contribution: a minimal append-only ledger that traces token/API spend across a delegating agent tree and attributes cost back to the originating command, plus a pre-flight cost estimator to prevent bill shock. Test it on multi-hop delegation chains.
3. Stress-test MCP/A2A security empirically. The threat taxonomy is qualitative. Run prompt-injection and tool-poisoning attacks against a real MCP server registry and measure how often a malicious “advertised” capability gets selected — quantify the Agent-Attention-Economy attack surface the paper only hypothesizes.
4. Make discovery itself a learned, contestable market. If services compete for agent invocation, build a re-ranking layer where capability selection is a learned policy (reward = task success / cost), and study whether it’s gameable (the agentic analog of SEO spam). This turns the “Agent Attention Economy” hypothesis into an experiment.
5. Close the loop with online learning. The Intelligence Dimension lists “adaptive learning” but the systems described are mostly static LLMs + prompting. A real improvement: have the orchestrator log task outcomes and fine-tune (or update a routing policy / memory) so discovery and decomposition get better over time on a fixed domain — and report the learning curve.

Glossary

• Agentic Web — an internet where autonomous LLM agents persistently plan, coordinate, and execute goal-directed tasks on a user’s behalf, with services/resources that are agent-accessible.
• MCP (Model Context Protocol) — Anthropic’s standard for an agent (Host) to discover and call tools/resources via a Client→Server handshake with machine-readable capability declarations.
• A2A (Agent-to-Agent) — Google’s protocol for direct collaboration between heterogeneous agents using public Agent Cards for discovery and Task/Message/Artifact primitives.
• Agent Card — a public JSON file describing an agent’s capabilities, endpoint, and auth, used by other agents to find and call it.
• Client-Agent-Server — the proposed three-tier architecture replacing client-server; the agent tier is an autonomous orchestrator between user and backends.
• Agent Attention Economy — the emerging market where tools/services/agents compete to be invoked by agents (rather than clicked by humans), expected to spawn agent-facing ranking, ads, and referral systems.
• Capability discovery / just-in-time matchmaking — finding and selecting a suitable tool or peer agent at runtime from a large, dynamic pool; the paper’s headline open problem.
• SRZ (Service Requirement Zone) — an 8-dimensional profile (delay, cost, security, data rate, knowledge, reliability, storage, energy) describing a task’s quality-of-experience needs so infrastructure can provision per-task SLAs.
• DID (Decentralized Identifier) — a cryptographically verifiable identity (no central registry) that an Agent Card can reference for self-sovereign agent authentication.
• RAG (Retrieval-Augmented Generation) — grounding an LLM’s output in retrieved external documents; here, the bridge from passive search to agentic, multi-step retrieval.
• ReAct — an agent pattern interleaving reasoning traces with actions (tool calls), letting the agent reason-to-act and act-to-reason; a canonical single-agent loop.
• Tool orchestration — safely composing and sequencing external capabilities (verify, authenticate, execute in a controlled environment) within an agent’s plan.
• In-parameter knowledge — information stored in an LLM’s weights from pretraining, used via reasoning instead of a document lookup.