AI / Agentic AI Interview Questions

Agentic AI refers to AI systems that go beyond generating text or answering questions, they perceive their environment, reason about a goal, take real actions through tools, and adapt based on what happens, continuing this loop until a task is complete.

Unlike a traditional chatbot that responds once per turn, an agent operates autonomously across multiple steps, deciding what to do next based on the outcome of its previous action rather than waiting for a human to prompt every step.

• Perceives input and relevant context
• Reasons about what action would move it toward its goal
• Acts by calling tools, APIs, or executing code
• Observes the result and adapts its next step accordingly

By 2026, this pattern has moved from experimental demos into production use across software engineering, finance, healthcare, and business operations.

Most agent architectures decompose into the same handful of core components, regardless of the specific framework used to build them.

These components work together in a loop: perception feeds reasoning, reasoning consults memory and produces a plan, and that plan is carried out through tool-based actions, whose results feed back into perception for the next cycle.

ReAct, short for Reasoning and Acting, is an agent pattern that interleaves explicit reasoning steps with tool-based actions, rather than jumping straight from input to action.

Loop:
  Thought = LM(context, previous_observation)
  Action = Parse(Thought)
  Observation = Execute(Action)
  context += [Thought, Action, Observation]

At each step, the agent writes out a thought about what to do next, takes an action based on that thought, observes the result, and folds that observation back into its context before deciding the next step.

Because the reasoning is explicit, ReAct agents can recover from errors mid-task, if a tool call fails, the agent can reason about the failure and try a different approach instead of silently continuing down a broken path.

Tool use, often implemented through function calling, is how an agent extends beyond generating language and actually affects the outside world, calling APIs, databases, or code execution environments.

• Each tool is described with a schema, its name, its purpose, and the parameters it expects
• The agent's reasoning engine selects a tool based on that schema, without needing to know how the tool is implemented internally
• The tool's response becomes an observation the agent factors into its next reasoning step

This separation matters, the agent only ever sees a tool's name and description, so the quality of that description effectively acts as the API contract between the agent and the tool.

Agent memory is generally split into a few distinct types, each serving a different purpose.

Short-term memory disappears once the session ends unless it's explicitly written to long-term storage, which is why persistent agents need a deliberate mechanism for deciding what's worth remembering beyond the current conversation.

A Multi-Agent System splits a complex task across several specialized agents rather than relying on a single agent to handle everything itself.

• Each agent can focus on a narrower responsibility, such as research, coding, or review
• Agents can run sequentially, in parallel, or under a hierarchical structure with a coordinating agent
• Specialization often makes the overall system faster and more capable than one generalist agent trying to do it all

The trade-off is added coordination complexity, agents need a way to hand off context and results to each other reliably, which is exactly the kind of problem orchestration frameworks and protocols like MCP are designed to address.

Chain-of-Thought reasoning is a prompting technique where a model is encouraged to write out intermediate reasoning steps before arriving at a final answer, rather than jumping directly to a conclusion.

• Breaks a complex problem into smaller, more manageable reasoning steps
• Makes a model's reasoning process visible and easier to debug
• Forms the reasoning backbone that patterns like ReAct build on top of, by pairing each reasoning step with an actual tool call

On its own, Chain-of-Thought is purely about reasoning in text, it doesn't take real actions, which is the key difference between it and an agentic pattern like ReAct.

Plan-and-Execute is an agent architecture where the agent generates a complete plan upfront, then works through each step of that plan sequentially, rather than re-reasoning from scratch after every single action.

• Produces the full sequence of steps needed to reach a goal before taking the first action
• Executes steps largely without repeated re-planning cycles, unless something unexpected happens
• Uses noticeably fewer tokens than ReAct on multi-step tasks, since it avoids a reasoning cycle before every single action

The trade-off is adaptability, because the plan is fixed upfront, a Plan-and-Execute agent is less naturally suited to tasks that need constant re-evaluation as conditions change mid-task.

Reflexion is a self-correction mechanism where an agent critiques its own recent actions and outcomes, then uses that internal feedback to adjust its future behavior within the same task.

• Adds an internal feedback channel on top of the normal reasoning-action loop
• Helps reduce compounding errors, where one small mistake early on snowballs into a completely wrong final result
• Supports iterative repair, letting the agent retry a failed approach with an adjusted strategy instead of repeating the same mistake

This is conceptually similar to a person pausing mid-task to ask whether their current approach is actually working, rather than blindly continuing down the same path regardless of results so far.

The OODA loop, Observe, Orient, Decide, Act, is a decision-making cycle borrowed from military strategy that maps closely onto how agentic AI systems operate in practice.

• Observe: the agent perceives its current context and any new information from the environment
• Orient: it interprets that information in light of its goal and what it already knows
• Decide: it chooses the next action to take
• Act: it executes that action through a tool or API call

Every agentic system, at its core, runs some variation of this cycle, whether it's explicitly framed as OODA, ReAct, or a custom reasoning loop.

Retrieval-Augmented Generation grounds a language model's output in external evidence by retrieving relevant documents or data before generating a response, rather than relying purely on what the model memorized during training.

• A retrieval step searches an external knowledge source, often a vector database, for content relevant to the query
• That retrieved content is added to the model's context before it generates an answer
• Reduces hallucination by anchoring answers in retrievable, verifiable source material

RAG treats retrieval as a first-class operation feeding into generation, which is also why it's often described as a specific case of tool use, retrieval being just another tool an agent can call.

Agentic RAG extends traditional RAG by letting an agent decide when, what, and how many times to retrieve, rather than performing one fixed retrieval step before every generation.

• The agent can reason about whether the retrieved content actually answers the question, and retrieve again if it doesn't
• Can combine retrieval with other tools, like calculations or API calls, within the same reasoning loop
• Supports multi-hop questions that require pulling information from several different sources before answering

The practical difference is that traditional RAG retrieves once and generates, while Agentic RAG treats retrieval as one tool among several that the agent's reasoning loop can invoke as many times as the task actually requires.

The Model Context Protocol is a standardized way for AI agents and applications to share tools, resources, and context, so agents can coordinate workflows across different systems more reliably.

• Lets an agent discover what tools and resources are available from an MCP server, rather than needing them hardcoded
• Uses JSON-RPC under the hood, supporting long-lived, stateful sessions with streaming results
• Aims to solve the interoperability problem of siloed agents that can't easily share capabilities or context

Rather than every agent framework inventing its own way to expose tools, MCP gives agent developers and tool providers a common protocol to build against.

Several frameworks have emerged to help developers build agentic systems, each with a somewhat different focus.

Most of these frameworks converge on the same underlying primitives, planning, memory, and tool invocation, but differ in how explicitly they let developers control the flow of execution versus leaving decisions to the model.

A Human-in-the-Loop checkpoint is a deliberate pause in an otherwise autonomous agent workflow where a human must review or approve an action before the agent proceeds.

• Commonly inserted before high-stakes or irreversible actions, like sending an email or executing a financial transaction
• Lets an agent operate autonomously for most of a task while still keeping a person accountable for the riskiest steps
• Can be implemented explicitly as a graph node in frameworks like LangGraph that require approval before continuing

This is a common practical compromise between full autonomy and full manual control, letting an agent handle the routine work while a human retains the final say on consequential actions.

Prompt injection is an attack where malicious instructions are embedded in content an agent processes, tricking it into behaving differently than the user intended.

• Can be hidden inside a document, webpage, or file the agent reads as part of its task
• Exploits the fact that an LLM can't reliably distinguish between instructions from the user and text that happens to look like instructions
• Becomes more dangerous for agents than for simple chatbots, since an agent with tool access can actually act on the injected instructions

This risk grows directly with how much external, untrusted content an agent is exposed to during its task, which is part of why tool access and permissions need careful scoping.

Context poisoning is a more subtle variant of prompt injection where an attacker doesn't inject an obvious command, but instead subtly manipulates a document or data source an agent will later read, altering the agent's behavior indirectly.

• Harder to detect than a blatant injected instruction, since the manipulated content can look like ordinary data
• Can influence an agent's later reasoning or tool choices without ever appearing as an explicit command
• Particularly relevant for agents that build up long-term memory from external sources over time

Because the manipulation is subtle and can accumulate silently in memory, context poisoning is one of the harder agentic security risks to catch through simple keyword-based filtering.

Tool injection is an attack where an attacker manipulates the instructions or metadata an agent receives about a tool, tricking it into executing a malicious function or targeting the wrong resource.

• Can exploit the fact that an agent typically trusts a tool's name and description without verifying its actual implementation
• Has been compared to a malicious macro in a document, hidden in plain sight and executed automatically once the agent processes it
• Can subvert human-in-the-loop guardrails, since the malicious instruction may execute before a human ever reviews the agent's output

Defenses generally focus on restricting which tools an agent can discover and call in the first place, rather than trying to detect malicious intent after the fact.

The Orchestrator-Worker pattern splits a multi-agent system into one coordinating agent, the orchestrator, and several specialized agents, the workers, that each handle a specific part of a larger task.

• The orchestrator breaks the overall goal into subtasks and assigns them to appropriate workers
• Workers execute their assigned subtask independently and report results back to the orchestrator
• The orchestrator assembles worker outputs into a final result, sometimes running several rounds of delegation

This pattern keeps individual workers simple and focused, while concentrating the harder problem of task decomposition and coordination in a single place.

Short-term memory in an AI agent corresponds to the active conversation and context within the current session, roughly equivalent to what fits inside the model's context window.

• Includes the current task, recent tool calls, and their observed results
• Disappears once the session ends unless it's explicitly saved somewhere persistent
• Limited by the size of the context window, which constrains how much recent history the agent can directly reference

Because short-term memory is bounded, long-running agents need strategies like summarization or offloading to long-term memory to avoid losing important earlier context as a task grows.

Long-term memory lets an agent retain knowledge across sessions rather than starting fresh every time, typically implemented through an external vector database or knowledge store.

• Stores information as embeddings that can be searched for semantic similarity to a new query
• Lets an agent recall relevant facts or past interactions from weeks or months earlier
• Requires deliberate write and retrieval logic, deciding what's worth saving and when to pull it back in

This is what separates an agent that remembers a user's preferences over time from one that treats every conversation as a completely blank slate.

Episodic memory captures specific past events along with temporal information, letting an agent recall not just facts but what happened, and roughly when.

• Useful for tasks where the sequence or timing of past events matters, not just the underlying facts
• Distinct from general long-term factual memory, which stores knowledge without necessarily tracking when it was learned
• Some memory architectures link individual episodic entries together into an evolving network, updating older entries as new related information comes in

This kind of memory is especially relevant for agents that need to reason about what they already tried, and when, such as a debugging agent tracking previous failed fixes.

• Prompt injection and context poisoning: malicious instructions hidden in content the agent processes
• Tool injection: manipulated tool metadata tricking the agent into harmful actions
• Data leakage: sensitive information exposed through tool calls or memory persistence
• Unauthorized persistence: memory stored longer, or in the wrong scope, than intended
• Limited observability: difficulty understanding what an agent remembers and why it made a given decision
• Compounding errors: small mistakes early in a multi-step task snowballing into a badly wrong final result

Most mitigations center on strict access controls, scoping and namespace boundaries, logging and audit trails, and retention policies, treating the agent's tool and memory access the same way you'd treat any other privileged system component.

Tree-of-Thoughts treats reasoning as a search problem, instead of following one linear chain of thought, the model explores multiple candidate reasoning paths as branches of a tree, and can backtrack from paths that aren't working.

• Generates several possible next steps at each point, rather than committing to just one
• Evaluates and prunes weaker branches, focusing compute on more promising paths
• Trades additional compute for greater reliability on problems where a single reasoning chain is prone to getting stuck

This makes it more expensive than a straight Chain-of-Thought approach, but more robust for problems where an early wrong turn would otherwise doom the whole answer.

A turn budget is a limit on how many reasoning-action cycles, or turns, an agent is allowed to take before it must stop, regardless of whether it has finished the task.

• Prevents an agent from looping indefinitely on a task it can't complete
• Bounds cost and latency, since each additional turn typically means more tokens and more tool calls
• Forces the agent, or its orchestrator, to make a decision once the budget is exhausted, such as returning partial results or escalating to a human

Setting an appropriate turn budget is a practical trade-off between giving an agent enough room to solve genuinely multi-step problems and preventing it from burning unbounded time and money on a task it's stuck on.

LangGraph represents an agent's workflow as a cyclical graph of nodes and edges, rather than leaving the entire flow of control up to the language model's own judgment.

• Nodes represent discrete functions or steps, like drafting a response or calling a tool
• Edges represent the possible transitions between nodes, often chosen conditionally based on the agent's output
• The model only decides which existing edge to take, it can't invent a transition path that isn't defined in the graph

This constrained, graph-based approach is described as the current standard for enterprise agent architecture in 2026, precisely because it makes an agent's possible behaviors predictable and auditable rather than fully open-ended.

Context bloat happens when an agent is connected to many tools or MCP servers at once, and each one injects its own tool metadata, descriptions, and prompts into the model's context window.

• Overwhelms the model with far more tool information than is relevant to the current task
• Can degrade the model's ability to pick the right tool, since it's sorting through excessive irrelevant options
• Increases token cost even when most of that injected context goes unused

Common mitigations include selective tool injection, only exposing tools relevant to the current step, intelligent prompt chaining, and routing tool access through a centralized gateway rather than exposing everything at once.

Grounding refers to connecting an agent's reasoning and language output to real, verifiable information or a real environment, rather than letting it generate plausible-sounding but unverified claims.

• Retrieval-augmented generation grounds answers in retrieved documents
• Tool use grounds actions in real API responses and environment feedback, not just the model's internal assumptions
• ReAct's explicit observation step is itself a grounding mechanism, forcing the agent to react to what actually happened rather than what it expected to happen

Poorly grounded agents are the ones most prone to hallucination and confidently wrong actions, since without a grounding mechanism, there's nothing forcing their reasoning to stay tethered to reality.

The key distinction isn't the underlying language model, it's the loop, a chatbot waits for the next instruction, while an agent decides its own next step based on the outcome of its previous action.

Choosing between them usually comes down to whether a task's steps are predictable in advance, favoring Plan-and-Execute, or whether the agent needs to react to unexpected conditions along the way, favoring ReAct.

ReAct's core loop performs a full reasoning-action-observation cycle before every single step, which means every action in a multi-step task pays for another round of model inference.

• Each cycle consumes additional tokens for the reasoning text generated before the action
• Sequential reasoning and observation steps add latency, since each one depends on the result of the previous action
• Costs become less predictable, since the number of cycles needed to finish a task isn't known upfront

Plan-and-Execute avoids most of this overhead by generating the full plan once and executing it with minimal re-reasoning, at the cost of being less able to adapt if the plan turns out to be wrong partway through.

An agent's reasoning engine, typically the underlying LLM, selects a tool based purely on the tool's declared name and description, without any visibility into how that tool is actually implemented.

• Each available tool exposes a schema describing its purpose and expected parameters
• The agent compares its current goal against these descriptions to decide which tool is most relevant
• Because the model can only see the schema, not the implementation, that schema effectively functions as the contract between the agent and the tool

This is why poorly written tool descriptions are a common, underrated cause of agent misbehavior, a vague or misleading description can lead a perfectly capable model to pick entirely the wrong tool.

A single-loop agent works well for tasks that are relatively linear and don't need much structural control over what happens next.

• Use a graph-based, hierarchical architecture when a workflow has clear branching logic, like different paths for success versus failure
• Useful when specific steps need mandatory checkpoints, such as a human approval node before an irreversible action
• Better suited to enterprise workflows where auditability and predictable execution paths matter more than maximum flexibility

The trade-off is flexibility, a single-loop agent can improvise more freely, while a graph-based structure trades some of that freedom for a workflow whose possible paths are fully known in advance.

A Human Approval Node is a deliberate pause point in a graph-based agent workflow that blocks progress until a person reviews and approves the agent's proposed next action.

• Commonly placed between a draft step and an execution step, such as between drafting an email and actually sending it
• Protects against irreversible or high-consequence actions being taken purely on the model's own judgment
• Keeps a human accountable for the specific decisions that matter most, without requiring manual approval for every routine step

This reflects a broader design principle, full autonomy isn't the goal for every workflow, controlled autonomy, with explicit checkpoints at the riskiest points, is often the more practical target.

The shift from RAG to Agentic RAG mirrors the broader shift in agentic AI generally, moving from a fixed pipeline to a reasoning loop that adapts its own next step based on what it's already learned.

Compounding errors happen when a small mistake early in a multi-step task goes unnoticed and cascades into a badly wrong final result several steps later.

• Reflexion adds an internal feedback channel where the agent critiques its own recent actions and outcomes
• This self-critique step can catch a mistake shortly after it happens, rather than only surfacing it at the very end
• The agent can then adjust its approach and retry, rather than continuing to build on a flawed foundation

In effect, Reflexion trades a bit of extra compute for periodic self-checks, aiming to catch errors while they're still cheap to fix rather than after they've propagated through several more steps.

In the common MCP architecture pattern, the MCP server acts purely as a stateless provider of tools, resources, and prompt templates, while the MCP client hosts the actual LLM runtime and agent logic that decides what to call and when.

• A stateless server can be reused and replaced without worrying about losing session-specific state
• Keeps the decision-making logic centralized in the client, which simplifies reasoning about what the agent is actually doing
• Makes the server simpler to scale, since any instance can serve any request without needing shared session context

This isn't a hard requirement of the protocol itself, some architectures do run LLM logic on the server side for centralized control, but the stateless-server pattern is the simpler, more common default when strong dynamic orchestration isn't a priority.

MRKL-style systems route tasks to specialized tools or modules, separating natural language understanding from deterministic components rather than asking the LLM to reason through everything itself.

• A router decides which specialized tool or module should handle a given part of the task
• Deterministic components, like a calculator or a database query, handle the parts they're reliable at, rather than relying on the LLM to compute them
• Improves governability, since specific responsibilities are clearly separated rather than blended into one opaque reasoning process

End-to-end LLM reasoning, by contrast, asks the model to handle the entire task itself, which is more flexible but loses the reliability guarantees that come from delegating well-defined subtasks to deterministic tools.

Rather than letting an agent act with blanket, unverified trust, an OAuth-based flow establishes identity for the specific session, producing a token that represents a particular user acting through a particular agent, with defined scopes.

• Every action the agent takes carries an identifier tying it back to the real user and the specific rights that were delegated
• Limits what the agent's token can actually do, rather than granting it the full permissions of whichever account it's connected through
• Moves permission logic to an external policy decision point instead of hardcoding it inside the MCP server itself

This addresses a core agentic security concern, without this kind of scoped identity, there's no way to distinguish the agent acting on behalf of a specific authorized user from the agent acting with unrestricted access, which is a much riskier default.

Each MCP server an agent connects to injects its own tool metadata, descriptions, and prompt templates into the model's context window, and those injections stack up as more servers are added.

• The model ends up sorting through far more tool options than are relevant to its current task
• Extra, unused context still consumes tokens and can dilute the model's attention on what actually matters
• Left unmanaged, this can degrade tool selection accuracy even though each individual server's metadata is reasonable on its own

Mitigations like selective tool injection and centralized orchestration gateways exist specifically to expose only the tools relevant to the current step, instead of dumping every connected server's full capability list into context at once.

The right choice depends on task structure, sequential fits pipelines where each stage genuinely depends on the last, hierarchical fits tasks that decompose cleanly into independent subtasks, and concurrent fits tasks where speed matters and subtasks don't depend on each other's results.

A human-in-the-loop checkpoint is designed to review the agent's proposed output before anything consequential happens, but some injection attacks are specifically crafted to trigger execution before that review ever occurs.

• Malicious instructions hidden in a document or data source the agent reads can be executed as part of the agent's normal processing, not as a separate reviewable step
• This can subvert the trust boundary the human checkpoint was meant to enforce, since the harmful action already happened by the time a human sees the output
• Comparable to a malicious macro in a document, hidden in plain sight and triggered automatically once the file is processed

This is why effective defenses focus on restricting what an agent can do with untrusted content in the first place, sanitizing inputs and scoping tool access, rather than relying solely on a human review step positioned after the fact.

A freeform agent loop lets the model decide its own next step at every turn, which is flexible but makes the space of possible behaviors hard to predict or audit.

• A hardcoded graph defines the exact set of nodes and possible transitions in advance, so the model can only choose among pre-approved paths
• Makes it straightforward to insert mandatory checkpoints, like human approval, at exactly the points where they're needed
• Produces execution traces that are easier to audit, since every possible path through the workflow is already known and documented

For enterprise use cases involving real money, real customer data, or compliance requirements, this predictability is usually worth more than the extra flexibility a fully freeform loop would offer.

MCP's protocol-driven orchestration is most valuable when dynamic tool discovery and flexible, standardized coordination across many different tools and agents is a priority.

• If the main goal is simplicity and integrating with existing systems you already control, exposing agents as plain SDKs or microservices removes the protocol overhead entirely
• SDK/microservice integration is a better fit for a small, stable set of tools that rarely change and don't need to be dynamically discovered
• MCP earns its complexity specifically when you need reusable, swappable tool providers across many different agent clients

In short, MCP trades some simplicity for interoperability and dynamic orchestration, so if you don't actually need that flexibility, a direct SDK or microservice integration is often the simpler and more maintainable choice.

1. The agent generates a thought about what action to take and selects a tool accordingly
2. It executes the tool call, but the tool returns an error or unexpected result, such as a failed API request
3. Because ReAct explicitly folds observations back into context, the agent sees this failure as part of its next reasoning step, rather than the loop silently continuing as if it had succeeded
4. The agent reasons about why the call likely failed and what alternative approach might work, such as retrying with different parameters or trying a different tool entirely
5. It takes the revised action and continues the loop, or, if it's exhausted reasonable alternatives or its turn budget, escalates to a human or returns a partial result

This explicit failure-handling step is exactly what a purely generative, non-agentic system lacks, without an observation step, there's no mechanism forcing the model to notice and react to something having gone wrong.

1. The agent receives the overall goal and, before taking any action, generates a full decomposition of that goal into an ordered sequence of steps
2. Each step in this initial plan typically corresponds to a specific tool call or sub-task, established upfront rather than decided step-by-step later
3. Execution then proceeds through this sequence largely without pausing to re-reason at every step, unlike ReAct's per-step reasoning cycle
4. Re-planning is triggered only when something unexpected blocks progress, such as a step failing in a way the original plan didn't account for

This upfront decomposition is what gives Plan-and-Execute its token efficiency on predictable, multi-step tasks, the cost of full re-reasoning is paid once during planning rather than repeatedly during execution.

1. Active session: information starts in short-term memory, living inside the current context window as the conversation or task unfolds
2. Filtering: not everything is worth keeping, so a decision, whether rule-based or model-driven, determines what's significant enough to persist
3. Encoding: selected information is converted into an embedding, or in some architectures, an LLM-generated structured note with keywords and context
4. Storage: that encoded memory is written to a long-term store, commonly a vector database
5. Retrieval: in future sessions, a similarity search pulls back relevant stored memories to enrich the agent's current context

Some more advanced memory architectures go a step further, letting new incoming information trigger updates to existing stored memories, creating an evolving, interconnected network rather than a simple append-only log.

Chain-of-Thought commits to a single linear sequence of reasoning steps, generating one thought after another until it reaches an answer, with no mechanism to reconsider an earlier step if it turns out to be a dead end.

1. Tree-of-Thoughts instead generates multiple candidate next thoughts at each step, treating reasoning as a search over a tree of possibilities rather than one fixed path
2. Each candidate branch is evaluated for how promising it looks toward solving the problem
3. Weaker branches are pruned, while the model spends more computation expanding the more promising ones
4. The model can effectively backtrack, abandoning a branch that led nowhere in favor of a different one explored earlier

The trade-off is straightforward, Tree-of-Thoughts uses substantially more compute than a single Chain-of-Thought pass, but is considerably more robust on problems where a single early misstep would otherwise doom the entire reasoning chain.

• Favor Plan-and-Execute over ReAct for sub-tasks with predictable steps, avoiding repeated reasoning cycles
• Use selective tool injection so each agent only sees the tools relevant to its specific role, reducing context bloat
• Cache and reuse retrieval results across agents working on the same task, instead of each agent independently re-querying the same data
• Set sensible turn budgets per agent so a stuck sub-agent fails fast rather than looping expensively
• Run independent sub-tasks concurrently rather than sequentially, when they don't depend on each other's output
• Route through a centralized gateway for tool access, reducing the redundant metadata injected by many separately connected servers

Most of these optimizations come down to the same underlying idea, give each agent only as much reasoning freedom, tool visibility, and retry budget as its specific sub-task actually needs, rather than a uniformly generous default applied everywhere.

1. Review the tool's schema and description, since the agent only ever sees the declared name and description, not the implementation, a vague or overlapping description is a common root cause
2. Check for context bloat, if many tools with similar-sounding descriptions are all injected into context at once, the agent may struggle to distinguish between them
3. Examine recent reasoning traces to see what the agent's stated thought was before the wrong tool call, this often reveals a misunderstanding rather than a random error
4. Test whether narrowing the set of tools exposed for that specific step resolves the issue, which points to a selection problem rather than a reasoning problem
5. Check whether the underlying task itself is genuinely ambiguous, in which case the fix may be clarifying the prompt or goal rather than the tool descriptions

In most cases, this kind of misbehavior traces back to the tool's description acting as an unclear contract rather than a flaw in the model's reasoning ability itself, which is why refining descriptions is usually the first and most effective fix to try.