Support Agent & Multi-Agent Research

The exam shows you 4 of 8 scenarios. Two of the highest-value ones share a hidden spine: Scenario 1 (Customer Support Agent) and Scenario 3 (Multi-Agent Research System). Both are really about the same architect-grade judgment — when a model decides, and when deterministic code must guarantee.

• Support Agent: identity preconditions, hook-enforced policy, and disciplined escalation.
• Multi-Agent Research: a hub-and-spoke coordinator that fans out, then synthesises findings with citations and coverage annotations.

This lesson walks the decisions an examiner tests on both, weighted toward Domain 1 (Orchestration, 27%) with strong pulls from Tool Design, Prompt Engineering, and Reliability.

The support agent has four tools: get_customer, lookup_order, process_refund, and escalate_to_human. The first decision the exam tests: a refund is a side effect, so it must be gated behind a verified identity.

A programmatic precondition — block process_refund until get_customer has returned a verified ID — is a deterministic guarantee. Prompt guidance ("please verify the customer first") is roughly 90% probabilistic; it will eventually let an unverified refund through. For an action with financial consequence, that gap is unacceptable.

A subtle but frequently-tested case: get_customer returns more than one match. The wrong answer picks the first row, or the highest-spending account, or guesses by recency. The right answer asks for more identifiers.

Guessing identity on an account that can issue refunds is exactly the kind of unrecoverable, high-stakes mistake the precondition was meant to prevent. When the input is ambiguous, the model's job is to disambiguate with the user — request an order number, email, or postal code — not to resolve the ambiguity on its own.

Suppose policy says refunds over $500 require a manager. A system prompt that says "never refund more than $500 without approval" is probabilistic — it holds most of the time and fails silently the rest. When failure has financial, legal, or safety consequences, you reach for a hook.

• An outgoing-call hook intercepts the action before it executes and blocks any policy-violating call.
• A PostToolUse hook intercepts a tool's result before the model sees it — useful for redaction or for injecting a verified fact.

Hooks are 100% deterministic; prompts are ~90% probabilistic. That number is the whole answer on these questions.

Here the guarantee is enforced in code that the model cannot talk its way past. Even if a clever user convinces the agent to attempt a $900 refund, the hook denies the call outright.

On the exam, any answer that enforces a hard money/legal/safety rule with prompt wording alone is a distractor. The deterministic option wins.

Escalation is where most candidates lose points. Memorise the two lists.

Good triggers (escalate):

• An explicit human request — escalate immediately, no further attempts.
• A policy gap the agent has no rule for.
• No progress after genuine attempts.
• A threshold violation (e.g. refund over the policy cap).

Bad triggers (never escalate on these):

• Sentiment analysis of the customer's tone.
• The model's own self-rated confidence ("I'm 4/10 sure").
• Untrained classifiers.

Sentiment and self-rated confidence are unreliable signals; building escalation on them is a classic anti-pattern.

An upset customer is not, by itself, an escalation trigger. The exam-correct sequence is a three-step pattern:

1. Acknowledge the emotion — briefly and genuinely.
2. Propose a concrete solution — try to actually solve the problem.
3. Escalate only if the request is reiterated — i.e. the customer explicitly asks again for a human, or the solution doesn't land.

This keeps a human in the loop for the cases that truly need one, without routing every frustrated message to a person. Note the contrast with an explicit "get me a human" — that you escalate immediately.

Now Scenario 3. A research question spanning five sources is too much for one agent — attention dilutes and the context window fills with noise. The fix is hub-and-spoke: a coordinator decomposes the question and delegates each slice to a focused specialist subagent.

The coordinator owns five jobs: decompose, delegate, aggregate, route, handle errors. Delegation is itself a tool call, so the coordinator's allowedTools must include "Task". Each specialist is an AgentDefinition (name, description, system_prompt, allowed_tools) with a least-privilege tool set.

The most-tested fact about subagents: they do not inherit the coordinator's conversation history. Each one starts clean and knows only what the coordinator writes into its Task prompt. If a constraint, date window, or prior finding matters, the coordinator must restate it explicitly — every time.

This isolation is a feature: it keeps each spoke's context focused. And because multiple Task calls emitted in one response run in parallel, the coordinator fans out across independent sources simultaneously.

• Parallel Task calls for independent sub-tasks (different sources/files).
• Sequential delegation when a later step depends on an earlier result.

One subagent failing must not abort the whole research run. The exam wants structured error propagation and graceful degradation:

• Distinguish an access failure (retryable?) from a valid empty result (no matches — a real answer).
• Recover transient faults locally inside the subagent; only escalate the non-recoverable.
• When escalating, carry partial results and structured context: failure type, attempted query, alternatives.
• Annotate coverage gaps in the final report — say what you couldn't reach, never silently suppress it.

A generic "Operation failed" blocks intelligent routing; a structured error (with errorCategory and isRetryable) enables it.

The coordinator's final job is synthesis — and on the exam, synthesis without provenance is wrong. Keep an explicit claim→source mapping for every assertion: URL, document name, the quote, and the publication date.

• When two sources conflict, annotate the discrepancy rather than arbitrarily picking one. Dates often resolve the apparent contradiction (an old figure vs a current one).
• Render by content type: tables for financials, prose for news, lists for technical findings.
• State coverage explicitly — which sub-questions were fully answered, partially answered, or unreachable.

A confident, well-formatted answer with no traceable sources is a trap; the cited, coverage-annotated answer is the architect-grade one.

A support agent confirms exactly one customer via get_customer and the customer, sounding frustrated, asks for a $750 refund. Company policy caps automated refunds at $500. Which design is exam-correct?

Across both scenarios, the same architect instincts decide the answer:

• Guarantee with code, persuade with prompts. Identity preconditions and money/legal/safety caps go in hooks and programmatic checks — never prompt wording alone.
• Escalate on objective signals (explicit request, policy gap, no progress, threshold violation). Never on sentiment, self-rated confidence, or untrained classifiers.
• Emotion pattern: acknowledge → propose a solution → escalate only if reiterated. Explicit human requests escalate immediately. Ambiguous identity → ask, don't guess.
• Hub-and-spoke: coordinator decomposes, delegates via "Task", aggregates. Subagents inherit no history — pass context explicitly. Independent slices run in parallel.
• Fail gracefully: structured errors with errorCategory/isRetryable, recover transient faults locally, carry partial results, annotate coverage gaps.
• Synthesise with provenance: claim→source mappings, conflict annotations resolved by date, render by content type.

Match the enforcement mechanism to the cost of failure, and you'll pick the right answer every time.