Agentic AI, MCP & Gateways — Complete Visual Guide

Agents · Tool Use · Model Context Protocol · MCP & Agent Gateways · A2A — every concept explained with animated diagrams

Agentic Fundamentals

What “Agentic” Actually Means

Strip away the hype and an AI agent is one simple thing: a language model running in a loop, calling tools, and reading the results until a goal is reached. A chatbot answers once and stops. An agent acts — it decides its own next step based on what just happened in the environment.

The agentic loop — reason · act · observe

The Building Blocks

🧠

Model

The LLM doing the reasoning. It never executes anything itself — it only emits text and structured tool-call requests. Capability of the model caps capability of the agent.

🔧

Tools

Functions the model may request: read a file, run a shell command, query an API. Each tool is described by a name, a description, and a JSON Schema for its inputs — that description is the model’s only manual.

📜

System Prompt

The standing instructions: role, constraints, style, guardrails. In agent products this is where behaviour is engineered.

🪟

Context Window

The model’s working memory — everything it can “see” right now: prompt, conversation, tool results. Finite, so long-running agents need compaction and summarisation.

💾

Memory

State that survives beyond the context window — scratchpad files, vector stores, databases. Short-term (this task) vs long-term (across sessions).

⚙️

Agent Runtime / Harness

The non-AI code around the model: runs the loop, executes tool calls, enforces permissions, retries failures, manages context. Claude Code is a harness; the Claude Agent SDK lets you build your own.

One Loop Iteration, Step By Step

1

Receive The Task

The user goal lands in the context alongside the system prompt and the list of available tool definitions.

2

Model Reasons

The LLM decides: can I answer now, or do I need information / side effects? If the latter, it emits a structured tool-call request (name + JSON arguments).

3

Harness Executes

The runtime — never the model — validates the call, checks permissions, runs the actual function, and captures output or error.

4

Result Goes Back In

The tool result is appended to the context. The model now “observes” what happened — including failures, which it can recover from.

5

Repeat Or Finish

The model loops to step 2 with richer context. When it stops requesting tools, its text response is the final answer. Stop conditions (max turns, budget) bound the loop.

# the whole idea, in eight lines
messages = [system_prompt, user_task]
while True:
    reply = llm(messages, tools=TOOLS)      # 1 · reason
    if reply.stop_reason != "tool_use":
        return reply.text                # done
    result = execute(reply.tool_call)       # 2 · act
    messages += [reply, result]             # 3 · observe

Key insight: the model proposes, the harness disposes. An LLM cannot touch your filesystem or network — every real-world effect goes through tool execution code you control. That separation is exactly where permissions, sandboxing, and (later) gateways attach.

---

Workflows vs Agents

Anthropic’s “Building Effective Agents” draws the line that the industry adopted: in a workflow, your code decides the path and the LLM fills in steps. In an agent, the LLM decides the path. Workflows are predictable and cheap; agents handle open-ended problems. Most production systems are workflows with agentic islands.

Workflow Patterns — Predefined Paths

⛓️

Prompt Chaining

Fixed sequence of LLM calls, each consuming the previous output. Outline → draft → polish. Add programmatic checks between steps.

🔀

Routing

A classifier call picks which specialised prompt/model handles the input. Cheap queries → small model, hard ones → big model.

⫘

Parallelization

Fan the same input out to several calls and aggregate — independent subtasks (sectioning) or multiple votes on one question.

🎛️

Orchestrator–Workers

A lead LLM decomposes the task at runtime and dispatches worker calls, then synthesises. The number and shape of subtasks is dynamic.

🔁

Evaluator–Optimizer

One call generates, another critiques against criteria, loop until accepted. The pattern behind self-review and judge loops.

Choosing Between Them

Dimension	Workflow	Agent
Path Through The Task	Known upfront, coded by you	Discovered at runtime by the model
Predictability	High — same input, same route	Lower — needs eval + guardrails
Cost / Latency	Bounded, easy to budget	Open-ended; cap with max turns
Debugging	Step-by-step, deterministic	Trace-driven (hence observability)
Best For	Pipelines: classify, extract, transform	Open problems: coding, research, ops

Rule of thumb: find the simplest pattern that works and stop there. Reach for a full agent only when you cannot enumerate the steps in advance.

Multi-Agent Patterns

Orchestrator + Subagents

A lead agent plans and delegates to focused subagents, each with its own clean context window and a narrow toolset. The subagent returns a summary, not its working — the orchestrator keeps the big picture without drowning in detail.

Context Isolation

Handoffs

Peer agents transfer the conversation to whichever specialist owns the current need — triage hands to billing, billing hands to refunds. Control moves; there is no permanent boss.

Specialisation

Parallel Fan-Out

Many agents attack independent slices simultaneously — review dimensions, file migrations, research angles — and a synthesis step merges results. Wall-clock wins, token costs multiply.

Throughput

More agents is not automatically better. Every agent boundary loses context and adds a failure mode. Multi-agent pays off for exactly two reasons: context isolation (a subagent burns its own window, not yours) and parallelism. If neither applies, one agent with good tools beats five with a committee.

MCP — Model Context Protocol

MCP — Model Context Protocol

MCP is an open standard for connecting AI applications to tools and data — “USB-C for AI”. Open-sourced by Anthropic in November 2024, adopted across the industry through 2025, and now governed openly under the Linux Foundation. The wire format is JSON-RPC 2.0. Before MCP, every app × every tool meant a custom integration; with MCP, each side implements the protocol once.

The integration problem MCP solves — M × N becomes M + N

MCP architecture — host · clients · servers

Server Primitives — What A Server Offers

🔧

Tools Model-Controlled

Executable functions the LLM chooses to invoke — create_issue, query_db. Discovered via tools/list, invoked via tools/call. This is the primitive that powers agents.

📄

Resources App-Controlled

Read-only context identified by URI — file contents, schemas, log streams. The host application decides what to attach; the model doesn’t fetch these on its own.

💬

Prompts User-Controlled

Reusable prompt templates the server publishes — surfaced to users as slash commands or menu entries.

Client Primitives — What The Host Offers Back

🔮

Sampling

A server can ask the host’s model to complete something — servers get LLM access without shipping their own API key. The host mediates and can require approval.

📁

Roots

The host tells the server which filesystem locations are in scope — a soft boundary for where the server should operate.

❓

Elicitation

Mid-operation, a server can ask the user for structured input (“which environment?”) through the host UI. Added in the 2025-06-18 revision.

Capabilities are negotiated at initialize — each side declares what it supports, and only negotiated features may be used during the session.

Transports

Transport	How	Use For
stdio	Host spawns the server as a child process; JSON-RPC over stdin/stdout	Local servers — filesystem, shell, dev tools
Streamable HTTP	Single HTTP endpoint; responses can upgrade to SSE streams; session via Mcp-Session-Id	Remote / hosted servers
HTTP + SSE	Two-endpoint scheme from the original spec	Deprecated — replaced by Streamable HTTP (2025-03-26)

// .mcp.json — one remote, one local
{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "~/projects"]
    }
  }
}

Connection Lifecycle

1

Initialize

Client sends initialize with its protocol version and capabilities; server replies with its own. Versions are date-stamped (e.g. 2025-06-18).

2

Ready

Client sends notifications/initialized. The session is live.

3

Discover

Client calls tools/list, resources/list, prompts/list. Servers push list_changed notifications when offerings change.

4

Operate

The agent loop calls tools/call as the model requests; results flow back as content blocks (text, structured JSON, images).

5

Terminate

Transport closes; stdio servers exit with the host.

// a tool, as the model sees it (tools/list)
{
  "name": "create_issue",
  "description": "Create a GitHub issue",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repo":  { "type": "string" },
      "title": { "type": "string" }
    },
    "required": ["repo", "title"]
  }
}

Spec Evolution — Date-Stamped Revisions

Revision	What Changed
2024-11-05	Initial release: stdio + HTTP/SSE transports, tools, resources, prompts, sampling
2025-03-26	Streamable HTTP transport, OAuth 2.1 authorization framework, tool annotations (e.g. read-only hints), audio content
2025-06-18	Elicitation, structured tool output, servers classified as OAuth resource servers (RFC 8707 resource indicators), JSON-RPC batching removed
2025-11-25	Tasks — call a tool asynchronously and poll for the result of long-running operations

Governance moved from Anthropic alone to open stewardship under the Linux Foundation (announced December 2025), alongside an official MCP Registry for discovering published servers.

Security reality check: every MCP server you connect is code that feeds text straight into your model’s context. That enables prompt injection via tool results, tool poisoning (malicious instructions hidden in tool descriptions), and rug pulls (a server silently changing a tool’s behaviour after you approved it). One laptop with three servers is manageable by inspection. Fifty agents and two hundred servers is not — that is the problem the next tab exists to solve.

Gateways · A2A · Glossary

Gateways — Running Agents At Scale

One agent on one laptop needs nothing from this tab. The moment an organisation runs many agents against many models, many MCP servers, and each other, the old microservices lesson repeats: unmanaged point-to-point traffic becomes a security and operations nightmare. A gateway is the choke point where identity, policy, and observability attach — the same role the API gateway played for REST, rebuilt for agent traffic.

The enterprise agentic stack — one governed data plane

Agent Gateway

A data plane purpose-built for agentic traffic. Where an API gateway understands HTTP requests, an agent gateway natively understands the three protocols agents speak:

🧠

Agent → LLM

Provider APIs (Anthropic, OpenAI, …). The gateway can route by model, enforce token budgets, fail over between providers.

🔧

Agent → Tool (MCP)

Proxies and multiplexes MCP sessions, applies per-tool authorization, inspects payloads for policy violations.

🤝

Agent → Agent (A2A)

East–west traffic between agents — identity propagation and audit for delegation chains.

Reference open-source implementation: agentgateway (Rust, originated at Solo.io, now a Linux Foundation project, integrated with the Envoy/kgateway ecosystem).

MCP Gateway

A narrower, very common specialisation: a reverse proxy that sits between MCP clients and a fleet of MCP servers.

1️⃣

Aggregation

Agents configure one endpoint; the gateway federates hundreds of upstream servers behind it.

🎭

Virtual Servers

Compose curated tool subsets per team or per agent — “deploy-bot sees these 6 tools”, regardless of what upstreams expose.

🔐

Central Auth + Audit

One OAuth flow at the gateway instead of N credentials scattered across agents; every tools/call logged and traced.

🛡️

Policy Enforcement

Tool allow-lists, rate limits, payload scanning — the practical mitigation for tool poisoning and rug pulls from the previous tab.

Examples: Docker MCP Gateway, IBM ContextForge MCP Gateway.

MCP gateway — agents see one server, operators govern hundreds

The Four Gateways, Side By Side

	API Gateway	LLM Gateway	MCP Gateway	Agent Gateway
Traffic	Clients → REST/gRPC services	Apps/agents → model provider APIs	MCP clients → MCP servers	All of it: LLM + MCP + A2A
Speaks	HTTP, gRPC	Anthropic / OpenAI-style APIs	MCP (JSON-RPC over stdio / HTTP)	MCP, A2A, provider APIs
Governs	Routes, keys, rate limits	Model choice, cost, caching, fallback	Which tools exist and who may call them	End-to-end agent traffic policy
Examples	Traefik, Kong, Envoy	LiteLLM, Portkey, OpenRouter, Envoy AI Gateway	Docker MCP Gateway, IBM ContextForge	agentgateway

They compose, not compete. A realistic stack runs an agent gateway as the front door, an LLM gateway function for model routing, and an MCP gateway function for tool federation — sometimes three products, increasingly one.

A2A — Agent2Agent Protocol

Where MCP connects an agent to tools, A2A connects an agent to other agents — opaque peers that hold their own state and reasoning. Announced by Google in April 2025, donated to the Linux Foundation in June 2025.

1

Discover

Each agent publishes an Agent Card — a JSON document at a well-known URL describing identity, skills, endpoint, and auth requirements.

2

Delegate A Task

The client agent sends a task (JSON-RPC over HTTPS). Tasks are the unit of work, with a lifecycle: submitted → working → input-required → completed / failed.

3

Stream Progress

Long tasks stream status updates over SSE or deliver webhooks via push notifications.

4

Collect Artifacts

Results come back as artifacts — text, files, structured data. The remote agent’s internals stay private; only the task interface is shared.

MCP vs A2A — Which Wire When

	MCP	A2A
Connects	Agent ↔ tools & data	Agent ↔ agent
Remote Side Is	Deterministic functions you describe with schemas	An autonomous peer with its own reasoning
Interaction	Call → result, usually seconds	Task lifecycle, possibly hours, may ask questions back
Discovery	Config / registry of servers	Agent Cards at well-known URLs
Mental Model	”Plug in a capability"	"Delegate to a colleague”

A useful test: if you can fully describe the remote thing with a JSON Schema, it’s a tool — use MCP. If you’d brief it like a coworker, it’s an agent — use A2A.

Glossary — The Rest Of The Vocabulary

Concept	What It Is
Function Calling / Tool Use	The model-API feature underneath everything here: the LLM emits a structured request naming a function and JSON arguments; your code executes it
ReAct	The 2022 paper pattern (Reason + Act) that became the agent loop: interleave thinking traces with actions and observations
Context Engineering	Successor discipline to prompt engineering: curating everything in the window — instructions, tools, retrievals, history — for the current step
Compaction	Summarising older conversation turns to reclaim context window space so long-running agents don’t run out of memory mid-task
Agentic RAG	Retrieval driven by the agent loop — the model decides what to search, reads results, and searches again — instead of one fixed retrieve-then-answer pass
Skills	Packaged procedural knowledge (instructions + scripts + resources) an agent loads on demand — teaching workflows without retraining or bloating the system prompt
Computer Use	An agent operating a GUI directly — screenshots in, mouse/keyboard actions out — for software that has no API
Sandboxing	Executing agent tool calls inside containers/VMs with restricted filesystem and network so a bad action is contained
Human-In-The-Loop (HITL)	Approval checkpoints on consequential actions — deploys, payments, deletions — while routine steps run autonomously
Guardrails	Input/output validation around the model: schema checks, content filters, policy rules — enforced by code, not by asking nicely
Evals	Repeatable test suites for agent behaviour — graded tasks and LLM-as-judge scoring; the agent world’s regression tests
Agent Observability	Traces of every loop iteration, tool call, and token spent — converging on OpenTelemetry GenAI semantic conventions
MCP Registry	The official catalog for discovering published MCP servers (with private sub-registries inside enterprises)
Agent Runtime	The managed place agents execute — loop scheduling, state persistence, scaling — e.g. cloud agent platforms or your own harness on k8s
Tool Poisoning	Attack: hostile instructions hidden inside a tool’s description or output, hijacking the model when they enter context
Confused Deputy	Attack: tricking a privileged agent into using its authority for the attacker’s request — why per-user, per-tool authorization beats one god-token
Rug Pull	Attack: an MCP server changes a tool’s behaviour after the user approved the original — mitigated by version pinning and gateway policy

How it all composes: a model becomes an agent when a harness runs it in a tool loop · MCP standardises how that loop reaches tools and data · A2A standardises how agents delegate to each other · and gateways put identity, policy, and observability on every one of those wires. Four layers — reasoning, tooling, collaboration, governance.