Top 30 AI Agent Developer Interview Questions and Answers [2026]

TL;DR: AI agent developer interviews in 2026 test whether a candidate can keep a tool-calling loop safe, cheap and measurable: stop conditions, tool design, permission checks, prompt injection defenses, trajectory evals and durable resume after a crash or an approval. Candidates should also know the Model Context Protocol 2026-07-28 revision, which removed sessions and the initialize handshake, and that OpenAI removed the Assistants API on August 26, 2026.

On July 28, 2026, the Model Context Protocol shipped a stateless core: no initialize handshake, no Mcp-Session-Id header, and every request carries its own protocol version.

Any agent stack that talks to MCP servers over HTTP is now being upgraded. The questions below test the engineering around the model: loops, tools, multi-agent orchestration, MCP, memory, evals, guardrails and production operations.

Agent Loops and Tools

1. What is an agent loop, and what ends it?

An agent loop calls the model, runs any tool calls it returns, appends the results to the context and calls the model again, until the model produces a final answer or a limit stops the run.

The OpenAI Agents SDK runner docs describe exactly this: final output ends the loop, a handoff swaps the active agent and loops again, tool calls are executed and appended, and passing max_turns raises MaxTurnsExceeded.

The SDK's default is 10 turns.

def run_agent(task, tools, max_turns=10, max_tokens=200_000):
    messages = [{"role": "user", "content": task}]
    used = 0
    for _ in range(max_turns):
        reply = call_model(messages, tools)
        used += reply.usage.total_tokens
        if not reply.tool_calls:
            return reply.text                      # final answer
        for call in reply.tool_calls:
            result = run_tool_with_checks(call)    # permissions, timeout, errors
            messages.append(tool_result(call.id, result))
        if used > max_tokens:
            raise BudgetExceeded(used)
    raise MaxTurnsExceeded(max_turns)

A strong candidate names more than one stop condition.

A turn cap alone does not bound cost when a single turn can pull 25,000 tokens of tool output, so production loops also cap tokens, wall-clock time and spend, and they decide in advance what the user sees when a cap fires.

2. When should you build a workflow instead of an agent?

Build a workflow whenever you can write the steps down in advance.

Anthropic's Building effective agents (December 19, 2024) draws the line clearly: workflows are systems where LLMs and tools are orchestrated through predefined code paths, while agents direct their own process and tool use.

The same post lists the workflow patterns to recognize. There are five: prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer.

An invoice extraction pipeline with a fixed schema is a chain with a validation gate, not an agent. A support assistant that must decide which of 40 internal APIs to call, in what order, is a reasonable agent.

The senior answer is about cost of failure. A workflow fails in a known place and can be unit tested step by step; an agent trades that predictability for flexibility.

Candidates who reach for an agent first, without asking whether the path is knowable, tend to ship systems that are slow and hard to debug.

3. How do you design a tool that an agent will use well?

Design it for the model, not as a thin wrapper over an existing API. Anthropic's Writing effective tools for agents (September 11, 2025) gives concrete rules:

• Namespace related tools under common prefixes, because an agent may see hundreds of tools from dozens of MCP servers.
• Bound the response size. Claude Code restricts tool responses to 25,000 tokens by default; use pagination, range selection, filtering or truncation with sensible defaults.
• Offer a response format switch, such as a response_format parameter for concise or detailed output, so the agent can ask for IDs only when it needs to chain calls.
• Describe each tool the way you would to a new hire on your team: what it is for, what the parameters mean, and what it returns.

Good candidates also fold common multi-step sequences into one tool. A schedule_event tool that finds availability and books the slot beats separate list and create tools that the model must chain correctly every time.

4. A tool call fails. What should the agent see?

An error message the model can act on, returned as a tool result rather than a crash. The MCP tools specification separates two kinds of failure. Protocol errors, such as an unknown tool name, are JSON-RPC errors.

Tool execution errors, such as API failures, invalid input and business rule violations, come back in the result with isError: true, and clients should pass them to the model so it can self-correct.

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "resultType": "complete",
    "content": [{ "type": "text",
      "text": "Invalid departure date: must be in the future. Current date is 08/08/2025." }],
    "isError": true
  }
}

The 2025-11-25 revision made this explicit for input validation: validation errors should be tool execution errors, not protocol errors, so the model sees what was wrong.

A weak answer returns a stack trace or a bare 500; a strong one returns the reason, the valid range and, where possible, the next step.

5. ReAct or plan-and-execute: how do you choose?

ReAct interleaves reasoning and acting step by step; plan-and-execute writes a plan first, then runs the steps, replanning only when something fails.

The ReAct paper (Yao et al.) describes generating reasoning traces and task-specific actions in an interleaved manner, where reasoning helps track and update the plan and actions pull in new information.

The trade-offs a senior candidate should state:

• ReAct adapts better when each observation changes what to do next, such as debugging or open-ended research. It costs a model call per step and can wander.
• Plan-and-execute is cheaper and easier to audit. The plan can be shown to a user for approval, independent steps can run in parallel, and a cheaper model can execute them. It breaks when early results invalidate the plan, so it needs an explicit replan trigger.

Most production agents mix the two: a short plan, ReAct-style execution inside each step, and a check against the plan after each step.

Asking how they would detect that a plan has gone stale separates hands-on candidates from those who have only read about the patterns.

6. How do you make tool calls safe to retry?

Make every tool with side effects idempotent, usually with an idempotency key derived from the task and the call.

Agents retry for many reasons: the model repeats a call, a timeout fires after the action succeeded, or a run resumes from a checkpoint and replays a step.

Practical rules: read tools need nothing special. Write tools take a key from the caller and, on a repeat, return what they stored the first time. Payment, email and ticket creation tools check for an existing record before acting.

Long-running actions return a handle that the agent polls instead of calling again.

Ask the candidate what happens if the process dies between "charge card" and "write result to state". The right answer involves a key the downstream system honors, not a hope that the agent will not call twice.

Multi-Agent Systems

7. When is a multi-agent system worth its cost?

When the task splits into independent, parallel lines of work that each need their own context, and the value of the answer justifies several times the token spend.

Anthropic's multi-agent research system post (June 13, 2025) reports that a lead agent on Claude Opus 4 with Claude Sonnet 4 subagents outperformed a single Claude Opus 4 agent by 90.2% on its internal research eval.

The same post gives the cost side: agents typically use about 4 times the tokens of chat, and multi-agent systems about 15 times. Token usage alone explained 80% of the performance variance on its browsing evaluation.

It also notes that most coding tasks have fewer truly parallel parts than research, and that agents are not yet good at coordinating with each other in real time.

A strong candidate turns this into a rule: use multiple agents for breadth-first work like research or wide codebase surveys, and keep a single agent for tightly coupled, sequential tasks.

8. Handoffs or agents as tools: what is the difference?

With agents as tools, a manager agent keeps control and calls specialists like functions. With handoffs, a triage agent passes the conversation to a specialist, which then owns the rest of the turn.

The OpenAI Agents SDK orchestration docs recommend agents as tools when one agent should own the final answer, combine specialist outputs or enforce shared guardrails in one place, and handoffs when routing is part of the workflow and the specialist should answer directly.

The detail that catches teams: guardrail placement changes with the pattern. In that SDK, input guardrails run only for the first agent in the chain and output guardrails only for the agent that produces the final output.

After a handoff, the specialist's own input guardrails do not run, so per-call checks belong on tools.

9. How do you stop subagents from duplicating work or overspending?

Give each subagent a precise brief and set effort rules in the orchestrator's prompt.

Anthropic's research post lists early failures: spawning 50 subagents for simple queries, searching endlessly for sources that did not exist, and subagents duplicating each other's work when task descriptions were vague.

The fixes from the same post: each delegation states an objective, an output format, guidance on tools and sources, and clear task boundaries.

Effort scales with complexity, written as explicit rules: simple fact-finding gets 1 agent with 3 to 10 tool calls, direct comparisons 2 to 4 subagents with 10 to 15 calls each, and complex research more than 10 subagents with divided responsibilities.

Senior candidates add hard limits in code as a backstop: a cap on subagents per run, a token budget per subagent, and condensed summaries returned to the lead agent instead of full transcripts.

10. MCP or A2A: which problem does each protocol solve?

MCP connects an agent to tools, data and prompts; Agent2Agent (A2A) connects one agent to another agent that it cannot see inside. An MCP server exposes functions the calling model decides to use.

The A2A protocol is built for communication between opaque agentic applications: each agent advertises its skills in an agent card, and the protocol supports streaming and asynchronous operations for long tasks.

Both now sit under the Linux Foundation.

The Linux Foundation launched the A2A project on June 23, 2025, with the protocol created by Google, and A2A 1.0.0 shipped on March 12, 2026 with breaking changes, including a tasks/list method and OAuth flows that drop implicit and password grants in favor of device code and PKCE.

The practical answer: inside your own system, subagents are usually plain function calls or agents as tools. A2A earns its place when the other agent belongs to another team or vendor and you need a contract, not shared code.

Model Context Protocol

11. What are MCP's server primitives, and who controls each?

Tools, resources and prompts, each with a different controller.

The server overview in the 2026-07-28 spec sets out the hierarchy: prompts are user-controlled templates such as slash commands; resources are application-controlled context such as file contents or git history; tools are model-controlled functions such as API calls and file writes.

The control column is the point of the question.

Because the model chooses tools, tools carry the security burden: the spec says there should always be a human in the loop with the ability to deny tool invocations, with clear indicators when tools are called.

A candidate who exposes a database as a tool that the model can query freely, when a resource the application attaches would do, has given the model more agency than the feature needs.

12. Which MCP transports exist, and when do you use each?

Two: stdio for a local server launched as a subprocess, and Streamable HTTP for a remote or shared server.

Per the transports spec, stdio messages are newline-delimited JSON-RPC; the server may log to stderr but must not write anything to stdout that is not a valid MCP message.

A stray print() in a Python stdio server is a classic cause of a broken connection.

Streamable HTTP uses a single MCP endpoint that accepts POST. Servers must validate the Origin header, and local servers should bind to 127.0.0.1, not 0.0.0.0, to block DNS rebinding attacks from a browser.

The old HTTP+SSE transport was replaced in 2025-03-26 and is now formally Deprecated under the feature lifecycle policy.

Authorization follows the transport: the spec says stdio servers should not use the OAuth flow and should take credentials from the environment, while HTTP servers that need auth follow the authorization spec.

13. How does authorization work for a remote MCP server?

The MCP server is an OAuth 2.1 resource server and the client is an OAuth 2.1 client.

The authorization spec requires servers to publish OAuth 2.0 Protected Resource Metadata (RFC 9728), which clients use to discover the authorization server.

Clients must use PKCE and Resource Indicators (RFC 8707), naming the MCP server in both the authorization and token requests so tokens are bound to it.

Two 2026-07-28 changes are worth asking about. Clients must validate the iss parameter against the recorded issuer before redeeming a code when the authorization server supports it (RFC 9207), which closes a mix-up attack.

And Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents, though it stays available for older authorization servers.

A senior candidate also knows that authorization is optional in the spec. An internal stdio server reading an API key from its environment is a valid design; a public HTTP server without auth is not.

14. What is token passthrough, and why is it forbidden?

Token passthrough is an MCP server accepting a token that was not issued to it and forwarding it unchanged to a downstream API.

The MCP security best practices state that servers must not accept tokens that were not explicitly issued for them, and list the risks: rate limits and monitoring keyed to the token audience are bypassed, audit trails lose the real caller, and the downstream API may trust the token as if the MCP server had validated it.

The correct pattern is for the MCP server to validate the audience claim of the token it receives, then use its own credentials, or a token obtained for the downstream API through its own flow, when calling onward.

The same page covers the confused deputy problem for MCP proxy servers that use a static client ID with a third-party API; those proxies must implement per-client consent.

15. Can a client trust a tool's readOnlyHint?

Not on its own. The tools spec says clients must consider tool annotations untrusted unless they come from trusted servers.

The MCP blog post Tool Annotations as Risk Vocabulary (March 16, 2026) explains the defaults: a tool with no annotations is assumed to be not read-only, potentially destructive, not idempotent and open-world.

Annotations are still useful from a server you have vetted: a client can skip a confirmation prompt for a trusted read-only tool and require one for anything destructive.

The same post frames the bigger risk with Simon Willison's "lethal trifecta": an agent that has access to private data, exposure to untrusted content and a way to communicate externally can be steered into leaking data.

Judging tools one at a time misses that, because the risk comes from the combination in one session.

Memory and Context

16. How do you design short-term and long-term memory?

Keep them separate. Short-term memory is the state of one conversation or run; long-term memory is information that should outlive it, such as user preferences or learned facts.

The LangGraph persistence docs map this onto two components: checkpointers persist a thread's state for continuity, human approval and fault tolerance, while stores hold application data across threads.

The OpenAI Agents SDK has the same split in different words: Sessions keep conversation history across runs, with backends such as SQLite, Redis, SQLAlchemy, MongoDB and an encrypted wrapper.

A session cannot be combined in the same run with server-managed continuation such as previous_response_id, so a team must pick one source of truth for history.

Senior candidates talk about what goes into long-term memory, not just where: who can write to it, how stale facts are corrected, and how one user's memory is isolated from another's. Memory written from untrusted content is a prompt injection that persists.

17. The context window fills up halfway through a long task. What do you do?

Compact, take notes outside the window, or split the work across subagents. Anthropic's context engineering post (September 29, 2025) names all three:

• Compaction: summarize a conversation that is nearing the limit and restart with the summary. The post calls it the first lever for long-run coherence.
• Structured note-taking: the agent writes notes to storage outside the context, such as a progress file or to-do list, and reads them back later.
• Sub-agent architectures: subagents explore in their own clean context and return condensed results.

The same post describes context rot: as the number of tokens in the window grows, the model's ability to recall information from it decreases. So a bigger window is not a fix.

Strong answers also mention clearing old tool results, which are often the largest and least useful part of a long transcript.

Evals and Tracing

18. How do you evaluate an agent: outcome or trajectory?

Grade the outcome first, and use the trajectory to explain failures and catch unsafe paths.

Anthropic's Demystifying evals for AI agents (January 9, 2026) defines the terms: the transcript, also called a trace or trajectory, is the full record of a trial; the outcome is the final state of the environment.

A flight-booking agent may say "your flight has been booked", but the outcome is whether the reservation exists in the database.

The same post warns against grading the exact path, because agents often find valid routes the eval author did not foresee; it is often better to grade what the agent produced.

Trajectory checks still matter for constraints: the agent must not call a refund tool without verifying the order, must not exceed a tool-call budget, must not touch production data.

Two hygiene rules from the post: start each trial from a clean, isolated environment so runs do not leak state into each other, and read the transcripts of failed tasks to check that the task itself is fair.

19. What is the difference between pass@k and pass^k?

pass@k is the chance that at least one of k attempts succeeds; pass^k is the chance that all k succeed.

The tau-bench paper introduced pass^k to measure reliability over repeated trials, and found GPT-4o function-calling agents succeeded on under 50% of tasks, with pass^8 below 25% in the retail domain.

The choice follows the product. A coding agent whose output a developer reviews can live with pass@k, since one good attempt is enough.

A customer-facing agent that runs the same workflow thousands of times a day needs pass^k, because each user gets one attempt.

As k grows, pass@k rises and pass^k falls, so the same agent can look strong or weak depending on which number is reported. Ask candidates which one their last eval used and why.

20. What goes wrong with LLM-as-judge, and how do you control it?

Judges have known biases.

The MT-Bench paper (Zheng et al.) names position bias, verbosity bias, self-enhancement bias and limited reasoning ability, while also finding strong judges reached over 80% agreement with human preferences, about the level humans reach with each other.

Controls a senior candidate should list:

• Swap answer order in pairwise comparisons and count only consistent verdicts.
• Use a rubric with specific criteria, and grade each dimension with a separate, isolated judge call, as the Anthropic evals post recommends, rather than one judge scoring everything.
• Calibrate against human graders on a sample, and recheck when the judge model or prompt changes.
• Prefer code-based graders (state checks, unit tests, schema validation) wherever the outcome can be checked deterministically.

The broader AI screening topics, such as RAG evaluation and offline metrics, are covered in our AI skills evaluation questions.

21. What should you trace for an agent in production?

Every model call, tool call, handoff and guardrail decision as spans in one trace per run, with token counts, latency and errors on each.

The OpenAI Agents SDK does this by default: per its tracing docs, tracing is on unless disabled with OPENAI_AGENTS_DISABLE_TRACING=1 or per run, and it is unavailable for organizations under a Zero Data Retention policy.

For vendor-neutral tracing, the OpenTelemetry GenAI conventions now live in their own semantic-conventions-genai repository.

They define spans such as invoke_agent {gen_ai.agent.name} and execute_tool {gen_ai.tool.name}, with attributes such as gen_ai.usage.input_tokens. All of it is still at Development status, so attribute names can change.

MCP 2026-07-28 also documents trace context propagation through _meta keys (traceparent, tracestate), so one trace can follow a call into an MCP server.

The senior follow-up is privacy: traces contain prompts and tool outputs, which often hold customer data. Ask how they redact, sample and set retention.

Guardrails and Safety

22. How do you defend an agent against indirect prompt injection?

Assume it will succeed sometimes, and limit what a hijacked agent can do.

OWASP LLM01:2025 defines indirect prompt injection as instructions arriving through external content such as websites or files, and lists least privilege first among mitigations: give the application its own API tokens and handle privileged functions in code, not through the model.

A layered answer:

• Break the lethal trifecta per session. If the agent reads untrusted email, it should not also have an unrestricted way to send data out.
• Scope credentials to the task, not the user's full account.
• Require approval for side effects that are hard to reverse, and show the exact arguments.
• Mark untrusted content in the context and validate tool arguments in code (allowlisted domains, recipients, amounts).

OWASP's LLM06:2025 Excessive Agency gives the vocabulary for the root causes: excessive functionality, excessive permissions and excessive autonomy.

A candidate who says a better system prompt solves injection has not shipped an agent that reads the open web.

23. Where do guardrails run, and what do they miss?

It depends on the guardrail type, and the gaps are where incidents happen.

In the OpenAI Agents SDK, per the guardrails docs, input guardrails run only for the first agent, output guardrails only for the agent that produces the final output, and tool guardrails on every guarded function-tool call.

The gaps a senior candidate should name from the same page: tool guardrails do not apply to handoff calls, to hosted tools such as web search, file search and hosted MCP, or to built-in execution tools such as shell and computer use.

For those, the controls are approvals, sandboxing and narrow credentials, not guardrail functions.

24. How do you build human approval into an agent run?

Mark the sensitive tools, pause the run when one is called, persist the paused state, and resume after a decision, possibly in a different process.

The OpenAI Agents SDK human-in-the-loop docs show the pattern: needs_approval on a tool, interruptions on the result, and a serializable RunState.

from agents import Agent, Runner
from agents.decorators import tool

@tool(needs_approval=True)
async def cancel_order(order_id: int) -> str:
    return f"Canceled order {order_id}"

agent = Agent(name="Support agent", tools=[cancel_order])
result = await Runner.run(agent, "Cancel order 1042")

while result.interruptions:
    state = result.to_state()          # serialize with state.to_string()
    for item in result.interruptions:
        if reviewer_approves(item.name, item.arguments):
            state.approve(item)
        else:
            state.reject(item)
    result = await Runner.run(agent, state)

Two details worth probing. A callable approval rule fails closed: if the arguments are missing, malformed or not a JSON object, the SDK requires manual approval.

And in the Claude Agent SDK, the permission order is hooks, deny rules, ask rules, permission mode, allow rules, then the canUseTool callback.

Deny rules block a call even in bypassPermissions mode, so hard limits belong in deny rules rather than in prompts.

Cost and Production

25. How do you set a cost and latency budget for an agent?

Start from the cost of one successful task, not one model call, and enforce limits in code. A task cost is model tokens across every turn, plus tool and infrastructure costs, divided by the success rate, since failed runs still cost money.

Levers a senior candidate reaches for:

• Hard caps on turns, tokens, wall-clock time and subagent count, each with a defined fallback.
• Model routing: a cheaper model for classification, extraction and subagent work; the strongest model for planning and final synthesis.
• Smaller tool outputs: pagination and concise response formats, since tool results usually dominate input tokens after a few turns.
• Stable prefixes for prompt caching: keep system prompts and tool lists identical across turns. MCP 2026-07-28 says servers should return tools/list in a deterministic order, partly to improve prompt cache hit rates.
• Blocking guardrails for cheap rejections, so the expensive model never starts on requests you would refuse.

For latency, the main tools are parallel tool calls, streaming partial output, and fewer sequential turns. Ask candidates for the per-task cost of something they shipped; vague answers are a signal.

26. How do you make a long-running agent survive crashes, deploys and approvals?

Checkpoint state after each step, make resumed steps idempotent, and deploy without cutting off runs in flight.

In LangGraph, per the durability modes docs, "exit" saves only when the graph exits, "async" saves while the next step runs with a small risk of losing a checkpoint on a crash, and "sync" saves before each next step starts.

config = {"configurable": {"thread_id": "order-1042"}}
for chunk in graph.stream({"input": "refund order 1042"}, config, durability="sync"):
    ...

The trap is in the interrupt docs: when a paused run resumes, the node restarts from the beginning, not from the line where it paused. Any side effect before the interrupt runs again, so it must be idempotent or moved to its own node.

Deploys are the other half. Anthropic's research post describes rainbow deployments for agents: traffic shifts gradually from the old version to the new one while both keep running, so agents mid-task are not broken by a code change.

It also describes resuming from where the agent was when an error occurred, rather than restarting expensive runs.

What Changed Recently

27. What changed in the MCP 2026-07-28 revision, and what breaks?

MCP went from a stateful, bidirectional protocol to a stateless request and response protocol. Per the 2026-07-28 changelog and the release post:

• The initialize handshake and the Mcp-Session-Id header are gone. Every request carries its protocol version and client capabilities in _meta, and servers must implement a new server/discover call.
• Streamable HTTP requests must send Mcp-Method and Mcp-Name headers, so gateways can route and rate limit without parsing JSON.
• SSE resumability is removed; a broken stream loses the in-flight request, and the client must re-issue it with a new ID.
• List results carry ttlMs and cacheScope cache hints, and every result carries a required resultType.
• Roots, Sampling and Logging are deprecated, under a new policy with a minimum twelve-month deprecation window.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
  "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

What breaks: servers that kept per-session state in memory, and gateways with sticky sessions keyed to the session header. The upside is that any request can land on any instance behind a plain round-robin load balancer.

28. Without sessions, how does an MCP server keep state or ask the user for input?

State moves into explicit handles, and questions to the user move into Multi Round-Trip Requests.

For state, the release post recommends that a tool mint a handle, such as a basket ID, and that the model pass it back as an ordinary argument on later calls.

The maintainers found this works better than state hidden in the transport, because the model can see the handle and thread it between tools.

For input, the MRTR pattern replaces server-initiated elicitation/create, sampling/createMessage and roots/list requests.

The server returns a result with resultType: "input_required" and the questions it needs answered; the client collects the answers and retries the original request with inputResponses.

Servers that need to correlate retries encode their own identifier in requestState.

Long-running work moved too: tasks left the core protocol and became the official io.modelcontextprotocol/tasks extension, polled with tasks/get.

A candidate who designed a server around held-open streams should explain how they would port it.

29. Who governs MCP now, and why does it matter for a buyer?

The Agentic AI Foundation, a directed fund under the Linux Foundation.

On December 9, 2025, Anthropic donated MCP to the foundation, co-founded by Anthropic, Block and OpenAI with support from Google, Microsoft, AWS, Cloudflare and Bloomberg.

The founding projects were MCP, Block's goose and OpenAI's AGENTS.md.

The technical process did not change: the same maintainers decide through Specification Enhancement Proposals, and the Linux Foundation does not set the technical direction.

For a company choosing an integration standard, vendor-neutral governance and the formal deprecation policy added in 2026-07-28 lower the risk that the protocol changes under them without notice.

Candidates should still pin the protocol version they support and test against it.

30. Which agent framework changes should a candidate know about?

Four, all checked against official release pages on October 16, 2026:

• OpenAI: the Assistants API was removed on August 26, 2026, one year after the deprecation notice, with the Responses API as the replacement. The OpenAI Agents SDK for Python is at 0.24.0 (October 15, 2026). Its versioning policy uses 0.Y.Z, where a minor bump can break public interfaces, so pin the minor version.
• Anthropic: the Claude Code SDK was renamed the Claude Agent SDK on September 29, 2025. Per the migration guide, the packages are now claude-agent-sdk for Python and @anthropic-ai/claude-agent-sdk for TypeScript.
• LangGraph: 1.0.0 shipped on October 17, 2025; the 1.2 line is current.
• Google ADK: ADK 2.0 reached general availability on May 19, 2026, adding a model-agnostic engine for non-linear, conditional and cyclical multi-agent workflows.

The point of the question is not trivia. Frameworks in this space ship weekly, so a strong candidate pins versions, reads breaking-change notes before upgrading, and keeps business logic in plain tools that would survive a framework swap.

Signs of a Strong Answer

• They name every stop condition of their loop (turns, tokens, time, spend) and what the user sees when each one fires.
• They return tool failures as actionable tool results, and can explain when the model should see an error and when code should handle it.
• They report pass^k or a per-task cost from a real eval, not a single demo run.
• They reason about the lethal trifecta per session and put hard limits in deny rules or code, not in the system prompt.
• They know which guardrails skip handoffs and hosted tools, and they make every side effect idempotent before adding approvals or checkpoints.
• They can say what the MCP 2026-07-28 revision changes for a server they built: sessions, handles, MRTR and the new headers.

Hiring AI Agent Developers

Engineers who have run agents in production, with evals, tracing and approval flows, are still rare.

Second Talent helps US startups hire vetted AI-Native Engineers from Asia, including AI agent developers screened with questions like these, at $29 to $39 USD an hour billed monthly.

See the cost to hire an AI agent developer, or read what the AI agent developer and AI agent operations engineer roles cover.

Shortlists arrive within 24 hours, and every placement has a 90-day one-time replacement guarantee. Tell us what you need to start.