Clear
Your agent's responses are good, but they arrive as one big block after a long wait, and users think it's broken.
How would you design the system to improve perceived responsiveness?
General Medium

Answer:

  1. Stream tokens: Deliver output incrementally, so users see progress immediately.

  2. Cut time-to-first-token: Trim the prompt and use caching, so the first token comes fast.

  3. Show status during work: Indicate tool calls and processing, so silence isn't mistaken for failure.

  4. Return partial results: Deliver what's ready while more computes, so users get value sooner.

  5. Acknowledge immediately: Confirm receipt fast, so users know the request is being handled.

Your agent's tool definitions have grown to fifty, and the model now frequently picks the wrong tool or gets confused.
How would you design the system to keep tool selection accurate as the toolset grows?
General Medium

Answer:

  1. Retrieve relevant tools: Surface only applicable tools per query, so the model chooses from a small set.

  2. Write precise descriptions: Give clear, distinct tool specs, so selection is unambiguous.

  3. Group tools by domain: Namespace or cluster them, so the model navigates fewer at once.

  4. Provide selection examples: Show correct choices for representative tasks, so the model learns the mapping.

  5. Validate the choice: Check the selected tool fits the task, so wrong picks are caught.

Your agent works, but a user reported it gave them someone else's data, and you can't reproduce or explain how.
How would you design the system to prevent and diagnose cross-user data leakage?
General Medium

Answer:

  1. Scope all data by user: Namespace retrieval, memory, and cache per user, so cross-user access is structurally impossible.

  2. Enforce at the data layer: Apply access control at the source, so filtering doesn't depend on the model.

  3. Never share caches across users: Key caches by user, so one user's data can't surface for another.

  4. Log data access per request: Record what data each request touched, so leaks are diagnosable.

  5. Audit for isolation: Test that users can't access each other's data, so leaks are caught before production.

Your agent handles a task that needs several LLM calls, and doing them one after another makes the response unacceptably slow.
How would you design the system to reduce latency from sequential LLM calls?
General Medium

Answer:

  1. Parallelize independent calls: Run non-dependent calls concurrently, so latency is the slowest, not the sum.

  2. Combine calls: Merge multiple reasoning steps into one prompt where possible, so you make fewer calls.

  3. Use faster models for simple steps: Route lightweight steps to small models, so they don't add much latency.

  4. Cache repeated calls: Reuse results for identical sub-calls, so you skip redundant work.

  5. Stream the final step: Stream the last call's output, so users see progress sooner.

Your agent's answers are correct, but a downstream compliance system flags them because they lack required source attribution.
How would you design the system to guarantee source attribution on every answer?
General Medium

Answer:

  1. Track sources through the pipeline: Carry provenance from retrieval to answer, so attribution is available.

  2. Require citations: Force the model to attribute claims to sources, so answers are cited.

  3. Validate attribution presence: Check every answer has required citations, so uncited ones are caught.

  4. Enforce post-generation: Add attribution structurally if missing, so it's never absent.

  5. Verify citation accuracy: Confirm cited sources actually support the claims, so attribution is correct.

Your agent's LLM provider raised prices, and you need to cut costs without a noticeable quality drop.
How would you design the process to reduce cost while preserving quality?
General Medium

Answer:

  1. Route by difficulty: Send easy requests to cheaper models, so you spend big-model budget only where needed.

  2. Trim prompt tokens: Cut redundant context and use caching, so per-call cost drops.

  3. Cap output length: Limit generation to what's needed, so you don't pay for verbosity.

  4. Cache aggressively: Reuse results for repeated queries, so you avoid redundant calls.

  5. Measure quality per change: Validate each cost cut against evals, so quality doesn't silently drop.

Your agent needs to call an external API that's frequently slow, and its latency makes the whole agent feel unresponsive.
How would you design the system to stay responsive despite a slow external dependency?
General Medium

Answer:

  1. Set tight timeouts: Bound the slow API, so it can't stall the agent indefinitely.

  2. Cache its responses: Reuse recent results, so you avoid the slow call when possible.

  3. Call it in parallel: Overlap the slow call with other work, so its latency is hidden.

  4. Prefetch when predictable: Start the call early, so results are ready when needed.

  5. Degrade gracefully: Proceed without it when it's too slow, so responsiveness holds.

Your agent's multi-step workflows fail silently — a step returns a plausible but wrong result and the workflow continues to a bad conclusion.
How would you design the system to catch bad intermediate results before they propagate?
General Medium

Answer:

  1. Validate each step's output: Check intermediate results before passing them on, so errors are caught early.

  2. Add sanity checks: Verify results fall in expected bounds, so implausible ones are flagged.

  3. Verify against the goal: Confirm each step still serves the objective, so drift is caught.

  4. Gate on confidence: Halt when a step is low-confidence, so uncertain results don't propagate.

  5. Trace intermediate values: Log each step's output, so failures are diagnosable after the fact.

Your agent uses an LLM to extract structured data, but it occasionally hallucinates field values that weren't in the source.
How would you design the system to prevent hallucinated values in structured extraction?
General Medium

Answer:

  1. Ground extraction in source: Require values come from the provided text, so nothing is invented.

  2. Verify against source: Check each extracted value appears in the input, so hallucinations are caught.

  3. Allow null over invention: Let fields be empty when absent, so the model doesn't fabricate to fill them.

  4. Cite source spans: Have the model point to where each value came from, so extraction is verifiable.

  5. Score confidence per field: Flag low-confidence extractions for review, so uncertain values are checked.

Your agent works well, but you have no way to catch when a specific type of request slowly starts failing more often over weeks.
How would you design monitoring to catch slow, category-specific degradation?
General Medium

Answer:

  1. Segment metrics by request type: Track quality per category, so category-specific decline is visible.

  2. Baseline per category: Know normal performance for each type, so drift stands out.

  3. Track trends over time: Watch metrics longitudinally, so slow degradation surfaces before it's severe.

  4. Alert on category drift: Flag when a specific category declines, so you catch it early.

  5. Diagnose per category: Investigate the failing type specifically, so fixes are targeted.

Your agent retrieves from a vector DB, but as the index grew to tens of millions of vectors, query latency became unacceptable.
How would you design retrieval to stay fast at very large scale?
General Medium

Answer:

  1. Use approximate search: Apply ANN indexes like HNSW, so search stays fast without exact scans.

  2. Partition the index: Shard by metadata or namespace, so queries search a smaller space.

  3. Filter before searching: Narrow with metadata first, so vector search runs on fewer candidates.

  4. Tune the index: Balance recall against speed in ANN parameters, so latency meets your target.

  5. Cache frequent queries: Serve hot queries from cache, so common requests skip the search.

Your agent's answers vary between runs on the same input, which is fine for chat but breaks a downstream system that expects stability.
How would you design the system to provide stable outputs where downstream systems need them?
General Medium

Answer:

  1. Lower temperature: Reduce sampling randomness for stability-critical paths, so outputs are consistent.

  2. Cache canonical answers: Serve a fixed answer for repeated inputs, so downstream sees stability.

  3. Constrain output structure: Enforce a schema so the shape is always stable, so parsing doesn't break.

  4. Pin the model version: Use a fixed model, so provider updates don't shift behavior.

  5. Validate against a contract: Check output meets the downstream contract, so instability is caught before it propagates.

Your agent's cost is fine per request, but batch jobs of millions of requests are prohibitively expensive at standard API rates.
How would you design the system to process large batches cost-effectively?
General Medium

Answer:

  1. Use batch APIs: Exploit provider batch pricing for non-urgent volume, so per-request cost drops sharply.

  2. Deduplicate inputs: Skip identical requests, so you don't pay for redundant work.

  3. Route to cheaper models: Use the smallest model meeting quality for batch work, so cost falls.

  4. Cache across the batch: Reuse results for similar inputs, so repeated work is avoided.

  5. Self-host for steady volume: Run open models when batch volume justifies the infrastructure, so you avoid per-token API cost.

Your agent's tool results feed back into the LLM, but a large tool response blows past the context window and truncates important instructions.
How would you design the system to handle large tool outputs?
General Medium

Answer:

  1. Summarize large outputs: Condense big tool results before feeding them back, so they fit the window.

  2. Truncate intelligently: Keep the relevant parts of large outputs, so important content survives.

  3. Store and reference: Save the full output and pass a reference, so the model retrieves detail on demand.

  4. Paginate results: Return tool output in chunks, so the model processes it in pieces.

  5. Cap output size: Limit what tools return, so responses stay manageable.

Your agent handles a high volume of requests, but a few malformed ones throw unhandled exceptions that crash the worker and drop other in-flight requests.
How would you design the system to isolate failures so one bad request can't take down others?
General Medium

Answer:

  1. Isolate request handling: Process each request independently, so one failure doesn't affect others.

  2. Catch exceptions per request: Wrap handling so errors are contained, so a crash doesn't propagate.

  3. Validate inputs early: Reject malformed requests before they cause exceptions, so bad input fails cleanly.

  4. Use bulkheads: Limit the blast radius of failures, so one bad request can't exhaust shared resources.

  5. Fail the request, not the worker: Return an error for the bad one and keep serving others, so availability holds.

Your agent's quality dropped after you switched embedding models, even though the new model benchmarks higher.
How would you design the process to diagnose why a better-benchmarking model hurt your retrieval?
General Medium

Answer:

  1. Test on your own data: Evaluate the model on your queries, not public benchmarks, so domain fit is measured.

  2. Check version consistency: Ensure documents and queries use the same model, so mismatches aren't the cause.

  3. Re-tune parameters: Recalibrate thresholds and top-k for the new model, so old settings don't hurt.

  4. Compare retrieval directly: Diff what each model retrieves on the same queries, so the difference is visible.

  5. Verify the migration: Confirm re-embedding completed correctly, so partial migration isn't the issue.

Your agent calls multiple tools, but a failure in tool three leaves the effects of tools one and two applied, creating an inconsistent state.
How would you design the system to keep multi-tool operations consistent under partial failure?
General Medium

Answer:

  1. Use the saga pattern: Pair each action with a compensating undo, so failures can be rolled back.

  2. Order for reversibility: Do reversible steps first and irreversible last, so failures are recoverable.

  3. Make tools idempotent: Ensure retries don't duplicate effects, so recovery is safe.

  4. Checkpoint between steps: Save state so you can resume or roll back, so partial failure is handled.

  5. Confirm irreversible steps: Gate permanent actions until prerequisites succeed, so you don't commit prematurely.

Your agent maintains conversation history, but long sessions blow past the context window and truncating the oldest messages loses critical early context.
How would you design the system to manage conversation history within the context window?
General Medium

Answer:

  1. Summarize old turns: Compress earlier history into a running summary, so key facts survive truncation.

  2. Pin critical context: Keep essential early information in-window, so it isn't dropped.

  3. Retrieve relevant history: Pull past turns on demand rather than keeping all, so the window stays lean.

  4. Prioritize by relevance: Keep the most relevant history, not just the most recent, so importance drives retention.

  5. Track a token budget: Bound history size explicitly, so the window never overflows.

Your agent uses an LLM to route requests to specialized handlers, but the router itself is now a latency and cost bottleneck on every request.
How would you design the system to make routing cheap and fast?
General Medium

Answer:

  1. Use a small model for routing: Route with a lightweight classifier, so you don't spend a big model on every request.

  2. Try rules first: Handle clear-cut routing with deterministic rules, so most requests skip the LLM entirely.

  3. Cache routing decisions: Reuse routes for similar requests, so repeated routing is free.

  4. Route on embeddings: Classify by vector similarity, so routing avoids generation cost.

  5. Skip routing when obvious: Bypass the router for unambiguous requests, so it only runs when needed.

Your agent's answers are grounded in retrieval, but you can't tell whether a wrong answer means the fact wasn't retrieved or was retrieved but ignored.
How would you design the system to separate retrieval failures from generation failures?
General Medium

Answer:

  1. Log retrieved context: Capture exactly what was retrieved per query, so you can check if the fact was there.

  2. Check for the needed fact: Verify whether retrieval contained the answer, so you know which stage failed.

  3. Test generation with gold context: Feed perfect context and check the answer, so you isolate generation quality.

  4. Measure each stage separately: Score retrieval and generation independently, so failures are attributable.

  5. Categorize failures: Label each as retrieval or generation, so patterns guide where to fix.