Interview Questions: Agents and Tools

20 questions on “Agents and Tools” — with short answers and a link to an in-depth explanation of each topic.

How to use it: cover the answer, answer out loud within a minute, then compare. All sections are on the interview questions page. Topics marked “in Russian” are not translated yet.

• Tool Calling: How a Model Calls Tools · 4
• The Agent Loop and Stopping Criteria · 4
• Memory, Planning and Multi-Agent Systems · 4
• MCP: The Standard for Connecting Tools · 4
• Evaluating Agents: pass@k and Trajectories · 4

Tool Calling: How a Model Calls Tools (in Russian)

• “Does the model execute the tools itself?” — no, it generates a structured request; execution always happens in your code. This is the main trick question.
• “How do you improve call accuracy?” — fewer tools, detailed “what and when” descriptions, strict JSON schemas, returning validation errors to the model for a retry.
• “What is MCP and why is it needed?” — a standard for describing and connecting tools: write a server once, use it from any client.
• “How is tool calling different from JSON mode?” — both mechanisms are about generating to a schema; tool calling adds the loop “call → execution → result into the context → continue”.

The Agent Loop and Stopping Criteria (in Russian)

• “How is an agent different from a pipeline?” — in a pipeline the sequence of steps is fixed in code in advance; an agent chooses the next step and how many steps to take based on the situation.
• “How does an agent know it's time to stop?” — list all four criteria and stress that a verifiable success condition is more reliable than the model's self-assessment.
• “Why do agents break on long tasks?” — compounding errors: 95% per step is only ≈36% over 20 steps; fixed with verification and short, verifiable subtasks.
• “How do you debug an agent?” — read whole trajectories, not final answers; look for loops, lost observations, wrong tool choices.

Memory, Planning and Multi-Agent Systems

• “The context is overflowing — what do you do?” — compaction of old history, moving artifacts out to files, selective loading, delegating bulky subtasks to subagents.
• “What is lost in the middle?” — the model uses information from the middle of a long context worse; so “stuff everything into the window” is not a strategy.
• “The main pro and the main con of multi-agent systems?” — pro: a clean context for each subagent and parallelism; con: losses in handoff, more tokens, harder debugging.
• “When is one agent better than several?” — a short linear task or tightly coupled subtasks with shared state.

MCP: The Standard for Connecting Tools (in Russian)

• “Why MCP if there is function calling?” — the main question. Answer: different levels — function calling describes how the model asks to call a tool, MCP describes where tools come from and how they are delivered to the application.
• “What problem does MCP solve quantitatively?” — N applications × M sources = N×M integrations turn into N+M connections to the standard.
• “What are the risks of a third-party MCP server?” — someone else's code with permissions: supply chain, prompt injection via tool results, excessive privileges. Mitigated by least privilege and confirmation of dangerous actions.
• “What does an MCP server expose besides tools?” — resources (data for the context, read by the application) and prompts (ready-made templates).

Evaluating Agents: pass@k and Trajectories (in Russian)

• “How do you evaluate an agent for production?” — automatic task success + k runs: pass^k for reliability, cost (steps/tokens), checking the trajectory for dangerous actions.
• “Why isn't pass@1 enough?” — a single run is stochastic; pass@1 doesn't distinguish a stable agent from a lucky one, and the pass@1 ↔ pass@k gap shows instability.
• “Why a sandbox?” — reproducibility: a fixed initial state and isolation from the outside world, otherwise the metric is flaky and results are not comparable.
• “What's wrong with a 60% average success rate?” — it may be bimodal or hide reward hacking; look at the distribution across tasks and read the trajectories.