AI agent interview questions: how agent design rounds are scored

Agent questions go wrong in a familiar way: the candidate draws five agents before one works. Interviewers in forward deployed engineer loops want the opposite instinct: the smallest system that does the job, with hard limits around it.

This guide covers the Agents topic in the FDEBench bank, plus the agent questions filed under grounding and safety and under memory. For the whole loop, see the round-by-round guide.

What do agent design interviews ask?

They ask you to build an agent, fix one, or explain what makes one reliable. A broad prompt reported at Salesforce covers most of it: "Describe how you would architect an AI agent system: the agent loop, tool interfaces, memory design, orchestration, and safety."

• Fix one: "Your AI agent keeps calling the wrong tool. How do you fix it?" Or the context budget: "An agent has access to several hundred tools. Their definitions consume most of the context window before the user’s request is even read. Design a fix."
• Explain the mechanism: "What is an agent harness, and what specifically does it add over a well-engineered single prompt for a long-running task?"
• Recover and coordinate: "Design an agent that recovers from its own failures." Or several agents writing one cited research report.
• Memory: "How do you prevent an agent’s memory from going stale?" Or the design of ChatGPT’s cross-conversation memory.
• Safety: "How do you handle prompt injection that arrives through retrieved documents?" Or a bank chatbot that must give no financial advice and survive jailbreak attempts.

What should you ask before designing an agent?

Ask how long the task runs, whether a cheap verifier exists, which steps can't be undone, and how many tools a typical task really uses. Those four answers set the design.

• Task length. Minutes or hours? Long tasks make context management the main problem.
• A verifier. Is there a test suite, a compiler or a schema to check each step? The harness question's page notes that a loop is far stronger with one.
• Irreversible steps. Sending email, moving money, deleting records. These decide where approval gates go.
• Tools per task. If a task touches three of several hundred tools, the bank-131 page says, "this is a retrieval problem".

Should you use one agent or several?

Start with one agent and good tools, and add agents only when you can name the limit you hit. LangChain's guide to multi-agent architectures says many tasks "are best handled by a single agent with well-designed tools". Microsoft's Azure guide to agent orchestration makes the same call: "Use the lowest level of complexity that reliably meets your requirements."

When you do need more than one, pick the pattern from the task graph.

Azure describes the concurrent pattern as one that "runs multiple AI agents simultaneously on the same task". Say what that costs. Agents that each carry their own history drift apart, and re-sending the full shared context at every hop multiplies tokens. The fixes are one shared state store and passing only what changed since the last hop. In a pipeline, define a fallback at every stage so the next agent can continue on degraded input.

One red flag on the harness rubric is proposing "a multi-agent swarm before establishing a single working loop". Name the loop first: decompose, act, observe the real result, update context, decide again.

Where do guardrails go in an agent design?

Put them in three places, with the real enforcement outside the model. A system prompt telling the agent not to do something is not a control, because text an attacker writes lands in the same context window. That is indirect prompt injection.

1. Input validation, before the model reads the request: injection patterns, personal data, policy checks. It catches known attacks, not novel ones.
2. Output validation, after the model answers and before anything acts on it: schema checks, hallucinated tool calls, leaked data.
3. Execution-layer enforcement, at the tool-call boundary: an allowlist of tools per agent role, least-privilege scopes, rate limits and spend ceilings. The model can't argue with code it never sees.

Classify every tool as auto, gate or deny. Gate the irreversible ones with a blocking pause in the orchestrator that holds the action for review. On a timeout, reject. The quieter failure is scope creep: forty small permitted actions that add up to something nobody approved. Log every tool call with the context that triggered it.

Grounding is a guardrail too. On the live-web question, the heaviest criterion, 25 of 100 points, is strict grounding, and full credit needs the empty-retrieval branch: refuse, or mark model knowledge as unverified.

How should an agent handle memory and context?

Manage context per step instead of letting it pile up. Load what the current sub-task needs, drop what it doesn't, and compact finished work into short summaries. The RAG guide explains why a bigger window doesn't solve this.

Move older state, such as preferences, resolved sub-tasks and past decisions, into an external store the agent queries on demand. That only works if you tag state when you write it, so retrieval knows what to surface later. Stale memory starts as a write-time problem.

Tool definitions are context too. For bank-131, the rubric's two largest criteria, 25 points each, are making tool discovery a retrieval step and appending loaded definitions at the end of the prompt, so the cached prefix survives.

What numbers should you estimate out loud?

Put a number on the context and on the blast radius.

Tool tokens (illustrative). 300 tools at about 400 tokens per definition is 120,000 tokens before the user says anything. A search tool plus ten always-loaded tools might cost 5,000. That is the kind of win the rubric asks you to size.

Budget ceilings (illustrative). A per-session spend cap, 20 actions a minute and 100 external calls per run. A runaway loop then hits a wall and alerts someone, instead of running until a person notices.

What should you measure for an agent?

Measure whether the task finished, and whether the path to it was sound.

• Task success rate, end to end. A token saving that lowers success is not a saving.
• Tool selection accuracy on labeled requests: the right tool, with the right arguments.
• Steps, cost and latency per completed task, not per call.
• Escalation and rejection rates at each approval gate.
• Instruction-following over long sessions, sampled at checkpoints, to catch drift.

The evaluation guide covers trajectory scoring, and the cost guide covers the token math.

Which mistakes lose points in an agent round?

Most of these are red flags on FDEBench's agent rubrics. The rest are the failure modes above.

• Answering with a framework name instead of a mechanism.
• Several agents before one working loop.
• No step limit, cost limit or exit condition.
• Safety rules that live only in the prompt.
• Truncating tool schemas until they fit, or asking for a bigger context window.
• Approval gates that approve on timeout.

On the FDEBench board, Updated 2 Nov 2026, you can search roles that mention agentic AI. To practice before your loop, the free course Claude Code for Forward Deployed Engineering covers building AI agents with Claude Code.