Agentic Systems: Overview

This site is a working reference for agentic systems: software in which one or more language-model-driven agents pursue goals by repeatedly observing context, deciding on an action, acting through tools, and folding the result back into the next decision. It is written for two readers at once — someone learning the concepts for the first time, and a practitioner who needs the exact wire formats, method names, and design trade-offs to ship a real system.

From a single model call to an autonomous system

It helps to think of "agentic" as a spectrum rather than a binary. Capability grows as you move along it, and so does the engineering effort required to keep the system reliable.

1. A bare model call. A prompt goes in, text comes out. There is no memory, no ability to act on the world, and no loop — the model cannot check its own work or fetch a fact it does not already know.

2. A tool-augmented call. The model is given a set of typed, named capabilities and may ask the host to invoke one. This is tool-use: the model emits a structured request (a tool name plus arguments), the host runs the tool, and the result is fed back. A single round of this is already enough to answer "what's the weather in Lisbon?" by calling a weather API instead of hallucinating.

3. An agent with an agent loop. Wrap tool-use in a loop and you get an agent-loop: observe the current context, decide on the next action (often a tool call), act, observe the result, and repeat until a stopping condition is met. The loop is what lets an agent take multiple dependent steps — read a file, notice it references another, open that one, then summarize both — without a human driving each turn.

4. A multi-agent system. Decompose a hard goal across several specialized agents — a planner, a researcher, a coder, a critic — coordinating through some orchestration pattern. A multi-agent system trades the simplicity of one loop for parallelism, separation of concerns, and the ability for agents owned by different teams or organizations to collaborate.

The further right you go, the more the hard problems shift from "can the model do the task" to "how do components talk to each other safely and reliably." That shift is what makes interoperability protocols central rather than incidental.

Anatomy of an agent

At every point on that spectrum the core building block is the same: a model acting as a reasoning engine, surrounded by the machinery that lets it remember, act, and collaborate.

flowchart TB
    subgraph Agent["Agent"]
        LLM["LLM core
(reasoning + planning)"]
        MEM["Memory
(context, history, retrieval)"]
        LLM <--> MEM
    end

    subgraph Tools["Tools & Data"]
        T1["Tool / API"]
        T2["Database"]
        T3["Filesystem"]
    end

    PEER["Peer agent
(owned by another team)"]

    LLM -- "tool-use via MCP" --> Tools
    LLM -- "delegation via A2A" --> PEER
    PEER -. "may itself use MCP" .-> Tools

Read the diagram as two distinct conversations leaving the agent. Downward, the agent reaches tools and data — the things it acts through. Sideways, it reaches other agents — peers it can hand work to. These are different problems, and the ecosystem has settled on two different standards for them.

Why interoperability protocols matter

Before standard protocols, every connection was bespoke. Wiring an agent to N tools and M models meant writing custom glue for each pairing — an integration matrix that grows multiplicatively and never finishes. Anthropic framed the motivation for the Model Context Protocol (MCP) exactly this way when it introduced the standard on 2024-11-25: even capable models are "constrained by their isolation from data," and "every new data source requires its own custom implementation," so MCP aims to replace "fragmented integrations with a single protocol."

A shared protocol collapses that matrix. Build a tool server once against the protocol and any compliant agent can use it; teach an agent the protocol once and it can reach any compliant tool. The same logic, applied to agents talking to agents, motivates the Agent-to-Agent (A2A) protocol, an open standard "designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems."

The key distinction: MCP connects to tools, A2A connects to agents

If you remember one thing from this page, make it this:

• MCP connects an agent to tools and data. It standardizes the vertical link between one agent and the external capabilities it acts through. MCP uses a client-host-server architecture: a host application runs one or more clients, and each client holds a 1:1 stateful session with a server that exposes resources, prompts, and tools. See protocols-mcp.html.

• A2A connects agents to each other. It standardizes the horizontal link between independent, possibly opaque agents — including those owned by different organizations. A server (remote) agent publishes an agent-card describing its skills and endpoint; a client agent reads it and delegates work as tasks. See protocols-a2a.html.

The two are complementary, not competing: an agent typically uses MCP to reach its own tools and speaks A2A to collaborate with peers — and a peer agent reached over A2A may, in turn, use its own MCP servers. A side-by-side breakdown lives in protocols-comparison.html.

Both protocols share a foundation worth noting up front: each carries its messages as JSON-RPC 2.0 — request objects with jsonrpc, id, method, and params fields, and responses that echo the id with a result or error. MCP defines methods such as tools/call; A2A's JSON-RPC binding (as of A2A v1.0) defines operation-style methods such as SendMessage and GetTask. A2A additionally specifies gRPC and HTTP+JSON/REST bindings of the same operations. That shared vocabulary is why the two slot together cleanly rather than fighting over the wire.

Version note. A2A v1.0.0 (the current "latest" spec, released 2026-03-12) renamed the JSON-RPC binding methods from the kebab-style names used through v0.3.x (message/send, tasks/get, message/stream) to operation-style names (SendMessage, GetTask, SendStreamingMessage), and made task-state values SCREAMING_SNAKE_CASE (ProtoJSON) across all bindings. The examples below follow v1.0.

{
  "jsonrpc": "2.0",          // JSON-RPC version — always "2.0"
  "id": "1",                 // request id; the response echoes it to correlate
  "method": "SendMessage",   // A2A v1.0 method: send a message, get a Task back
  "params": {
    "message": {
      "role": "ROLE_USER",   // who is speaking on this turn (v1.0 ProtoJSON enum)
      "parts": [             // a message is a list of typed parts
        { "text": "Summarize Q3 revenue." }
      ],
      "messageId": "msg-1"
    }
  }
}

The remote agent answers with a result carrying a Task whose status.state moves through lifecycle values. As of A2A v1.0 these are serialized in SCREAMING_SNAKE_CASE — "TASK_STATE_SUBMITTED", "TASK_STATE_WORKING", "TASK_STATE_INPUT_REQUIRED", and "TASK_STATE_COMPLETED" — and the same uppercase identifiers are used across every binding (JSON-RPC, gRPC, and HTTP+JSON/REST), since v1.0 aligned the JSON representation with ProtoJSON. (Through v0.3.x the JSON-RPC binding used lowercase kebab values like "submitted" and "input-required".) Either way, the asynchronous, possibly long-running nature of delegated work is baked into the protocol.

Governance: open and vendor-neutral

These are not single-vendor APIs. MCP is an open protocol whose specification is published openly and developed in the open. A2A began at Google and was donated to the Linux Foundation (announced 2025-06-23), which formed the Agent2Agent project with founding participants including Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow — putting the standard under neutral, multi-company governance. For practitioners that matters: building against these protocols is a bet on an ecosystem, not on one company's roadmap.

A map of this site

The material is organized into four pillars. Start anywhere, but if you are new, read them in order.

Foundations

The building blocks every agent shares, independent of any protocol. foundations-what-is-an-agent.html settles the definitional question first — what the word agent means, from the classical perceive-and-act formulation to today's competing framings. How the agent-loop turns a static model into something that takes steps; how tool-use is defined, described, and validated; and how memory — context windows, history, and retrieval — gives an agent something to reason over. Start at foundations-agent-loop.html, then foundations-tool-use.html and foundations-memory.html.

Protocols

The interoperability layer, in spec-accurate detail. protocols-mcp.html covers MCP (agent ↔ tools); protocols-a2a.html covers A2A (agent ↔ agent); protocols-acp.html covers a further agent-communication effort; and protocols-comparison.html puts them side by side so you can choose the right one for a given boundary.

Orchestration

Once you have more than one agent, you need a coordination strategy. This pillar surveys multi-agent orchestration patterns — supervisor/worker hierarchies, sequential and parallel pipelines, routing, and reflection — and the trade-offs between them. See orchestration-patterns.html.

Ecosystem & Ops

What it takes to run agentic systems in production. The frameworks that implement these ideas — see ecosystem-frameworks.html — and the operational concerns of deployment, security, evaluation, and observability — see ecosystem-ops.html.

Two appendices support the rest: a glossary.html of the terms used throughout (technical terms link to it on first use), and a references.html list of the primary sources every claim is grounded in.