Exercise 5: Delegating to Agents

Overview

Five artifacts for Lintel, about 2.5 hours. This is the exercise a compliance owner would actually read, because four of the five artifacts are about what the system is not allowed to do.

Keep Exercise 2’s NFR budget and Exercise 4’s stack selection to hand. Several of the numbers here are derived from them rather than chosen.

How to work

In order. The action boundary depends on the agent design; the observability plan depends on everything above it.

Agent design — ~30 min
Tool and action boundary — ~40 min
MCP-based tool integration design — ~20 min
Human handoff protocol — ~30 min
Observability plan — ~30 min
Self-check — six pass/fail items

Artifact 1 — Agent design

One to two pages.

Position on the autonomy spectrum, per path. The retrieval path and the action path do not sit at the same point, and saying so is most of the argument.
The five-line pipeline version of the action path, followed by what it cannot do. This is how the rubric’s “simpler alternative genuinely considered” is satisfied — if you cannot name a capability gap, build the pipeline.
The four criteria — complexity, value, viability, cost of error — assessed honestly, including the one that fails as stated and what you engineer to satisfy it.
The pattern, justified by task shape and by where oversight must attach, not by sophistication.
Multi-agent: justified or explicitly rejected, with the reliability arithmetic for your own numbers.
What must survive exactly, and therefore lives outside the model’s context.

Artifact 2 — Tool and action boundary

One table plus half a page. The artifact most likely to be read by someone with blocking authority.

For every tool:

Read-only or consequential, and whether it is safe to run in parallel.
Promotion reason — gate, invariant, render, or parallelise. A tool with no promotion reason probably should not be its own tool.
Blast-radius tier: act alone · act then notify · ask first · forbidden.
Enforcement point — where in your code the limit, scope or confirmation is actually applied.
Credential scope — the narrowest authority that lets the tool work.
Idempotency key composition, for anything with an effect.

Then the four bounds with their derivations — step cap, task budget, wall-clock timeout, spend cap — and the exhaustion path for each.

Name the tool that must not exist, and why. Every system of this shape has one.

Artifact 3 — MCP-based tool integration design

Half a page plus a diagram.

What the seam carries: discovery, schemas, versioning, instrumentation.
What stays behind it: every enforcement point from Artifact 2, listed explicitly.
Whether the seam is justified yet — more than one consumer, or more than a couple of providers. If not, say what you would build instead and when you would revisit.
Third-party servers: which, if any, and the review process for tool definitions arriving from a server you do not control.

The test: a reviewer asking “what stops this exceeding the credit limit?” must be pointed at code, not at a protocol.

Artifact 4 — Human handoff protocol

One page, written for the people who receive the handoffs.

Lead with the package contents — conversation, sources with versions, conclusion and confidence, actions taken with outcomes, what it was about to do, and the handoff reason. Triggers go at the end, as a list.

Then:

Hand-back, and what the system accepts as authoritative from a person.
Resolution capture as evaluation data.
Volume arithmetic — confirmations plus handoffs, against the team’s real capacity across its time zones. If it does not fit, say what changes.
The owner, and how you would review the format with them before building it.

Artifact 5 — Observability plan

One page. Write it against a single test: a credit was issued last Tuesday that should not have been. Explain it.

Trace contents — inputs with provenance and versions, every tool call with exact arguments and results, the plan and revisions, the tier decision and who confirmed, the terminating bound, per-step cost, model and config version.
What you deliberately do not rely on: the model’s internal reasoning, for both reasons given in the topic.
Sampling policy — full on the action path, sampled elsewhere, with the justification.
Retention, set by the audit cycle, and the trace store’s place in the erasure path.
Cost attribution per interaction, and per tier if you cascade.

Self-check

Pass or fail.

The agent-vs-pipeline decision is argued, with the simpler alternative genuinely considered. The five-line pipeline appears, with its capability gap named.
Every action the agent can take is classified by required oversight, with reasoning tied to blast radius. Including a forbidden tier that is absent rather than gated.
Loop termination and cost bounds are specified numerically. Four bounds, each with a derivation, plus the exhaustion path.
The handoff protocol addresses what the human receives, not just when the handoff triggers. Package contents lead the document.
The observability plan would let you reconstruct a specific bad decision after the fact. Test it against the Tuesday credit.
Multi-agent is either justified against coordination cost or explicitly rejected. With arithmetic, not preference.

If something failed

If your bounds have no derivations, they are guesses with decimal points. Two of the four come straight from Exercise 2 — the timeout from the latency budget, the task budget from the cost ceiling — so go and fetch them rather than inventing new ones.

If every tool has the same credential scope, you have granted uniform authority for convenience. Narrow the read-only tools first; it is the cheapest correction in the artifact.

If the handoff protocol is a list of triggers, you have written the part that was easy. The package is the deliverable, and the test is whether a support agent could act on it without asking the customer anything.

If multi-agent was neither justified nor rejected, run the multiplication. It takes one line and usually settles the question against a requirement someone already owns.

→ The agent is bounded. Next, whether it survives production — cost, safety and evaluation. — Exercise 6, after reading Handbook Module 6.