Core to Deep Dive
Prepare for questions on tool schemas, validation, routing, retries, result normalization, and reliable execution.
Depth
Showing 4 of 4 questions
Short answer
A good schema has one clear purpose, an unambiguous name and description, typed fields, meaningful constraints, explicit required values, and examples only where they reduce ambiguity. It should be easy for both the model and the executor to validate.
Interview-ready answer
I design tool schemas like stable public APIs. Inputs should avoid overlapping semantics, use enums and bounds where possible, distinguish optional fields from nullable values, and describe units and side effects. Smaller task-focused tools are usually easier to select than one broad tool with many modes, but too many near-duplicates can confuse routing, so the catalog also needs coherent naming and descriptions.
Common mistakes
Short answer
Validate arguments against a strict schema, normalize types, enforce semantic constraints and authorization, then validate the returned result against a stable output contract. Treat validation failures as typed observations, not executable instructions.
Interview-ready answer
I use multiple layers: structural schema validation, domain checks such as ranges and resource existence, permission checks tied to the authenticated actor, and policy checks for high-impact actions. Outputs receive the same discipline because external tools can be buggy or compromised. The agent gets a sanitized typed error it can reason about, while logs retain diagnostic detail without leaking secrets.
Common mistakes
Short answer
Classify the failure before acting: retry transient errors with bounded exponential backoff and jitter, repair invalid arguments, choose a fallback for unavailable capabilities, and stop on permanent or unauthorized failures. Every retry must respect idempotency and the overall budget.
Interview-ready answer
I first distinguish timeout, rate limit, dependency outage, invalid input, authentication, and policy failure. Only transient and idempotent operations receive automatic retries, using exponential backoff, jitter, per-call timeouts, and a run-level deadline. For side-effecting tools I use idempotency keys or require confirmation. The final trace should show attempts and the terminal classification so operators can separate tool instability from agent-planning errors.
Common mistakes
Short answer
Reduce overlap, improve names and descriptions, retrieve a small relevant tool subset, use routing examples, and evaluate confusion pairs. Hierarchical routing can select a domain first and a specific tool second without exposing the entire catalog.
Interview-ready answer
I start by fixing the catalog because routing cannot compensate for indistinguishable APIs. Then I use metadata retrieval or a deterministic capability router to present only likely tools, with examples for common confusion pairs. For high-risk actions, selection and execution are separate decisions: the model can propose a tool, while policy and authorization layers approve it. I measure top-k tool recall, wrong-tool rate, argument validity, latency, and behavior as the catalog changes.
Common mistakes