Lesson 30 / 31

Case Study: A Refund Assistant Across Teams

Design an assistant that uses MCP tools and delegates to another team's agent.

The design

Goal: support staff ask the assistant to handle refund requests. Front-door agent (support team): an MCP host with three servers, all vetted, pinned and sandboxed: orders-mcp (read-only get_order_status), docs-mcp (policies as resources) and ticketing-mcp (create note). Tool definitions are snapshot-tested. Delegation: for refund calculation it sends an A2A task to the Billing agent (owned by finance), found in the registry via its Agent Card (skill propose-refund), passing only the invoice id and reason. The billing agent may answer input-required ("which line is damaged?"), which the front door relays to the staff member. Policy (in host code): allow-listed tools, amount range check, human approval before anything is paid, tokens scoped and short-lived with the end user's identity delegated, never forwarded. Safety: all tool and agent outputs wrapped as data and scanned; no tool combines private data, untrusted content and outbound send. Quality: contract tests for servers, a stub Billing agent for routing and state tests, a 100-case evaluation (outcome, trajectory, safety), a trace id across hops, redacted audit logs, alerts on cost and approval backlog.

Connected, governed, safe

Standard protocols, strict policy and good tests turn many agents and tools into one dependable system.

Four habits: standardise, constrain, test, observe.
Figure 8.1 — Standardise, constrain, test and observe.

The design on one page

Each line maps to a section of this course.

Tools      orders-mcp (read-only), docs-mcp (resources), ticketing-mcp; vetted, pinned, sandboxed  (Sec 3, 5)
Delegate   A2A task to Billing agent found via registry + Agent Card skill "propose-refund"          (Sec 6)
Dialogue   input-required relayed to the staff member; terminal states final                         (Sec 6)
Policy     allow-list + amount range + human approval before payment; scoped short-lived tokens      (Sec 4, 5)
Safety     tool/agent output = untrusted data; no private+untrusted+outbound combination             (Sec 5)
Quality    contract tests, stub remote agent, 100-case eval, trace id, redacted audit logs            (Sec 3, 7)
Change     pinned SDK/protocol versions, adapter layer, deprecation policy                            (Sec 7)

Quick check: Why does the front door pass the Billing agent only the invoice id and reason?

  • To avoid using tasks
  • IDs are faster to type
  • A2A forbids other fields
  • The remote agent is outside the trust boundary and should get minimum data
Answer

The remote agent is outside the trust boundary and should get minimum data — Data minimisation limits exposure if the remote side is compromised or misbehaves.