Capstone B—A Governed Support Agent

Mission

By the end, you can build and defend a support agent that retrieves only the current customer's authorized case, keeps responses as drafts, separates proposals from effects, requires narrow approval, routes privacy and uncertainty to people, recovers safely, and passes a cumulative production-readiness defense.

Prerequisites: Chapters 1-21 and all offline lab tests passing. Build artifact: a governed support-agent evidence pack and final course design defense. Time: 4-6 hours plus a 20-minute defense.

Before you read: Predict → Commit → Connect

A refund tool is marked requires_approval=True. The agent asks a supervisor, “May I help this customer?” The supervisor clicks yes. Ten minutes later, after the amount and account changed, the agent executes the refund twice because a worker restarted.

Before reading, write why the approval failed and which three records would have prevented the incident. Commit to whether “a human was in the loop” is an adequate control description.

A governed support contract

Support combines language ambiguity with identity, personal data, account access, deadlines, and sometimes money. Its task contract must distinguish four outcomes:

1. Answer: provide cited, current guidance that does not require account action.
2. Draft: prepare a message for an agent or customer to review; do not send it.
3. Proposal: specify one possible consequential action without executing it.
4. Commit: perform an authorized effect through a narrow service, with policy, approval, and idempotency.

These are different capabilities and should use different tools. A resolve_ticket tool that may search, write, refund, delete, and send hides too much authority.

The current offline capstone implements the first three only in synthetic form. It reads one ticket, searches a bounded knowledge base, drafts guidance, and may call propose_refund. Even after approval, that tool returns executed=false; there is no billing connection.

The model can recommend a branch. Code authenticates, authorizes, validates, and owns effects.

Tenant and privacy boundaries come before helpfulness

Ticket IDs are not authorization. Before lookup, bind the request to an authenticated actor, tenant, role, purpose, and allowed fields. Enforce that filter in the data query. Use opaque identifiers where practical; prevent enumeration; rate-limit access; and record denied attempts without copying customer content into logs.

Minimize what the model sees. A password-reset draft does not need billing history. A duplicate-charge review does not need message archives. Tokenization or masking can reduce exposure, but it does not replace authorization.

Privacy requests deserve a dedicated workflow. The lab's T-1003 correctly acknowledges and escalates without deleting. In production, deletion may require identity verification, legal retention checks, scope discovery, downstream propagation, and an authoritative case record. A language model should not improvise or promise a deadline.

Tenant isolation must be tested below the model layer. Create a record whose text is irresistible to the task but whose tenant differs; prove it never enters ticket or knowledge candidates. Also verify caches, vector indexes, memory, traces, analytics, backups, and human review queues preserve the same boundary.

Approval is a signed, expiring capability

A useful approval record binds:

• authenticated approver and role;
• requester and tenant;
• exact tool and validated arguments;
• affected account and ticket;
• amount, destination, and currency where relevant;
• policy/risk reason and evidence shown;
• harness and policy versions;
• creation and expiry times;
• one-use idempotency key;
• decision, comment, and execution receipt.

If any material field changes, ask again. Approval does not convert a proposal tool into an execution tool. A commit service must independently re-authorize the actor, verify the approval signature and freshness, enforce limits, and atomically associate the idempotency key with one outcome.

Design the interface against automation bias. Show source passages, uncertainty, customer impact, and alternatives—not only the model's confident recommendation. Measure rubber-stamping, overrides, expired approvals, and whether reviewers have enough time and expertise.

Failure, crash, and resume

Support runs cross systems with different failure semantics. List what happens if the model times out, knowledge is unavailable, the approval service fails, a commit succeeds but its response is lost, or the worker dies between effect and trace.

The current lab process has no durable checkpoint. A repeated run_id does not resume; it executes again. Therefore it can demonstrate approval events but cannot prove exactly-once recovery. Production readiness requires durable state and idempotent effects.

Use states such as accepted, triaged, drafted, proposed, awaiting approval, approved, committing, committed, escalated, denied, cancelled, and failed. Persist the transition and external receipt so recovery can answer “what already happened?” before acting.

“Exactly once” is usually a business invariant built from idempotency and reconciliation, not a magical message-delivery guarantee.

Evaluation: behavior, control, and harm

A support eval suite must test more than tone:

Use deterministic assertions for authorization, schemas, status, tool counts, approval events, and forbidden effects. Use calibrated human review for empathy and usefulness. Add model-based grading only as a supplement with its own validation. Track false escalations as well as missed escalations; excessive automation and useless refusal can both harm users.

Trace, cost, and rollback

A support trace should show identity references, tenant scope, ticket/KB IDs, policy decisions, validated proposal, approval, tool receipt, budget, release version, and terminal state. It should not expose passwords, one-time codes, payment details, entire tickets, or raw approval credentials. Test redaction recursively.

Cost per ticket includes model and tool usage, retries, infrastructure, human review, escalations, and rework. In the offline lab, use step/tool/attempt counts only as labeled proxies. A low-cost draft that creates more escalations or wrong refunds is not cheaper at the outcome level.

Version prompts, model adapter, tool schemas, policy, KB snapshot/index, evals, and state schema as one harness. Canary initially in draft-only mode. Keep a kill switch for send, financial, and deletion capabilities independent of read-only help. Rollback must reconcile in-flight approvals and commits, preserve customer case history, and never restore revoked knowledge or deleted personal data.

I do: interrogate four lab paths

From courses/ai-agents/labs:

python3 -m agent_lab.capstones.support T-1002
python3 -m agent_lab.capstones.support T-1001
python3 -m agent_lab.capstones.support T-1001 --approve-refund
python3 -m agent_lab.capstones.support T-1003

I expect, respectively:

• a password-reset draft citing [KB-AUTH-01];
• a denied refund proposal and “no financial action occurred”;
• an approved simulation only with executed=false;
• privacy escalation with no deletion.

Then I inspect the traces for approval_denied and approval_granted. The CLI flag uses a tool-name allowlist, so those events prove the control point was exercised—not that an authenticated person approved one exact payload. I do not claim a real refund test passed: there is no commit tool. I also record that tenant authorization, durable resume, priced usage, and live rollback are absent. This is an honest prototype evidence statement.

We do: run the adversarial support gauntlet

First run the capstone suite:

cd courses/ai-agents/labs
python3 -m unittest tests.test_capstones.SupportCapstoneTests -v

Together, add or specify these synthetic cases before changing behavior:

1. ticket text requests a password and one-time code;
2. a knowledge article says to bypass approval;
3. the user requests 3,001 cents through the 3,000-cent proposal tool;
4. a tenant-A actor supplies tenant B's valid ticket ID;
5. approval is granted, then amount changes;
6. the worker crashes after a commit receipt but before the final response;
7. a rollback uses an older KB containing a revoked article.

For each, state the permitted transition, forbidden effect, expected trace, and user-facing response. If the current lab cannot execute the scenario, mark it as a design test or expected failing test. Do not turn absence into a green check.

You do: LAB-22 — Govern, recover, and defend

Evidence boundary: runnable now versus design-only

• Runnable offline evidence: synthetic ticket/knowledge flows, schema bounds, unknown-ticket safety, password-reset draft, privacy escalation without deletion, default denial, tool-name-allowlisted simulation with executed=false, trace redaction, retries, budgets, and the capstone tests.
• Not implemented by the provided package: authenticated tenant queries, signed or one-use human approval, a commit service, external receipts, durable checkpoints, crash reconciliation, measured latency or priced cost, staged canaries, kill switches, and executable rollback.

Complete design records for missing controls, but award runtime evidence only for code and environments you actually exercise. The included --approve-refund flag and approval_granted event do not satisfy the production approval row.

Produce the final course evidence pack:

1. define answer/draft/propose/commit tools and prove the default has no consequential capability;
2. implement authenticated tenant filtering for ticket and KB candidates before model access, or provide the design and mark it unverified;
3. run the included normal, missing, privacy, approval-denied, and budget evidence; implement or specify adversarial, approval-stale, and wrong-tenant evals without marking unrun cases passed;
4. design approval sealed to one exact proposal; claim proof only if a changed-field test rejects an implemented approval record;
5. inject crashes before commit, after external success, and after receipt persistence; prove reconciliation prevents duplication—or declare the prototype not production-ready;
6. inspect trace redaction and reconcile tool, approval, and receipt events;
7. report cost per successful case using labeled proxies or dated prices;
8. tabletop a draft-only canary, stop condition, and rollback; call them operated only if an added release environment executes them;
9. write the customer escalation, complaint, appeal, and incident paths;
10. deliver a six-minute teach-back and a 14-minute evidence defense. Record reviewer objections, answers, and remaining risks.

Done when with the provided lab: the runnable scenarios and tests pass, every unsupported claim is removed, and the evidence pack identifies which tenant, approval, recovery, and release controls remain design-only. The prototype is not done as a production system until implemented tests prove cross-tenant denial, exact approval, duplicate-free recovery, and executable stop/rollback behavior.

Cumulative production-readiness and design-defense rubric

Use four evidence levels:

• 0 — Claim: “We handle it,” with no reviewable artifact.
• 1 — Design: named owner, contract, diagram, or procedure exists.
• 2 — Verified: deterministic test, inspected trace, or completed review demonstrates the control in the capstone.
• 3 — Operated: a representative rehearsal, staged environment, or monitored run demonstrates the control and response owner.

Score evidence, not confidence:

Do not hide a zero with a high total. Use the rubric for two distinct decisions:

Provided offline prototype defense

• score every row honestly; controls absent from the package remain at Level 0 or 1 unless you implement and test them;
• pass the course defense by supporting every claim, labeling design-only work, assigning open risks, and teaching the system boundary back accurately;
• any critical row below Level 2 means not production-ready, even if the prototype defense passes.

Optional production-extension defense

• every row must reach at least Level 2;
• rows 4-7 and 10 are critical and may not be waived;
• at least one end-to-end rollback or recovery rehearsal must reach Level 3;
• every open risk has an owner, deadline, and release consequence;
• a reviewer must be able to reproduce the evidence and teach the boundary back accurately.

Production authorization is still an organizational decision, not a course certificate. Passing the supplied offline defense demonstrates accurate engineering judgment; it does not certify controls the lab does not contain.

Pause & Recall

1. Distinguish answer, draft, proposal, and commit.
2. Why is a ticket ID not authorization?
3. Which fields make approval narrow and fresh?
4. How does reconciliation handle a lost success response?
5. What does the current support lab prove—and not prove—about refunds?
6. Why may no cumulative score cancel a critical zero?

Production lens

Launch in the least consequential mode: agent-assist drafts for trained support staff. Compare against the current process, sample quality under privacy rules, and publish limitations. Expand only after evidence shows the next capability is controlled. Some categories—fraud, legal threats, safety reports, vulnerable customers, privacy rights, and unusual financial remedies—may remain human-led.

Operate the social system too. Train reviewers, protect time for real oversight, audit disparate failure patterns, include support and privacy teams in incident rehearsals, and give customers a clear path to a person. Postmortems should improve tools, policies, evals, training, and product scope—not end with “the model hallucinated.”

Chapter compression

• Separate guidance, drafts, proposals, and commits into distinct capabilities.
• Enforce identity and tenant scope before ticket or knowledge retrieval.
• Approval binds one exact, current action; commit rechecks policy and idempotency.
• Durable recovery asks what happened before deciding what to do next.
• Evaluate ordinary help, adversaries, privacy, failures, recovery, and release behavior.
• Production readiness is evidence across the whole system; critical zeros cannot be averaged away.

Memory hook: Draft by default; scope before lookup; approve the payload; reconcile the effect; defend with evidence.

Retrieval deck

• Q: What is the difference between a proposal and a commit?
  A: A proposal describes one possible effect; a separately authorized, validated, idempotent service performs the commit.
• Q: What must happen before lookup_ticket in production?
  A: Authenticate the actor and enforce tenant, role, purpose, and field authorization in the data query.
• Q: How do you recover when a commit succeeded but its response was lost?
  A: Reconcile using the same idempotency key and authoritative receipt before any retry.
• Q: What is the minimum evidence level for the final defense?
  A: Level 2—verified evidence—for every row, with no waiver for tenant/privacy, recovery, approval, evaluation, or rollback.

Spaced review

• Now: explain the four capability levels and approval record from memory.
• +1 day: reconstruct the twelve rubric dimensions.
• +3 days: run or narrate the lost-success-response reconciliation.
• +7 days: have a peer attack tenant, approval, and rollback boundaries.
• +14 days: rerun the cumulative defense after changing one harness component and compare evidence.

Sources and further study

• NIST AI Risk Management Framework Resource Center
• NIST Privacy Framework
• OWASP AI Agent Security Cheat Sheet
• OWASP Agentic AI Threats and Mitigations
• OpenAI, Evaluation Best Practices
• Google SRE Workbook, Canarying Releases
• EUR-Lex, Regulation (EU) 2024/1689