Agentic Architecture & Orchestration

An engineering enablement team at Northbank gives its legacy-migration agent the Bash tool so it can run build and test commands inside a scratch checkout. To stop the agent running commands that write outside that checkout, an engineer writes a hook that inspects the command string and returns a blocking response when a target path lies outside the checkout, and registers it as a PostToolUse hook matching Bash. During a rehearsal the agent issues a command that writes a file outside the checkout. What will happen?

• AThe command is intercepted before the shell starts and the agent receives a denial, because a hook matching Bash is consulted ahead of execution whichever event it is registered on.
• BThe command runs and the hook cannot evaluate it, because a PostToolUse hook receives the tool name and the result rather than the arguments that were submitted.
• CThe command runs and the harness reverts it, because a hook that rejects a tool result causes the runtime to undo the work that produced that result before continuing.
• DThe command runs and writes the file, and the hook's blocking response only shapes what the agent is told afterwards, so the side effect has already taken place on disk.check_circle Correct

Why A is wrong: Tempting because the matcher genuinely does select the Bash tool and the hook logic is written as a gate. It is wrong because the event, not the matcher, decides when the hook runs, and PostToolUse runs after execution.

Why B is wrong: Tempting because it sounds like a reasonable privacy boundary between events. It is wrong because the hook does see the call details, so it evaluates the command correctly and still cannot undo the write.

Why C is wrong: Tempting because transactional rollback is a familiar guarantee elsewhere in engineering. It is wrong because the harness has no general mechanism to undo arbitrary shell side effects, and no such rollback exists.

Why D is correct: Correct because PostToolUse fires after the tool has executed, so a blocking response there can influence the agent's next step but cannot prevent an effect that has already occurred.

A coordinator Claude Code session in the CI pipeline for a payments service has already read the pull request diff, captured the output of two failing integration tests and resolved the module ownership map. It then dispatches a specialist reviewer with the Task tool, using the prompt "Assess the risk of these changes to the billing module". Logs show the subagent opening with a repository-wide Grep and eleven Read calls, adding four minutes to a job whose build-time budget is six minutes, and its written summary never mentions either failing test. The pattern repeats on most delegated reviews. Which change most effectively addresses it?

• AMove the pipeline to a model configuration with a larger context window, so the material the coordinator gathered earlier in the job remains available to the reviewer it dispatches later in the same run.
• BWrite an explicit handoff payload into the Task prompt carrying the changed file paths, the two failing test outputs, the ownership map and the review criteria, so the subagent starts with the material rather than rediscovering it.check_circle Correct
• CRestrict the subagent through allowedTools so it can call Read but not Grep, which removes the repository-wide scan and brings the delegated step back inside the remaining build-time budget.
• DHave the coordinator detect a summary that omits the failing tests and re-dispatch the same specialist prompt a second time, keeping the delegated review while raising the chance of a complete assessment.

Why A is wrong: Tempting because attention dilution over long inputs is a real problem and a larger window sounds like it would carry more history forward. It is wrong because the subagent runs with its own separate context and receives only its prompt, so window size changes nothing about what it can see.

Why B is correct: Correct because a subagent inherits nothing from the coordinator's conversation and can only work from the prompt it is given, so stating the gathered evidence in that prompt removes both the exploratory scanning and the omission of the failing tests.

Why C is wrong: Tempting because it directly attacks the measured overrun and tool restriction is a legitimate control on a delegated agent. It is wrong because the scanning is a symptom of missing information; with no diff and no test output supplied, a narrowed toolset produces a faster review that is still blind to the failures.

Why D is wrong: Tempting because retrying is cheap to implement and does sometimes recover a variable output. It is wrong because a retry cannot supply information that was never present in the subagent's input, so the second attempt starts from the same empty context and doubles the time overrun.

The same team bounds cost on the research coordinator by stopping the loop after 10 model calls per run. Over one month, 14 percent of runs end at that ceiling with the synthesis subagent never invoked. The report handed back looks finished apart from an absent citations section, so reviewers accept it, and the truncated runs surfaced only during a quarterly audit. Which change most effectively addresses this?

• ALet a run finish on stop_reason end_turn, demote the call ceiling to a runaway backstop that fails the run with an explicit incomplete signal, and state the research budget in the coordinator prompt so it narrows scope itself.check_circle Correct
• BRaise the ceiling to 40 model calls, which gives the coordinator enough turns to reach synthesis on the runs that currently stop early while still bounding the cost of the worst case at a known figure.
• CMove the coordinator onto a request with a much larger context window so that more subagent findings fit into the conversation before the loop reaches the configured call ceiling on a long research run.
• DAdd a routing classifier ahead of the coordinator that predicts how many subagent calls a question will need and sets a per-run ceiling from that prediction before the first model call is issued.

Why A is correct: Correct because it restores model-driven termination as the normal exit, keeps a bound on pathological runs, and converts a silent truncation into a visible failure that a reviewer cannot mistake for a finished report.

Why B is wrong: Tempting because it would clear most of the 14 percent immediately, but it keeps an iteration cap as the primary termination mechanism and leaves the real defect untouched: a truncated run is still delivered as though it were complete.

Why C is wrong: Tempting because long research runs do accumulate large tool results, but the ceiling counts model calls rather than tokens. A larger window does not add a single turn to a run that is stopped by call count.

Why D is wrong: Tempting because a per-question budget sounds more precise than one fixed number, but it is a trained component added before the simpler fix has been tried, and a wrong prediction reproduces the same silent truncation.

The lookup_order MCP tool used by a support resolution agent takes a single order_id argument, and its description reads, in full, that it looks up an order. Logs from one week show the agent passing the customer's email address as order_id in 12 percent of contacts. The tool returns an empty result set, the agent then tells the customer that the order system is unavailable, and it calls escalate_to_human. Which change most effectively addresses the logged behaviour?

• ARewrite the tool description to state the exact order identifier format, that the value must come from the order list returned by get_customer, and that an empty result means no matching order rather than an unavailable system.check_circle Correct
• BWrap lookup_order in a retry with exponential backoff so that a lookup returning nothing is attempted twice more before the agent draws any conclusion about the state of the underlying order system.
• CSet is_error on the tool result whenever the result set comes back empty, so that the agent is told clearly that the lookup did not produce a usable answer and can react to that condition instead of guessing.
• DAdd few-shot examples to the system prompt showing well-formed lookup_order calls with a real order identifier, alongside a worked example of the agent recovering after a lookup returns no matching rows.

Why A is correct: Correct because both halves of the failure trace back to a description that defined neither the argument nor the meaning of an empty result, and the description is the only place the agent can learn either fact.

Why B is wrong: Tempting because retries are the standard remedy for a flaky dependency and the agent's own message blames availability. It is wrong because the lookup succeeded and simply matched nothing, so repeating a well-formed query with the wrong identifier returns the same empty set.

Why C is wrong: Tempting because it does give the agent an unambiguous signal to react to. It is wrong because it labels a valid empty result as a failure, entrenching the incorrect availability story and escalating genuine no-such-order cases as outages.

Why D is wrong: Tempting because examples do teach call shape and would probably reduce the malformed calls. It is wrong because it patches around a thin tool description from the prompt, leaving every other caller of that tool with the same ambiguity.