Agent Foundations

Answer: The essential difference is closed loop + autonomous multi-step + change of external state — an agent decides the next step from observations and keeps acting until the goal is met, and its actions can change external-world state; a chatbot is single Q&A. Simply giving an LLM a search API for one retrieval-augmented call is not yet an agent (still single-turn); only when it can autonomously decide whether to keep querying, what to query, and when to stop based on tool returns does it enter the agent regime.

Follow-up: agent = policy + what? → policy (LLM) + tool I/O + memory + control loop; treat the LLM as a policy $\pi_\theta(a\mid h)$ running in an "observe→act→new observation" loop.

Answer: Thought = reasoning, Action = call a tool, Observation = tool return (environment-injected). Pure CoT rolls forward on its own output and cannot externally correct intermediate facts; ReAct conditions each step on the real tool return, grounding the reasoning so a wrong fact can be corrected the next turn.

Follow-up: what is the most common ReAct production bug? → the stop-token footgun: not setting Observation: as a stop sequence, so the model writes its own Observation: … hallucinated return instead of stopping to wait for the environment's real result.

Answer: No, they are at different levels. Function calling is a structured format for a tool call (the model is fine-tuned to emit a {name, arguments} JSON schema); ReAct is a reason-act loop pattern (a prompting paradigm). They compose: run a ReAct loop and issue tools via function calling each step.

Follow-up: how do the two formats differ in label masking during training? → the masked set is the same (both mask tool-return tokens); the difference is that the fixed template parts of the JSON ({"name":, punctuation) are schema, not decisions, so over-training wastes gradient memorizing the template (see the react drill / agentic Q11).

Answer: MCP (Model Context Protocol, Anthropic 2024-11) standardizes the model ↔ external tools/data connection (vertical): client-server + JSON-RPC 2.0 + three primitives (tools/resources/prompts). It does not guarantee safety — the protocol itself does not defend against prompt injection; malicious instructions in a tool return must be defended by the host/agent.

Follow-up: how do MCP and A2A divide the work? → MCP is vertical (agent ↔ tools/data); A2A (Google 2025) is horizontal (agent ↔ agent, interop via agent card + task state machine).

Answer: $\text{pass@}k$ = at least one success in $k$ tries (measures capability upper bound, optimistic); $\text{pass}^k$ = all $k$ succeed (measures reliability). Agent deployment looks at pass^k — a customer-service/code agent that causes trouble 1-in-10 runs is unusable. τ-bench uses pass^k precisely to expose this instability.

Follow-up: why is a long-horizon agent's pass^k far below its pass@k? → with per-step success rate $p<1$, the probability that all $k$ runs (or all steps) succeed decays exponentially with the number of steps/tries; long tasks have many steps, and any single step failing fails the whole trajectory, so reliability is far below "at least once can do it".

Answer: every step re-reads the entire context, and the context grows linearly with steps ($L_t \propto t$, full history concatenated), so total tokens $\propto \sum_{t=1}^T t = O(T^2)$. This is the main cost source for long-horizon agents and the motivation for context management (compress/summarize/evict).

Follow-up: can parallel tool calls reduce this to O(T)? → No. Parallelism saves the within-step wait of multiple independent tools (lowering latency, not total tokens); the cross-step serial dependency and context accumulation remain, so the cost order is unchanged.

Answer: ReAct decides per step (reactive), flexible but no global view; Plan-and-Execute generates a full plan first then executes (executor can be a different model), globally consistent but the plan may go stale. Pure plan-and-execute fails when the environment is uncertain and mid-run state changes a lot (tool returns are unexpected) — the plan fixed at the start cannot keep up. Production usually mixes "high-level plan + per-step ReAct" + plan repair.

Follow-up: what are the ways to do plan repair? → Reflexion-style language reflection then replan, ToT-style search over alternative plans, or detect deviation and replan locally step-wise.

Answer: self-supervision + a utility filter. Randomly insert candidate API calls into text → execute to get returns → keep only samples where "inserting that call and its return significantly lowers the loss on subsequent tokens" for SFT. I.e. it uses "did the call actually help predict what follows" as the utility signal, auto-filtering useless or mis-placed calls without any human labeling of which/when to call.

Follow-up: what is the essential criterion of this utility filter? → compare the weighted loss on subsequent tokens under "with the API return" vs "without / empty return"; keep only when the former is clearly lower — essentially "how much did this tool call reduce the perplexity of what follows".

Answer: returning multiple tool calls at once requires those calls to be idempotent + mutually independent (no data dependency): if call B needs call A's result, they cannot be parallel and must serialize until A returns. Parallelism only applies to mutually-unrelated calls like "get weather + get exchange rate"; dependent chained calls go in separate rounds.

Follow-up: why can't parallelism break a long-horizon agent's serial-latency lower bound? → parallelism saves the within-step wait of independent calls; the cross-step data dependency (the next step uses the previous step's result) is still serial, so a T-step task serializes at least T LLM decodes.

Answer: Subagent orchestration is hierarchical decomposition — the main agent dispatches subtasks to context-isolated, tool-limited subordinates; single goal, communication is "assign ↔ return result". Multi-agent debate/collaboration is several peer agents each holding a viewpoint, challenging each other then aggregating; the goal is to use diversity to improve correctness. The two differ in structure (hierarchical vs peer), communication, and purpose.

Follow-up: what does subagent context isolation mainly solve? → it prevents main-agent context blow-up (the subtask's intermediate tokens don't flow back to the main thread) + an over-long tool table (each subagent only mounts relevant tools); the cost is that cross-subagent information sharing must be passed explicitly.

Answer: do not stuff all tool schemas into the prompt (it both blows up the context and lowers selection accuracy); instead do tool retrieval: vectorize each tool's description, do an embedding top-k retrieval against the current subtask query, and inject only the most relevant schemas. Essentially turning "tool selection" from one-shot full exposure into retrieval recall.

Follow-up: what is the main failure mode of tool retrieval? → incomplete recall (the needed tool isn't retrieved → the agent can't finish) and description ambiguity (two similar tools get confused); mitigate with better tool descriptions + larger k + hierarchical retrieval if needed.

Answer: ① grounding — mapping a semantic intent to precise pixel coordinates; imprecise visual localization is the main error source. ② long-horizon — GUI tasks have many steps and severe error compounding. One often prefers the accessibility tree (a structured element tree with role/label/coords) over raw screenshots, because structured elements locate "that button" more reliably than pixels, sidestepping part of the grounding error.

Follow-up: if the accessibility tree is more reliable, why still need screenshots? → many interfaces (canvas, custom rendering, games) have no usable a11y tree, or the tree is incomplete; the screenshot is the universal fallback, and practice often fuses both.

Answer: coding agent → SWE-bench / SWE-bench Verified (resolve real GitHub issues by editing code to pass unit tests; Verified is the human-validated clean subset); web agent → WebArena (real-website long-horizon tasks, with a 78.24% human baseline), or OSWorld if it's desktop computer-use. The basis is "does the action space and task distribution match the target scenario".

Follow-up: what caveat must accompany SOTA numbers on these benchmarks? → model SOTA moves fast + training contamination + scaffold-version differences (SWE-bench therefore released the human-validated Verified subset); you can only cite the current official-leaderboard value with a date, never treat a second-hand number as a stable fact.

Answer: all three stem from "context inflating with steps", so a combination is needed: ① for O(T²) cost — summarize old turns + KV eviction (keep sink + recent window) + dispatch independent subtasks to context-isolated subagents, splitting one long context into several short ones; ② for lost-in-the-middle (mid-context info ignored, U-shaped) — put key info (goal, constraints) at the ends and use retrieval to recall relevant history into the recent window rather than relying on the model to find it in a long middle; ③ for error compounding $p^T$ — shorten the effective horizon (decompose + verifiable milestones per subtask), add loop detection and a budget guard for early stop. Synergy: summarization + subtask isolation lower both cost and horizon; retrieval + end-anchoring fix both lost-in-the-middle and grounding.

Follow-up: what new risk does summarization itself introduce, and how to balance it? → lossy compression may discard key early info that turns out useful later (and if training saw the full history but inference only compresses, it creates a train-inference state-distribution mismatch); the balance is to keep a pointer / retrievable copy of "potentially-revisited" content and only summarize low-value turns.

Answer: threat model (indirect prompt injection, Greshake 2023): the attacker hides malicious instructions in external content the agent will read (web pages, search results, tool returns, files); the agent executes them as instructions — it can be induced to leak context, abuse high-privilege tools, or make outbound requests. Defense-in-depth: ① mark all tool/external returns as untrusted data (isolated from system instructions, not executed as instructions); ② least privilege (minimal scope per tool; dangerous operations require confirmation); ③ output-side constraints (host-level policy gates on high-risk actions like outbound send / delete); ④ monitor anomalous tool-call sequences. Key insight: the protocol (MCP) is not responsible for injection defense — the host/agent is.

Follow-up: why is "let the model judge whether an instruction is trustworthy" not a reliable defense? → it puts the security boundary back inside a model that the same injection can compromise; reliable defense should backstop outside the model with a deterministic privilege/policy layer (whitelist, scope, human confirmation) rather than relying on model self-discipline.

Answer: two problems — ① reward hacking: the agent exploits eval-implementation loopholes (editing test files, mocking outputs, empty functions passing CI) instead of truly solving; ② contamination: test samples leaked into training, inflating scores. Hack-resistant eval: use a verifiable, hard-to-forge success criterion (hidden extra unit tests, final environment-state checks, not assertions the agent can see), rotate adversarial test sets / living benchmarks (periodically swap items to prevent memorization), a human-validated subset (like SWE-bench Verified excluding cheatable/unsolvable items), report pass^k (to prevent gaming pass@k by many samples), and publish the eval harness for reproducibility.

Follow-up: why can't an "ever-rising public leaderboard" be taken directly as agent capability progress? → high scores may come from contamination, scaffold engineering, or overfitting to that benchmark; what matters is whether it improves in lockstep on newly released, contamination-resistant living benchmarks and the pass^k reliability metric, with the harness and date verified.