Tool Calling & Agents
Design validated tools, bounded loops, and safe side effects.
Trace a tool call from request to answer, validate arguments before anything runs, and keep side effects idempotent when an agent retries.
5 questions
Questions
Easy
1.5 h
Follow one ticket lookup from tool declaration to answer: what the model proposes, what the application validates and executes, and what the assistant says when the result is unavailable.
Medium
3 h
Implement a get_ticket adapter that validates model-proposed arguments, takes tenant scope from trusted context, and passes a fixture table, then explain how a bounded orchestrator handles timeouts, invalid calls, and parallel lookups.
4 h
Extend the validated ticket adapter with a paginated search_tickets tool behind a tool registry under a 3-hour cap, hand in tests and a README, then review a sample submission as the interviewer would.
3 h
Compare a fixed workflow and an agent loop for a parcel-delivery assistant's rescheduling and stuck-parcel tasks using a pilot's success, cost, and latency figures, then recommend a design per task and say what would change it.
Hard
4 h
Design an agent that closes a ticket and sends one approved closure email safely across duplicate jobs, crashes, timeouts, and concurrent workers, and say exactly what the design can and cannot guarantee.
What you will be able to do
- Explain how a tool declaration, a proposed call, its execution, and the returned result fit together
- Say which component proposes, which validates, and which executes a tool call
- Keep identity, tenant scope, and permissions in trusted application context instead of model arguments
- Treat tool results, including user-authored text, as data rather than instructions
- Choose between a predefined workflow and a bounded agent loop for a concrete task
- Define stopping conditions and failure behavior that the application enforces
- Validate a model-proposed call at runtime: allowlisted tool name, exact argument shape, and value format
- Derive tenant scope and permissions from trusted context so the model cannot widen access
- Return a stable result envelope with controlled error codes and a copy of only the needed fields
Hands-on exercises
Interview rounds that use this topic
Topic boundaries
This topic covers workflows versus agents, typed tools, approval boundaries, state, and termination. Specific frameworks and protocols appear as tags.
Related on CodeSnatch
System Design
Shows how to scope every query to the session's tenant and test isolation, the rule each tool executor enforces.
System Design
Compares two-phase commit with sagas and compensating actions, and shows idempotency keys that make retried writes safe.
System Design
Explains at-least-once delivery and idempotent consumers, the reason an agent's queued job can run twice.
System Design
A worked sender with retries by failure type and an idempotency window, close to an agent that sends email.
System Design
Shows idempotent requests and reconciliation with an outside provider whose response can be lost.
System Design
Teaches timeouts, backoff with jitter, and circuit breakers for tool calls to slow or failing services.
AI Engineering
Applies the same argument validation to tools served over MCP, with each error returned in the right channel.
AI Engineering
Traces an instruction planted in retrieved content and names the controls in trusted code that hold even if the model obeys.
Community article
A practitioner's list of idempotency key bugs, from concurrent retries to lost responses and keys that expire too soon.