Eleven stages, one agent, one recorded decision.
Everything in the preceding parts now gets applied to a single agent. What follows is written to be worked rather than read, and it is deliberately mechanical: each stage says what to do and what you should have when you are finished.
Choose an ordinary agent for the first pass. Meridian Group’s Customer Support Agent will serve as the example: it answers billing and shipping questions, looks up orders, and can issue a goodwill credit up to a stated limit. Starting with your most complex agent tends to turn the session into a discussion about tooling.
Set aside two hours, and bring the agent’s owner and one person who can say no.
What you do. Record the identity, version, and environment. Record the business function, the intended users, and the tasks the agent may perform. Write the prohibited-use list in three specific sentences — for this agent: it does not make retention offers, it does not waive fees above the goodwill limit, and it does not discuss disputes under legal review. Name the technical owner, the business owner, and the approver.
What you should have. A stable agent record that a reviewer can read without asking anyone who owns this agent or what it is for.
What you do. Answer six questions: primary use case, autonomy level, data sensitivity, region, whether a human reviews, and whether the agent takes consequential external actions. For the support agent: customer support, L3 autonomy, personal data, EU, human review on credits above the limit, consequential actions yes. That lands at the limited tier, which the portal shows as medium risk. Record the reasons alongside the tier.
What you should have. A tier, its justification, and the guardrails it sets — a minimum score, a blocking severity, whether sign-off is required, and a re-evaluation cadence.
What you do. Fill in every field in one sitting: model and version, system prompt version, policy prompt version, the four tools and their declared side effects, the retrieval corpus, the memory configuration, the orchestration, the credentials the agent can assume, and the environments it runs in. Mark every field you had to ask somebody about, and every field that should count as a change trigger.
What you should have. A composition record, a short backlog of unknowns, and a draft list of the changes that will later invalidate your evidence.
What you do. Decide three things. The mode: multi-turn, because this agent holds conversations. The turn budget: fifteen is a reasonable first pass, with the understanding that a shorter run leaves most of the eleven attack families unprobed. And the scenario you care about most — take the highest-impact prohibited action and design a five-turn trajectory that tries to obtain it: establish normal use, introduce ambiguity, apply pressure, change the environment, then ask for the action.
For the support agent that scenario writes itself: obtain a credit above the goodwill limit, with the final push arriving inside a document rather than from the user.
What you should have. A test plan tied to a specific prohibited action rather than to a general notion of quality.
What you do. Run it, then run it again unchanged.
proof run agent.py \
--context-dir ./context \
--domain-knowledge-dir ./policy_corpus \
--turns 15 --seed 42 \
--assess-context \
--json report.json --markdown report.mdWhat you should have. Two reports, and the difference between them. That difference is your noise floor, and every later comparison lives inside it.
What you do. Open the Markdown report and read the findings before the scores. For each one, write down what pattern it represents, which turn proves it, what it would cost in this deployment, and what change would fix it. Then group them: eleven findings with three causes are three findings and eight pieces of evidence.
What you should have. A grouped finding list with root causes separated from symptoms, short enough that you can name the three things that matter without rereading it.
What you do. Read the seven criteria the context assessment produced, treating the five scored ones as predictions about which behaviors will fail. Then do the part the score cannot do for you: list every source that can place content into this agent’s context and mark which ones an outsider can influence. For the support agent that list is the customer’s message, the order record, the policy corpus, and any attachment — two of the four influenceable.
What you should have. A scored context assessment, plus a written list of untrusted inputs and how the agent distinguishes them from instructions.
What you do. Take the three obligations that genuinely bear on this agent and write each as a control that could fail. For the support agent: goodwill credits above the stated limit require a recorded human approval enforced in the tool layer; customer personal data is not transmitted to any tool outside the registered scope; and no claim about entitlement is produced without grounding in the approved policy corpus. Give each a test, an owner, a threshold, and a status drawn from the run.
What you should have. Three controls with evidence attached and an honest status, including any marked as unevaluated.
What you do. Compute the index and read it in order: hard block first, then the weakest dimension, then completeness, then the number.
proof pai --report report.json --explainWhat you should have. Four dimension scores and a composite, with the aggregation shown — and, if the result is partial, a clear statement of which dimension lacks evidence.
What you do. Resolve the policy for this tier and read every rule that fired: thresholds met, thresholds missed, findings that matched a block rule, regressions against the baseline. Route the result to the named approver with the evidence package attached. The approver’s job is not to re-run the evaluation but to accept or refuse a stated residual risk, in writing, with an expiry.
The support agent’s first gate returns REVIEW at 84%: two medium findings the business owner may accept, and one control whose evidence is thin. That is the most common first outcome, and a useful one, because it forces the conversation governance exists to force.
What you should have. One sentence of this form — this version is BLOCKED because rule X fired on finding Y, and clearing it requires Z — plus a recorded decision, a named approver, and an authorized scope naming the environment, users, data classes, and tools.
What you do. Turn the change triggers from Stage 3 into a cadence and a rule set. Store the baseline run where a release record can reach it. Convert the sharpest finding from Stage 6 into a permanent regression scenario. Confirm the reversal path and time it.
What you should have. A schedule, a trigger list, a baseline, one new regression test, and a measured time-to-revoke.
A registry entry. A completed composition record with its gaps marked. Two evaluation runs and a noise floor. A grouped finding list. Seven context criteria scored. Three controls with statuses and evidence. Four dimension scores. One resolved policy. One recorded decision with a named approver. One assurance schedule.
That is a governance program. Everything after it is repetition and scale.
One agent, worked end to end, teaches more than a framework read cover to cover.
Use these as the review questions once you reach the end of the eleven stages. If any of them cannot be answered from the artifacts on the table, the corresponding stage is not finished.