Agents And Tool Use hard
A `query_logs` tool can return up to 200,000 tokens. The team truncates its output to the first 4,000 tokens. The agent now reports 'no errors found' for incidents whose errors appear late in the log window. What is the best fix?
- A Shape the tool to filter and aggregate server-side, returning bounded results with counts, a cursor, and an explicit truncation flag.
- B Raise the truncation limit to the full 200,000 tokens, since the model's context window can hold the complete log output.
- C Switch from head to tail truncation, because in most incidents the relevant errors cluster near the end of the log window.
- D Summarize the full output with a separate model call before returning it, so the agent gets complete coverage of the logs in far fewer tokens.
Answer: A. Shape the tool to filter and aggregate server-side, returning bounded results with counts, a cursor, and an explicit truncation flag.
Silent truncation turns 'not shown' into 'not present'. The fix is a tool that returns **bounded, query-shaped results** and says when more exists. This costs extra calls to refine or page, but accuracy improves and cost stays stable. Raising the limit makes every later step resend that output, and summarization suits prose documents but can drop the one error line that matters while still hiding what was omitted.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- You are defining a 'schedule_meeting' tool for an agent. Which schema decision most reduces wrong or malformed calls?
- A model emits three parallel tool calls: `get_inventory`, `get_price`, and `get_shipping`. To cut latency, the host appends each result to the transcript as it arrives and immediately re-invokes the model. Runs start failing with malformed-request errors, and some produce hallucinated shipping costs. What should the host do?
- A team splits a coding agent into planner, coder, tester, and reviewer agents, and each receives the full transcript of the previous agent. The expected quality gains did not appear. Cost tripled, and the reviewer often fixates on approaches that earlier agents abandoned. When is a multi-agent split actually justified?
- A support agent should remember each customer's preferences across months of sessions. The team appends every past session summary to the system prompt. After six months, prompts exceed 80,000 tokens, latency has doubled, and the agent sometimes ships to an address the customer replaced weeks ago. What redesign fixes both problems?
- A teammate proposes splitting a single coding agent into five agents, arguing that more agents means smarter results. When is a multi-agent split actually justified?
- A data-analysis agent runs model-generated Python inside the same container as your API service. That container has database admin credentials in environment variables. A security review flags this as critical. What is the best mitigation?