Agent Foundations Tutorial En

§0 TL;DR Cheat Sheet

1. Agent = LLM policy + tool I/O + memory + control loop. Minimal skeleton (ReAct, Yao et al. 2022, arXiv:2210.03629, ICLR 2023): loop Thought → Action → Observation → Thought … until Finish[answer] is generated. Action invokes external tools (search / calculator / shell), observation is fed back into context, the scratchpad is concatenated back into the prompt at every turn.
2. Key gains over vanilla CoT: CoT only "thinks" in latent space, hallucinations propagate all the way through; ReAct lets the model leave its own head to verify at every step (Wikipedia API, Python interpreter, code execution) → on interactive decision tasks like ALFWorld / WebShop the absolute success rate is +34% / +10% over IL/RL baselines (with only 1-2 in-context examples). But pure ReAct on HotpotQA EM (27.4) is actually below pure CoT (29.4) and CoT-SC (33.4); the true strongest is ReAct ↔ CoT-SC complementary fallback (HotpotQA 35.1, Fever 64.6).
3. Plan-and-Execute / Plan-and-Solve (Wang et al. 2023, ACL, arXiv:2305.04091): first plan ("Let's first understand the problem and devise a plan… Then carry out the plan step by step."), then execute step by step. Advantage: on long horizons the goal won't be "forgotten along the way"; downside: a wrong plan breaks the whole run (without a replan mechanism). In production it is usually hybrid: Plan-and-Execute up front + ReAct as per-step fallback.
4. Three paradigms of tool use: (a) Prompt-time tool use (ReAct, ART, Paranjape 2023, arXiv:2303.09014) — give demos so the model learns in-context; (b) Self-supervised fine-tuning (Toolformer, Schick 2023 NeurIPS, arXiv:2302.04761) — the model labels API calls itself and uses loss to filter "useful" ones; (c) Structured Function Calling (OpenAI 2023-06-13 / Anthropic Tool Use 2024 / Gemini Tools) — RLHF/SFT-aligned backend models emit JSON-schema-structured tool calls; the most stable choice and the 2024-2026 industrial-deployment default.
5. Reflexion (Shinn et al. 2023, NeurIPS, arXiv:2303.11366): after each episode fails, the model writes a natural-language reflection ("verbal reinforcement") which is stored in episodic memory; the next episode concatenates the reflection back into the prompt → without changing weights it noticeably gains on HumanEval / AlfWorld. Not RL — no gradient update; essentially "using in-context learning to simulate policy iteration".
6. MCP (Model Context Protocol, Anthropic 2024-11-25) is the de-facto industry standard for 2025: JSON-RPC 2.0 over stdio / Streamable HTTP, three primitives = tools (executable), resources (read-only data), prompts (templates). Client/server negotiate capabilities via initialize, then invoke tools/call / resources/read / prompts/get. A2A (Google 2025-04, donated to Linux Foundation 2025-06; v0.3 + v1.0 released in 2026Q1) is complementary: governs agent ↔ agent collaboration (Agent Card at /.well-known/agent-card.json + Task lifecycle; from v1.0 enums become SCREAMING_SNAKE_CASE). One-sentence mental model: MCP governs agent → tool/data; A2A governs agent → agent.
7. Computer-Use paradigm (2024-2025): Anthropic Claude 3.5 Sonnet (new) first shipped on 2024-10-22, takes screenshots as input and outputs {action: click/type/scroll, coordinates}; OpenAI Operator / CUA 2025-01-23 (later folded into ChatGPT agent on 2025-07-17). GUI agents treat the OS as the environment; bottleneck is grounding (accurate coordinates) + long horizon.
8. Mainstream 2024-2026 benchmarks: SWE-bench (Jimenez et al. 2024 ICLR, arXiv:2310.06770) + SWE-bench Verified (OpenAI Preparedness team 2024-08-13, 500-task human-reviewed subset); GAIA (Mialon 2024 ICLR, 466 questions, human 92% vs GPT-4 plugins 15%); OSWorld (Xie 2024 NeurIPS, arXiv:2404.07972, 369 real OS tasks, human 72.36% vs GPT-4V baseline 12.24%); WebArena (Zhou 2024 ICLR, arXiv:2307.13854, 812 web tasks, GPT-4 14.4% vs human 78.2%); τ-bench (Yao 2024-06, arXiv:2406.12045, customer-service domain + user simulator); AgentBench (Liu 2024 ICLR, 8 environments); MLE-bench (Chan 2024-10, arXiv:2410.07095, 75 Kaggle competitions). Frontier model + scaffold has broken 75-80% on SWE-bench Verified in 2026Q1 (OpenAI retired this benchmark on 2026-02-23, citing contamination + test flaws), but OS-level GUI / real long-horizon tasks remain far from saturated.
9. Key production architecture patterns: subagent orchestration (parent dispatches subtasks to isolated-context child agents and aggregates results; Claude Code, Devin, Manus all use this); tool retrieval (with a tool pool >100, embed top-k filtering of schemas to avoid prompt blowup); KV-cache prefix sharing (multiple agents share the system prompt); token-budget guard / early termination (prevent runaway loops from burning money).
10. Six common failure modes: (a) hallucinated tool call (calls non-existent functions or fabricates arguments); (b) loop / stalemate (the same action triggers repeatedly); (c) lost-in-context (the agent forgets instructions on long runs); (d) tool overuse / underuse (calls search when it could answer directly, or vice versa); (e) prompt injection via tool output (malicious instructions in external webpages); (f) reward hacking on benchmarks (the model overfits the grader's surface pattern). Production mitigations = structured tool schema + max_steps cap + observation truncation + Constitutional / safety classifier on tool I/O.

§1 Minimal viable mental model of an agent

1.1　From next-token predictor to agent

A vanilla LLM is a stateless function f: prompt → completion: it consumes a prompt once, produces a completion, with no external interaction.

An agent wraps it into a closed-loop system:

        ┌──────────────────────────────┐
        │   LLM (policy π_θ)           │  ← chooses next action given history
        └──────────────┬───────────────┘
                       │ action a_t
                       ↓
        ┌──────────────────────────────┐
        │  Environment / Tools         │  ← search / shell / browser / Python
        │  - retrieve(query)           │
        │  - python(code)              │
        │  - browse(url)               │
        └──────────────┬───────────────┘
                       │ observation o_t
                       ↓
        ┌──────────────────────────────┐
        │  Memory / Scratchpad         │  ← append (a_t, o_t) to context
        └──────────────┬───────────────┘
                       │ updated history
                       └──→ back to LLM

This is a special case of POMDP: state = full dialogue history $h_t = (q, a_1, o_1, \dots, a_{t-1}, o_{t-1})$, policy $\pi_\theta(a_t | h_t)$, the trajectory terminates when the LLM itself generates Finish[answer].

1.2　Three orthogonal axes of agent design

Any agent paper / framework can be decomposed along three independent axes:

When the interviewer asks "design an agent for X", pick a position along these three axes first, then discuss implementation. This is much clearer than spitting out an architecture diagram.

1.3　Comparison with classical RL agents

Classical RL agents (Atari, Mujoco) and LLM agents are structurally homologous; differences:

The "uncanny point" of LLM agents: action == token sequence, so "calling a tool" is essentially the model generating a string like Action: search("transformer"), which the harness then parses and executes. Function Calling's progress is replacing this string-parsing with structured JSON, no longer relying on regex.

§2 ReAct: the ancestor prompt of Reason + Act

2.1　Core prompt template

The key finding of ReAct (Yao et al. 2022 arXiv preprint, ICLR 2023) is that interleaving an explicit reasoning trace with actions outperforms both pure CoT and pure action-only on interactive decision tasks (ALFWorld, WebShop) + fact-verification (Fever); on multi-hop QA (HotpotQA) pure ReAct is actually worse than pure CoT-SC (see the table in §2.2), and the strongest result comes from ReAct ↔ CoT-SC complementary fallback.

Question: <user question>
Thought 1: <reasoning about what to do>
Action 1: <tool_name>[<args>]
Observation 1: <tool output>
Thought 2: <reasoning about observation>
Action 2: <next tool call OR Finish[answer]>
Observation 2: ...
...
Thought N: I now know the answer.
Action N: Finish[<final answer>]

Why is the interleaving critical? Because:

• Reasoning provides an interpretable trace of "why this tool / why these arguments" — the model can debug itself based on the reasoning;
• Action brings external information that grounds subsequent reasoning, avoiding hallucination cascades;
• One layer of "errors can be corrected" beyond Plan-then-Execute — every Thought can re-decide after the previous Observation.

2.2　Comparison of two prompt variants (simplified from the paper's table)

HotpotQA / Fever columns from Yao et al. ReAct paper Table 1 (PaLM-540B + 21-sample SC); ALFWorld / WebShop columns from the paper's Table 3 / Table 4 (different setups). This is a simplified comparison; use it only for the trend; refer to the original paper for exact numbers.

• On HotpotQA EM, pure ReAct (27.4) is below pure CoT (29.4) and CoT-SC (33.4) — "ReAct universally beats CoT" is a common misconception;
• The paper's strongest numbers come from ReAct ↔ CoT-SC complementary fallback: on HotpotQA, "ReAct → CoT-SC" (switch to CoT-SC when ReAct is not confident) gets 35.1; on Fever, "CoT-SC → ReAct" gets 64.6 — the two directions are different, depending on the task;
• Where ReAct really shines is on interactive decision-making tasks like ALFWorld / WebShop (absolute success +34% / +10% over IL/RL baselines). Here the value of "calling external tools" is significant.

2.3　Minimal runnable implementation (Python pseudocode ~ 50 lines)

import re
from typing import Callable, Dict

# ---- External dependencies: replace with your own implementations ----
def search_engine(q: str) -> str: ...   # e.g. wraps Serper / Bing API
def kb_lookup(key: str) -> str: ...     # e.g. dict / DB lookup
def run_python(code: str) -> str: ...   # e.g. exec in sandboxed subprocess

# Tool pool: each tool is (name, fn, doc)
TOOLS: Dict[str, Callable[[str], str]] = {
    "search":   lambda q: search_engine(q),       # returns top-1 snippet
    "lookup":   lambda key: kb_lookup(key),
    "python":   lambda code: run_python(code),    # exec in isolated env
    "finish":   lambda ans: ans,                  # sentinel
}

REACT_PROMPT = """You are a ReAct agent. At each step, output:

Thought: <reasoning>
Action: <tool>[<arg>]

Tools: search, lookup, python, finish.
End with Action: finish[<answer>].

Question: {question}
"""

ACTION_RE = re.compile(r"Action:\s*(\w+)\[(.+?)\]", re.DOTALL)

def react_loop(llm, question, max_steps=8):
    history = REACT_PROMPT.format(question=question)
    for step in range(max_steps):
        # 1) Let the LLM continue a chunk (until next "Observation:" or EOS)
        out = llm(history, stop=["Observation:", "Question:"])
        history += out

        # 2) Parse action
        m = ACTION_RE.search(out)
        if not m:
            # Model went off-format → force terminate (prevent silent fail)
            return None, history, "parse_fail"
        name, arg = m.group(1).strip().lower(), m.group(2).strip()

        # 3) finish exit
        if name == "finish":
            return arg, history, "ok"
        if name not in TOOLS:
            obs = f"[Error] Unknown tool {name}."
        else:
            try:
                obs = str(TOOLS[name](arg))[:512]      # truncate, prevent context blowup
            except Exception as e:
                obs = f"[Error] {type(e).__name__}: {e}"[:256]

        # 4) Append observation back to prompt
        history += f"\nObservation: {obs}\n"

    return None, history, "max_steps"

• stop=["Observation:", "Question:"] — prevents the model from hallucinating its own observation. Without this, ReAct almost always breaks.
• obs[:512] truncation — long search results blow up context; in production either truncate or spin up a separate summarizer agent.
• Feeding [Error] ... back instead of raising — gives the agent a chance to recover; if you raise directly, the agent never sees the error and can't adjust.

2.4　Common footguns (frequent interview topic)

§3 Plan-and-Execute / Plan-and-Solve

3.1　Core idea

Plan-and-Solve (Wang et al. 2023 ACL, arXiv:2305.04091) splits reasoning into two stages:

1. Plan: given the question, the model first writes an N-step abstract plan ("Step 1: find X. Step 2: compute Y. Step 3: ..."), without executing;
2. Execute: execute the plan in order; each step can be either an LLM reasoning step or a tool call.

Why does separating planning help? Because the LLM is not disturbed by observations while writing the plan, making it easier to maintain a global view; ReAct-style step-by-step is easily dragged off course by the previous observation ("the observation says X, so I follow X next", forgetting the user originally asked Y).

3.2　Comparison with ReAct

In production architectures pure Plan-and-Execute is rarely used because the cost of a wrong plan is high. The mainstream approach is hierarchical: high-level Plan-and-Execute (coarse plan), with ReAct inside each step (fine decision + replan). LangGraph, CrewAI, and Anthropic's Claude Code subagent all follow this hybrid.

3.3　Plan repair mechanisms

A pure one-shot plan fails easily; modern agents almost all include plan repair:

• Reflexion-style replan: failure during execute → push the failure description back into the prompt → re-plan;
• Tree-of-Thoughts plan tree: the plan itself is a tree, each branch is executed independently, a verifier scores and backtracks (Yao 2023 NeurIPS);
• Step-wise replan: every K steps re-prompt the model to evaluate "is the plan still reasonable? does it need to change?"

§4 Reflexion: pseudo-RL via language

4.1　Formalization

Reflexion (Shinn et al. 2023 NeurIPS, arXiv:2303.11366) factors agent behavior into three modules:

• Actor $M_a$: generates actions (a ReAct or CoT agent);
• Evaluator $M_e$: scores the trajectory (rule-based / heuristic / another LLM);
• Self-Reflection $M_{sr}$: on failure, writes a natural-language reflection stored in episodic memory $\text{mem}$.

The next episode concatenates $\text{mem}$ back into the prompt. Formally it looks like policy iteration:

$$\tau_t \sim M_a(\cdot \mid q,\, \text{mem}_{

Key point: $\theta$ is unchanged — only the reflection text inside the prompt changes.

4.2　Why does "verbal reflection" work?

Think of the reflection as a semantic gradient:

• A numerical gradient tells weights "in which direction and how much to move";
• A linguistic reflection tells the in-context policy "don't do this next time, do this instead" — via in-context learning, the effective policy changes without changing weights;
• Similar to prompt tuning but in natural language and generated by the model itself.

To emphasize: a reflection is prompt-side adaptation, not a weight update, so its effect depends strongly on base model capability — if the base writes useless / wrong reflections, the whole mechanism collapses. The paper §5 also explicitly notes that Reflexion is effective on ALFWorld / HumanEval / HotpotQA but on WebShop reflections do not generalize to the next product search, showing no significant improvement over pure ReAct.

4.3　Performance numbers (paper)

• Reflection rot: after many episodes the memory keeps growing, possibly containing stale / wrong reflections that drag performance down. In production do reflection summarization / pruning.
• Self-evaluator drift: when an LLM serves as the evaluator it tends to be lenient ("the answer's fine"), so reflection is never triggered. In the paper HumanEval uses unit tests as evaluator and AlfWorld uses environment reward — rule-based evaluators are far more stable than LLM evaluators.
• Not every task benefits from reflection: the paper itself reports no significant improvement of Reflexion over ReAct on WebShop — because WebShop requires exploration breadth rather than learning a rule from a single failure, and the written reflection does not generalize to the next product search. "Reflexion is universal" is a common misconception.

4.4　Minimal implementation skeleton

# Suppose we extend §2.3's react_loop a bit: accept extra reflection memory
# prepended to REACT_PROMPT. signature:
#     react_loop(llm, question, max_steps=8, reflections: list[str] | None = None)
#     return (answer: str | None, history: str, status: str)
#
# evaluator must return (score: float, feedback: str);
# prefer rule-based (e.g. unit tests / env reward), not LLM-as-judge.

def build_reflection_block(memory: list[str]) -> str:
    """ Concatenate accumulated reflection memory into a system-level header """
    if not memory:
        return ""
    items = "\n".join(f"- Past reflection: {r}" for r in memory)
    return (
        "Past attempts on this question failed. "
        "Use the following reflections to do better this time:\n"
        f"{items}\n\n"
    )

def reflexion_agent(llm, question, evaluator, max_episodes=3):
    """ Verbal RL: weights unchanged; reflection memory modifies the prompt.
        Returns: (answer: str | None, history: str)
    """
    memory: list[str] = []                  # list of reflection strings
    last_answer, last_history = None, ""
    for ep in range(max_episodes):
        # 1) Run one ReAct episode (pass memory as reflection prefix)
        answer, history, status = react_loop(
            llm, question, max_steps=8, reflections=memory
        )
        last_answer, last_history = answer, history

        # 2) Score
        score, feedback = evaluator(answer, history, status)
        if score >= 1.0:
            return answer, history          # Success, return early

        # 3) Let the LLM reflect on the failure (note: reflection is itself an LLM call)
        reflection = llm(
            f"You failed: {feedback}\n"
            f"Your trajectory:\n{history}\n"
            f"Write a SHORT reflection (<60 words) on what to do differently."
        )
        memory.append(reflection)
    return last_answer, last_history        # Out of episodes; return the latest

§5 Tool Use: from prompt to structured function call

5.1　Four-generation evolution timeline

By 2024-2026, mainstream frameworks stand on top of Gen 3. MCP (§6) then standardizes the server-side implementation of tools at the transport layer.

5.2　Toolformer: the core trick of self-supervised labeling

Toolformer aims to solve "how to teach a model to use APIs without human labels":

1. API candidate generation: have the base LLM emit [API(args)] tokens at every candidate position in each text snippet, producing many candidates;
2. Execute + splice back: actually execute each candidate API call, splice the result $r$ back into the original text to get $\text{text}_{\text{with}}$;

3. Utility filtering (paper §2.3): for each candidate API call $i$, define the weighted NLL of the LM on continuation tokens under three conditions:

   • $L_i^{+}$ = the loss when "calling the API + getting the result";
   • $L_i^{-} = \min$(loss without API call, loss when the API was called but the result is replaced by empty);

   Keep samples satisfying $$L_i^{-} - L_i^{+} \;\ge\; \tau_f$$ i.e. "calling the API and reading the result" is at least $\tau_f$ better than "not calling at all / calling but not reading the result". This $\min$ is the key: it simultaneously excludes "shouldn't call here" (not calling is good enough) and "called but result is useless" (call without reading). $\tau_f$ is a hyperparameter (tuned per API in the paper, typically order 0-1).

4. SFT: fine-tune the base LLM on the filtered corpus.

5.3　Schema specification for Structured Function Calling

Taking OpenAI Function Calling (2023-06-13) and Anthropic Tool Use (2024 onwards) as representatives, the schema looks like:

{
  "name": "get_weather",
  "description": "Get current weather in a given city.",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "City name, e.g. Shanghai"},
      "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
    },
    "required": ["city"]
  }
}

At inference time the model directly outputs:

{"type": "tool_use", "name": "get_weather",
 "input": {"city": "Shanghai", "unit": "celsius"}}

The frontend framework parses it, executes the tool, and wraps the result as a tool_result block to splice back into the conversation history.

Why is it better than the ReAct text-protocol?

• JSON-schema validation: parameter types / enums / required are all checkable at the frontend, with errors rejected immediately;
• Parallel tool calls: a single inference can produce multiple tool_use blocks, executed in parallel (natively supported by Anthropic 2024 onwards);
• High determinism: the model is SFT-aligned to the schema and almost never produces syntax errors.

5.4　Notes on parallel tool use

# Host-side pseudocode — must be awaited in an async function
import asyncio

async def execute_tool(name: str, args: dict) -> str: ...   # your own dispatcher

async def parallel_tool_step(llm, conv) -> list[dict]:
    # 1) A single LLM call may return multiple tool_use blocks
    #    Assume llm is an async client (e.g. anthropic.AsyncAnthropic / openai.AsyncOpenAI)
    response = await llm.messages.create(
        model="claude-opus-4-x", messages=conv, tools=[...]
    )
    tool_calls = [b for b in response.content if b.type == "tool_use"]

    # 2) Execute in parallel (note: only safe if idempotent / no-conflict)
    results = await asyncio.gather(*[
        execute_tool(tc.name, tc.input) for tc in tool_calls
    ])

    # 3) Wrap as tool_result blocks and splice back into conversation
    return [{"type": "tool_result", "tool_use_id": tc.id, "content": str(r)}
            for tc, r in zip(tool_calls, results)]

§6 MCP and A2A: the 2024-2026 protocol-layer standards

6.1　MCP (Model Context Protocol)

Anthropic open-sourced MCP on 2024-11-25; by 2025 it had become the de-facto standard (OpenAI, Google, Microsoft all added support in 2025). One sentence: MCP is "LSP for LLM" — it lets a host (Claude Desktop / Cursor / Cline / Claude Code) connect to arbitrary servers (GitHub / Slack / Postgres / custom) via a unified protocol.

6.1.1 Three primitives

Plus sampling (the server may reverse-request the client to run an LLM call) and roots (the client exposes filesystem roots).

6.1.2 Transport + protocol stack

• Wire format: JSON-RPC 2.0
• Transport: (a) stdio (local server, the host process forks-execs the server); (b) Streamable HTTP (HTTPS POST + SSE bidirectional stream, upgraded in spring 2025, replacing the older HTTP+SSE)

• Lifecycle (2025-11-25 spec):

  1. initialize request: client reports protocol version + capabilities
  2. initialize response: server reports capabilities + serverInfo
  3. initialized notification: handshake completed
  4. Business methods (tools/call, resources/read, prompts/get, etc.)
  5. Closing the transport terminates the session — the spec explicitly does not define a shutdown message; for the stdio transport, closing stdin/stdout ends it; the HTTP transport is closed by the client.

6.1.3 Capability negotiation

// client → server
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
  "protocolVersion":"2025-11-25",
  "capabilities":{"sampling":{}, "roots":{"listChanged":true}},
  "clientInfo":{"name":"claude-desktop","version":"1.x.y"}
}}

// server → client
{"jsonrpc":"2.0","id":1,"result":{
  "protocolVersion":"2025-11-25",
  "capabilities":{
    "tools":{"listChanged":true},
    "resources":{"subscribe":true,"listChanged":true},
    "prompts":{"listChanged":true}
  },
  "serverInfo":{"name":"github-mcp","version":"0.x.y"}
}}

The version is a date string (the spec uses dated revisions: 2024-11-05 → 2025-03-26 → 2025-06-18 → 2025-11-25), not semver.

6.1.4 Security model (frequent interview follow-up)

• Local stdio: process isolation + OS permissions; only the host can spawn the server, relatively safe;
• Remote HTTP: uses OAuth 2.1 (added in the 2025-03 spec) plus the Authorization header; DCR (Dynamic Client Registration, RFC 7591) was demoted from SHOULD to MAY in the 2025-11-25 spec — clients and authorization servers may support it but it is no longer required; CIMD (Client ID Metadata Documents) was introduced as an alternative without preregistration;
• Prompt injection via tool/resource output: the protocol layer cannot prevent this — MCP feeds arbitrary content directly into the LLM context, so a malicious server can inject "<system>Ignore previous instructions and ...". Production mitigations: (1) the host marks content as untrusted and sandboxes it; (2) a classifier filters tool results; (3) restrict the whitelist of spawnable servers.

6.2　A2A (Agent-to-Agent Protocol)

Google released A2A in 2025-04 and donated it to the Linux Foundation on 2025-06-23. By 2026Q1 v1.0 has been released — structurally it has a few non-backward-compatible changes from v0.3 (unified Part structure, all enums to SCREAMING_SNAKE_CASE like TASK_STATE_SUBMITTED, ISO-8601 UTC millisecond timestamps, introduction of signed agent card / multi-tenant / multi-protocol binding). The Agent Card design preserves backward-discoverability (an agent can simultaneously declare support for v0.3 + v1.0). This section uses v0.3 field names to explain concepts; v1.0 differs at the upper-level enum/naming layer but the mechanism is the same. A2A ↔ MCP relationship: MCP connects an agent to tools / data; A2A connects an agent to other agents.

6.2.1 Agent Card

Each A2A-compliant agent exposes a JSON at /.well-known/agent-card.json:

// v0.3-style example (field names per the official spec; only key fields shown)
{
  "protocolVersion": "0.3.0",
  "name": "PurchasingAgent",
  "version": "1.0.0",
  "description": "Buys items from approved vendor catalogs.",
  "url": "https://agent.example.com/a2a",
  "preferredTransport": "JSONRPC",       // v0.3: declares the primary transport
  "additionalInterfaces": [               // The same agent can expose multiple transports
    {"transport": "GRPC", "url": "grpc://agent.example.com:50051"},
    {"transport": "HTTP+JSON", "url": "https://agent.example.com/a2a/rest"}
  ],
  "capabilities": {"streaming": true, "pushNotifications": true},
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {"id": "buy", "name": "Buy item", "description": "..."}
  ],
  "securitySchemes": {                    // v0.3: aligned with OpenAPI's schemes shape
    "bearerAuth": {"type": "http", "scheme": "bearer"}
  },
  "security": [{"bearerAuth": []}]
}

Discoverable: another agent can GET /.well-known/agent-card.json for the capability description and decide automatically whether to delegate.

6.2.2 Task lifecycle

The central abstraction of A2A is the Task; the v0.3 state machine:

submitted ──→ working ──┬──→ completed
                        ├──→ failed
                        ├──→ canceled
                        ├──→ rejected
                        ├──→ input-required ──→ (user/agent reply) ──→ working
                        ├──→ auth-required ──→ (credentials provided) ──→ working
                        └──→ unknown   (heartbeat lost / unobservable)

The default wire is JSON-RPC 2.0; from v0.3 you can also choose gRPC or HTTP+JSON/REST (declared via the agent card's preferredTransport field); SSE streaming + push notifications are optional.

6.2.3 Position of MCP vs A2A in the architecture

┌──────────────┐                              ┌──────────────┐
│ Host App     │                              │ Host App     │
│ (Claude /    │ ←── A2A (agent ↔ agent) ──→  │ (Other vendor│
│  Cursor)     │                              │  agent)      │
└──────┬───────┘                              └──────┬───────┘
       │ MCP (agent → tool/data)                     │ MCP
       ↓                                             ↓
┌──────────────┐  ┌──────────────┐         ┌──────────────┐
│ MCP server   │  │ MCP server   │         │ MCP server   │
│ (GitHub)     │  │ (Postgres)   │  ...    │ (Vendor DB)  │
└──────────────┘  └──────────────┘         └──────────────┘

6.3　Minimal MCP server skeleton (Python)

# Using the official SDK: pip install mcp
import asyncio
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent

app = Server("weather-mcp")

@app.list_tools()
async def list_tools() -> list[Tool]:
    return [Tool(
        name="get_weather",
        description="Get current weather for a city.",
        inputSchema={
            "type": "object",
            "properties": {
                "city": {"type": "string"},
                "unit": {"type": "string", "enum": ["c", "f"]}
            },
            "required": ["city"]
        }
    )]

@app.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    if name != "get_weather":
        raise ValueError(f"unknown tool: {name}")
    city = arguments["city"]
    unit = arguments.get("unit", "c")
    # In a real scenario: call an external API; here we return a stub
    temp = 22 if unit == "c" else 71
    return [TextContent(type="text",
                        text=f"{city}: {temp}°{unit.upper()}")]

async def main():
    async with stdio_server() as (read, write):
        await app.run(read, write, app.create_initialization_options())

if __name__ == "__main__":
    asyncio.run(main())

Host configuration (Claude Desktop style):

{
  "mcpServers": {
    "weather": {"command": "python", "args": ["weather_server.py"]}
  }
}

§7 Engineering patterns: subagent / tool retrieval / memory / budget

7.1　Subagent orchestration

As tasks get longer, the context window of a single agent isn't enough. The core idea of a subagent (a.k.a. delegated agent): the parent agent forks a child agent at certain steps; the child completes a sub-task in isolated context and only returns a summary.

┌─────────────────────────────────────────────────────────┐
│ Parent agent  (system prompt + main goal)               │
│   step 1: ... [in-context]                              │
│   step 2: SPAWN(child, "research X and return summary") │
│           ↓                                              │
│           ┌──────────────────────────────┐              │
│           │ Child agent                   │              │
│           │  - independent context window │              │
│           │  - independent (trimmed) tools│              │
│           │  - runs N steps → returns summary │           │
│           └─────────────┬────────────────┘              │
│                         ↓                                │
│   step 2 result: "summary: ..."                          │
│   step 3: ... [continue with summary in main context]   │
└─────────────────────────────────────────────────────────┘

Why is this a key architecture?

• Context isolation: the child's internal exploration failures, long traces, noisy observations don't pollute the parent's main context;
• Tool/permission scoping: the child can be given a trimmed tool set (e.g. read-only), reducing risk;
• Parallelism: the parent can spawn multiple children simultaneously (exploration branches, A/B comparison).

Anthropic's Claude Code subagents, Cognition Devin, Manus all use this architecture.

7.2　Tool retrieval: tool pools of 100+

When the tool pool reaches 50-100, stuffing every tool schema into the system prompt causes problems:

• Prompt blowup: each tool schema is 100-200 tokens; 100 tools = 10-20K tokens;
• Model choice difficulty: an LLM's choice accuracy degrades on long schema lists;
• Cost: every inference re-passes 10-20K tokens.

Solution: Tool retrieval — embed tool schemas into a vector store, and per request:

import numpy as np

def embed(text: str) -> np.ndarray: ...   # replace: OpenAI / Cohere / local embedder

def cosine(a: np.ndarray, b: np.ndarray) -> float:
    return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b) + 1e-9))

def select_tools(user_query: str, all_tools: list, top_k: int = 10):
    """ Assume all_tools[i].embedding is precomputed once at startup """
    q_vec = embed(user_query)
    scored = [(t, cosine(q_vec, t.embedding)) for t in all_tools]
    return [t for t, s in sorted(scored, key=lambda x: -x[1])[:top_k]]

Only put the top-k tool schemas into the prompt. Optionally add 1-2 "always-include" tools (e.g. finish, ask_user) as a safety net.

• The query is the first line of the prompt, but the user's real intent may only become clear by the third paragraph → use a rewritten query (let the LLM rewrite the retrieval query first)
• For later steps in a multi-step task, the step-1 retrieved tools are not enough → do dynamic re-retrieval every N steps

7.3　Memory architecture

Agent memory is typically layered:

• The footgun of working memory is lost-in-the-middle (Liu et al. 2023, arXiv:2307.03172) — info in the middle of long context is ignored; mitigations: summarization + reordering (prepend key facts to the end).
• The footgun of long-term memory is stale recall — retrieved old memories clash with the current task; mitigations: memory aging / decay or active pruning during reflection.

7.4　Token budget / early termination

Production agents must include a hard budget guard:

import time

class BudgetGuard:
    def __init__(self, max_tokens=50_000, max_steps=20,
                 max_wall_clock_s=300, max_dollars=1.0):
        self.budgets = {"tokens": max_tokens, "steps": max_steps,
                        "time": max_wall_clock_s, "dollars": max_dollars}
        self.used = {k: 0 for k in self.budgets}
        self.t0 = time.time()

    def update(self, tokens_used=0, dollars_used=0):
        self.used["tokens"] += tokens_used
        self.used["dollars"] += dollars_used
        self.used["steps"] += 1
        self.used["time"] = time.time() - self.t0

    def should_stop(self) -> tuple[bool, str]:
        for k, v in self.used.items():
            if v >= self.budgets[k]:
                return True, f"budget_exceeded:{k}"
        return False, ""

    def graceful_finish(self, agent_state):
        """ Proactively ask the agent to summarize and Finish before budget runs out """
        # e.g. tokens used 80% → inject "You have limited time. Finalize."
        ...

§8 Computer-Use paradigm: agent as OS-user

8.1　Interface comparison

The core difference of a GUI agent (computer use / browser use) is that the action is not a textual tool call but mouse/keyboard operations:

Anthropic Claude 3.5 Sonnet (new) on 2024-10-22 was the first frontier model with native computer-use support: the API exposes a computer tool whose input is the current screenshot + task and whose output is {action: "left_click", coordinate: [x, y]}; the host application replays it as OS events.

8.2　Two major bottlenecks

8.3　Benchmark numbers (2024-2026)

§9 Complexity, cost, capacity planning

9.1　Token / cost model

The cost of a single agent task can be modeled as:

$$\text{Cost} \approx \sum_{t=1}^{T} \big[\, c_{\text{in}} \cdot |h_t| \;+\; c_{\text{out}} \cdot |y_t| \,\big]$$

• $T$ = number of steps;
• $|h_t|$ = step-$t$ prompt length (system + history trajectory $(a_1, o_1, \dots, a_{t-1}, o_{t-1})$ + current instructions);
• $|y_t|$ = step-$t$ LLM output token count = thought text + action text (distinguish from $o_t$ in §1.1; $y_t$ is the model's own output, $o_t$ is the observation from the environment);
• $c_{\text{in}}, c_{\text{out}}$ are input / output unit prices.

Key observation: $|h_t|$ grows linearly in $t$ (history accumulates), so total cost is $O(T^2)$ (every step sees a longer prompt). That's why long-horizon agent cost explodes.

Mitigations

9.2　Latency model

$$\text{Latency} \approx \sum_{t=1}^{T} \big[ T_{\text{LLM}}(t) + T_{\text{tool}}(t) \big]$$

Usually $T_{\text{LLM}}$ includes prefill ($\propto |h_t|$) + decode ($\propto |y_t|$, bounded by TPS; $y_t$ as defined in §9.1 = thought + action).

9.3　Reliability: pass@k and verifier-driven retry

$$\text{Pass@}k = 1 - (1 - p_1)^k$$

where $p_1$ is the single-shot success rate. If $p_1 = 0.5$, $\text{Pass@}5 \approx 97\%$. But this requires a ground-truth verifier (unit test / env reward / human) that can reliably judge success.

τ-bench's (Yao 2024-06, arXiv:2406.12045) $\text{pass}^k$ (all k attempts correct) is far below $\text{pass@}k$ (at least one attempt correct); it is a stricter reliability metric — GPT-4o on retail has $\text{pass}^8 < 25\%$, meaning "consistently getting it right" is still very far off.

§10 25 frequently-asked interview questions (L1 must-know / L2 advanced / L3 top-lab)

Ordered from the perspective of a gpt-5.5 xhigh-simulated top-lab interviewer.

L1 must-know (asked at any LLM Agent role)

L2 advanced (agent / research roles)

L3 advanced (top-lab / research direction)

§A Appendix: core paper timeline + one-sentence summary