Agent Scenarios: Set 1

Answer: the agent isn't getting usable feedback from the tool (or doesn't recognise the result), so it repeats; add loop detection, budgets and better tool responses

1. Check the tool result: an empty or ambiguous response (e.g. 'null', a generic error) gives the model nothing new, so it tries again.
2. Return actionable results/errors ('order not found for this customer; ask for the order number').
3. Add a step budget, detect repeated identical calls, and escalate to a human when stuck.

Follow-up: How would you catch this before production? Agent evals with tool failure injection (empty, error, timeout responses).

Answer: overlapping, ambiguously described tools; clarify names and descriptions and gate destructive actions

1. 'cancel_order' and 'cancel_subscription' look similar; the description doesn't say when not to use it.
2. Rename and describe precisely (with examples of when to use each), require explicit confirmation for subscription cancellation, and validate arguments in code.
3. Add test cases for both intents to the tool-selection eval.

Follow-up: Should destructive tools be auto-executed? No: confirmation or human approval, and reversible where possible.

Answer: steps per task and tokens per step: a tool started returning huge outputs, or loops/retries increased

1. Plot steps per run and input tokens per step from traces; find when it changed.
2. Common causes: a tool now returns full raw records (e.g. entire order history), blowing up context every subsequent step; a dependency failing causing retries; lost prompt caching from a changed prefix.
3. Fix the tool output (return only needed fields), add per-task token/cost budgets and alerts.

Follow-up: Why does one big tool result cost so much? It stays in context and is re-read on every following step.

Answer: untrusted text influenced a high-impact action with no code-enforced limit or approval

1. The email was treated as instructions; nothing outside the model checked the decision.
2. Enforce limits server-side (per-ticket and per-customer caps), require human approval above thresholds or for multiple refunds, and scope refunds to the specific complaint.
3. Mark customer content as untrusted in prompts, log the triggering input for every tool call, and add this attack to the red-team/eval set.

Follow-up: Would a better system prompt have prevented it? It might reduce it, but only code-level limits and approvals guarantee the money can't move.

Answer: the allergy fell out of the context window (or was lost in summarisation); store critical facts in memory and check them in code

1. Check the context at the reorder step: the early turn was trimmed or the summary dropped it.
2. Persist critical facts (allergies, preferences) to a long-term memory/profile and retrieve them for relevant actions.
3. For safety-critical constraints, check in code: the reorder tool compares items against the profile's allergens and blocks or warns.

Follow-up: Why not rely on bigger context windows? Cost grows, recall in long contexts is imperfect, and safety shouldn't depend on the model noticing.

Answer: the eval set doesn't match production: phrasing, multi-issue tickets, tool behaviour and policy edge cases differ

1. Compare distributions: real tickets are messier (several issues, missing order IDs, other languages), and real tools are slower, flakier or return different data than sandbox copies.
2. Sample failed production cases, categorise them, and add them to the eval set; simulate tool failures and latency in the sandbox.
3. Measure pass^k (consistency) rather than single runs, and track online metrics per category.

Follow-up: How do you keep the eval set representative? Continuously sample recent production tickets (with consent/redaction) and refresh the set.

Answer: improve delegation and synthesis, give sub-agents clearer non-overlapping briefs, and check whether parallelism is needed at all

1. Contradictions come from overlapping briefs and sub-agents working with partial context; the orchestrator merges without reconciling.
2. Write distinct, scoped briefs with output formats and sources; have the orchestrator check conflicts and resolve or flag them with citations.
3. Measure quality and cost per report against a single-agent baseline; reduce sub-agents for narrow questions (scale effort to the query).

Follow-up: When is multi-agent worth its tokens? For broad, parallel, read-heavy questions where breadth matters more than cost.