The moment an institution relies on a reviewer, the reviewer becomes part of the system that needs to be governed.

That is true whether the reviewer is a human expert, an independent evaluator, or another AI agent. The assurance function selects evidence, interprets ambiguity, applies a standard, and decides which findings deserve attention. Each action can be done well. Each can also drift. Giving the function a serious title does not exempt it from having an operating model.

AI makes the problem easier to miss. A team can ask one agent to produce a proposal and a second agent to review it. The reviewer agrees with the reasoning, suggests three improvements, and returns a polished assessment. The team now has two artifacts and a feeling of independent confirmation. The useful question is whether the second agent encountered evidence the first agent did not already choose.

Perhaps the proposal omitted a difficult dependency. Perhaps it framed the objective incorrectly. Perhaps the reviewer checked whether the steps were reasonable, and the steps were reasonable for the wrong purpose. Using a different model can help diversify review, but changing the logo at the top of the chat does not establish independence. Shared assumptions travel quite comfortably. They do not even need an integration.

A consequential review needs its own inputs. The reviewer should receive the governing purpose, original constraints, relevant evidence, acceptance criteria, and authority boundary. It should be possible to test a material claim without depending on the drafter’s explanation of why the claim is true. If the issue is a permission boundary, inspect the permission and the action. If it is a factual claim, follow the source. If it is an omission, the reviewer needs a way to know the omitted thing exists.

The reviewer’s standard also needs a history. Suppose a risk is first treated as a blocker. Three months later, similar evidence is routinely accepted with a note. There may be excellent reasons: stronger mitigations, better testing, a changed operating context. Record them. Otherwise an organization can redefine acceptable behavior through a series of individually plausible decisions and later discover that nobody remembers authorizing the new standard.

Anthropic’s Petri work makes a related point about automated auditors and judges: definitions and thresholds need to fit the domain, and calibration against manually reviewed transcripts matters. The authors also discuss problems with overly leading auditors and with scoring behavior accurately. That specificity is valuable because it gives the reviewing system visible failure modes. Petri’s auditing and judging design

A practical assurance design should include a deliberately varied calibration set: clear defects, acceptable work, borderline cases, and cases where the right answer depends on context. Keep some cases out of routine tuning. Ask the reviewer what evidence would change its conclusion. Examine false alarms as seriously as missed problems. A function that objects to everything trains the institution to ignore it; a function that never objects can make the institution feel wonderfully safe. Neither result proves judgment.

The most useful metric may be the disposition of objections. Was the finding substantiated, withdrawn, resolved, overridden, or left open? By whom, and on what evidence? Counts of findings show activity. Dispositions show how assurance interacts with power. If every serious objection becomes a wording adjustment before publication, the pattern matters. If every disagreement becomes a personal contest, that matters too.

The evaluator must also be able to make a mistake visibly. It should be possible to revise a finding, acknowledge an insufficient test, or admit that an interpretation went beyond the record. Independence is not a performance of certainty. It is the ability to follow evidence even when doing so is inconvenient to the evaluator’s previous position.

Assurance needs provenance, calibration, correction mechanisms, and accountable judgment. We are asking it to help govern systems that change. It should leave enough evidence for us to notice when it has changed as well.

The most dangerous rubber stamp may be the one that can explain itself.

A green status indicator is a claim, not a blessing.

Somewhere beneath it, a system was assessed, a scope was defined, evidence was examined, and someone decided that a particular use was acceptable. The useful question is what happens when one of those conditions changes. Does the indicator move with reality, or does it continue to commemorate a successful meeting?

Imagine an agent evaluated on Tuesday for preparing internal research summaries. It reads a defined document collection and produces a draft for a human reviewer. On Wednesday, someone connects it to a customer workspace because that saves copying. On Thursday, memory is added. On Friday, the agent can send the finished response. Each change is convenient. Together, they create a materially different job from the one that passed Tuesday’s assessment.

The model may be exactly the same. The effective system has changed through reach, context, and authority. A reliable assistant drafting a paragraph for internal review is not the same operating arrangement as an assistant representing the company to a customer. The second use cannot simply inherit confidence from the first.

NIST’s AI Risk Management Framework treats risk management as lifecycle work and recognizes that context matters. The implementation challenge is to keep assurance attached to the conditions that made the assurance true.

Every material assurance claim should answer a few plain questions. What was assessed? For which purpose and action? Under which permissions, knowledge sources, and review arrangement? Which evidence supports the conclusion? What assumptions would make the conclusion unsafe to reuse? Permission to borrow the truck for an errand does not silently include permission to attach a trailer, leave the state, and develop a sudden interest in off-road exploration.

The point is not to freeze the system. The point is to make boundaries inspectable. If an evaluation established that an agent accurately summarizes a defined source collection, preserve that result. If the agent gains a new tool, ask which claims depended on its inability to take that tool’s actions. If a standing instruction changes, identify the behaviors and decisions it governs. A punctuation example and a new ability to transfer funds do not deserve the same review response.

A change-sensitive assurance process needs three parts. First, record the evaluated configuration, permissions, context, and claims. Second, connect operational changes to the claims they may affect. Third, define the interim state while review happens. The agent might continue with narrower permissions, return to drafting, or pause a specific action until evidence is sufficient. The response should match the significance of the change. Repeating a full review for every adjustment will teach people to route around the process.

The missing step in many designs is recognizing which assurance became stale. A change log over here and an evaluation result over there are not enough. The system needs an account of why the evaluation supported the decision in the first place. “Passed testing” is hard to maintain. “Under these conditions, the agent respected this approval boundary in these scenarios” gives the next reviewer something concrete to work with.

The world can also change while the agent stays still. A source document becomes outdated. A business relationship ends. The reviewer leaves. An exception expires. Even if every component remains at the approved version, the conditions that justified using it may have disappeared. Configuration control and operational context need to speak to each other, preferably before the customer does.

A useful evaluation exercise is direct: give a system a valid approval, then change one condition the approval depends on. Remove a reviewer. Revoke a permission. Replace a current source with an archived one. Observe what the workflow detects, what the agent recognizes, and who receives the unresolved decision. The controls should not depend entirely on the agent noticing its own changed circumstances.

Current-state trust preserves the value of past evidence while asking whether it still supports the action in front of us. The green dot can stay. It just needs a reason.

Tuesday’s audit tells us what was known on Tuesday. Wednesday still needs an owner.