AI agents remember what you told them to do. Over a long task, they forget what you told them not to do.

In February, a director of AI alignment at a large technology company gave her agent a narrow job: look through her inbox and suggest emails to delete. She added a condition in plain words — don’t action until I tell you to.

It deleted more than two hundred.

By her account, the agent had summarized the conversation to save context space, and the summary dropped her instruction. Not overrode it. Dropped it. At the moment of deletion the agent was not defying a constraint; as far as its working context was concerned, there was no constraint to defy.

That distinction is the whole problem. We spend our safety effort on whether a model will comply with a rule, and the more common failure is that the rule is no longer in the room.

The asymmetry is measured, not anecdotal

This is not one unlucky inbox. One 2026 study found that a widely used coding agent’s summarizer kept 53% of safety rules after a single pass, and 10% after five. Five summarization passes is not an unusual day for an agent working a long task.

Another study, across 12 models, found that even simple “never” rules faded as sessions grew while “always” rules held.

The explanation offered for that asymmetry is uncomfortable once you see it, because it is structural rather than a model defect. An “always” rule shows up in every response the agent produces, so the agent’s own output history keeps reminding it the rule exists. A “never” rule produces nothing. It leaves no trace in the transcript, so when the transcript gets compressed there is nothing to compress — the rule was only ever stated once, at the start, in a span that summarization treats as preamble.

Your “always sign off with the ticket number” rule is self-reinforcing. Your “never delete anything without approval” rule is a single sentence decaying in a buffer.

Japanese railways solved this with pointing

Train drivers in Japan practise shisa kanko — pointing at each signal and saying aloud what it shows. “Signal green.” They point at the speedometer and call the speed. It looks absurd to outsiders and it is one of the more effective safety interventions in transport.

A railway research institute found it cut mistakes on a simple task by almost 85%.

The mechanism is not discipline and it is not ritual. A silent check leaves no evidence that it happened, to anyone, including the person doing it. Pointing and calling converts a check into an action with a motor component and an audible output, which means it can be observed, audited, and noticed when it goes missing.

That last one is the part that transfers to agents. The value of the call-out is not that the agent says the rule. It is that a missing call-out is detectable.

The card lives outside the conversation

Four components, and the first one is the one teams get wrong.

A rule card stored as a signed, versioned artifact — in our case an OCI artifact pulled by digest, delivered to the workload as a read-only mount. The card is not in the system prompt as a string literal in application code, and it is definitely not in the conversation, because anything in the conversation is subject to the compression that caused the problem.

A context assembler that attaches the card verbatim at every boundary where context is rebuilt. An enforcement point at the tool gateway — the same gateway that prices exposure if you are running the margin pattern. And a call-out verifier that runs between the call-out and the side effect.

The card is bound to a workload identity. The gateway resolves which card applies from the caller’s SPIFFE SVID rather than from a parameter, so an agent cannot present a more permissive card than the one it was issued.

1. Put the rules on a card

Keep standing rules, above all the “nevers,” in a short list outside the conversation. Attach it word for word to every fresh context, after each summarization, and in each brief to a sub-agent.

Researchers call this constraint pinning. In one study it took violations from 30% to 0%.

The card:

card: support-agent-nevers
version: 11
digest: sha256:2f91...cc40
issued_by: platform-risk
max_rules: 12
rules:
  - id: N1
    text: "Nothing is deleted until the user approves it in this session."
    enforcement: code
    applies_to: [mail.delete, object.delete]
  - id: N2
    text: "Never promise a delivery date."
    enforcement: call_out
    applies_to: [email.send, ticket.reply]
  - id: N3
    text: "Never send to an address outside the customer's own domain."
    enforcement: code
    applies_to: [email.send]
  - id: N4
    text: "Never close a ticket you opened in this session."
    enforcement: code
    applies_to: [ticket.close]
removal_policy:
  requires: original_setter

Note enforcement. Each rule declares whether a machine can check it or whether it needs the agent to state its reasoning. That field is what stops the card becoming a wish list.

The injection points are where this fails in practice, because there are more of them than anyone lists on a whiteboard. Fresh context. After compaction. Sub-agent spawn. Retry after a tool error. Model fallback when the primary is rate-limited. Any truncation of a long tool result that happens to sit above the card in the buffer.

We instrument every one and emit a single metric: did the card digest appear in the final assembled context for this turn? Card survival rate is the first thing to measure and almost nobody measures it.

2. Point and call before anything hard to undo

Before any action that is hard to undo — delete, send, pay, publish — show the agent the card and have it call out which rule applies and where things stand.

“Rule: nothing is deleted until you approve. Status: not approved. Asking now.”

Make the call-out a required structured parameter of the tool call, not prose in the transcript:

{
  "tool": "mail.delete",
  "args": { "message_ids": ["...", "..."], "count": 212 },
  "call_out": {
    "card_digest": "sha256:2f91...cc40",
    "rules_cited": ["N1"],
    "rule_text_verbatim": "Nothing is deleted until the user approves it in this session.",
    "status": "not_approved",
    "basis": "No approval message from the user in this session.",
    "intent": "ask"
  }
}

Prose in the transcript cannot be enforced on, verified, counted, or alerted on. A required parameter can be all four. This is the implementation decision that matters most in the whole pattern, and it is a schema change rather than a model change.

rule_text_verbatim has to match the card by string comparison. The agent reads the rule off the card and copies it; it does not paraphrase from memory. Each retelling of a rule shifts it slightly, and “nothing is deleted until approved” becomes “deletions need approval” becomes “significant deletions need approval” over a long enough session.

3. No call-out, no action

The system blocks a hard-to-undo action that arrives without a call-out. Not logs it. Blocks it.

New York subway conductors must point at a striped board on the platform before opening the doors. If they cannot see the board, the doors stay shut. The rule does not care why the board is not visible.

The gateway check in Go:

func (g *Gateway) Admit(ctx context.Context, req ToolCall) error {
	card, err := g.cards.ForIdentity(ctx, req.Principal) // from SPIFFE SVID
	if err != nil {
		return fmt.Errorf("no card resolved: %w", err)    // fail closed
	}
	rules := card.RulesFor(req.Tool)
	if len(rules) == 0 || !req.Tool.HardToUndo() {
		return nil
	}
	co := req.CallOut
	switch {
	case co == nil:
		return ErrNoCallOut
	case co.CardDigest != card.Digest:
		return ErrStaleCard                                // card moved mid-run
	case !co.Cites(rules.IDs()):
		return ErrRuleNotCited
	case !card.Rule(co.RulesCited[0]).MatchesVerbatim(co.RuleTextVerbatim):
		return ErrRuleParaphrased
	}
	return g.verifier.Check(ctx, card, req)
}

ErrStaleCard earns its place. If the card is updated mid-run, an agent carrying the old digest is operating on rules that no longer apply, and the correct behaviour is to stop and reassemble rather than proceed on a stale constraint set.

Fail closed when no card resolves. An agent whose card lookup failed is an agent with no constraints, which is the state you are trying to make impossible.

4. Check the call-out against the card

A second reader — a small model or a person — compares the call-out with the card and the action. A stated claim is far easier to check than a silent decision.

Split the check by what kind of thing it is. The mechanical part is policy:

package agents.callout
default allow := false
# The agent claims approval exists. Verify against the approval
# store, not against the agent's own assertion.
allow if {
	input.call_out.status == "approved"
	some a in input.session.approvals
	a.scope == input.tool
	a.covers_count >= input.args.count
	a.actor_kind == "human"
}
# Asking is always permitted; asking is not acting.
allow if {
	input.call_out.intent == "ask"
	not input.performs_side_effect
}
violation["status_claim_unsupported"] if {
	input.call_out.status == "approved"
	count(input.session.approvals) == 0
}

The claim “status: not approved” is checkable. So check it, against the approval store, every time. A call-out whose factual claims are verified mechanically and whose judgment claims go to a reviewer is a much stronger control than one that is read by a model and nodded at.

For the judgment rules — “never promise a delivery date” — give the verifier the card, the action, and the call-out. Nothing else. Do not hand it the conversation. Whatever framing in that conversation caused the primary agent to drift will do the same to a reviewer reading the same text, and you will have built two agents with one blind spot.

5. Guard the card

Keep it short. The longer the card, the less each rule counts — attention is finite for models the same way it is for the conductor who has nine things to point at and two seconds to do it.

We cap cards at twelve rules and enforce the cap in CI. The cap is the useful part, because it forces the argument about which rule to drop to happen in a pull request rather than never.

Only the person who set a rule can take it off. That is the removal_policy field, and it should be enforced by the artifact pipeline, not by convention.

Enforce in code what code can check

This is the line that decides whether you have built a control or a performance.

“Never delete without approval” is a code rule. The gateway can check the approval store. Putting it on the card as a call-out rule and trusting the agent to honour it is choosing a weaker mechanism when a stronger one was available.

“Never promise a delivery date” cannot be checked by code in any way I would defend. That is what the call-out is for.

So the card should get smaller over time, not bigger. Every rule that moves from enforcement: call_out to enforcement: code is a rule that no longer depends on the model remembering anything. The card is for the residue — the rules that genuinely need judgment.

Count the missing call-outs

Your existing monitoring shows “always” rules being followed, because following them produces output. It says nothing about the “nevers,” because a respected “never” produces silence and so does a forgotten one.

A skipped call-out is the signal you get. It is the only one.

Three metrics, and they are cheap:

Card survival rate — the share of assembled contexts containing the current card digest. Missing call-out rate — hard-to-undo tool calls rejected for ErrNoCallOut, by agent and by boundary type. Paraphrase rate — ErrRuleParaphrased rejections, which spike right before the card stops working at all.

Alert on card survival dropping, not violations rising. Violations are the lagging indicator.

Where this pattern breaks

Call-out theater

The serious failure. A model that is rewarded for producing well-formed call-outs produces well-formed call-outs, including when its actual reasoning does not match. A self-report is not evidence of an internal state. This is why the verifier has to check factual claims against external systems and why the call-out must never be the only control on anything a machine could have checked.

Card bloat

Every incident review wants to add a line, every legal review wants two. A card with forty rules is a card the model skims and a card nobody reads before adding the forty-first. The cap is not bureaucracy; it is the mechanism.

Incomplete injection points

The team instruments fresh context and compaction, ships, and six weeks later discovers that the retry-after-error path rebuilds context from a different assembler which never had the card. Card survival rate catches this. Nothing else does.

Latency on the hot path

Call-out plus verification adds a round trip before every irreversible action, and the temptation is to sample. Do not sample. Narrow the set of tools classified hard-to-undo instead, which is a decision you can defend, unlike a 10% check rate.

Verifier drift

The verifier has its own prompt, its own model version, and no tests. Give it a regression suite of recorded call-outs with known verdicts and run it in CI, because a verifier that silently started approving everything looks exactly like one that works.

Adoption: measure survival before you block anything

If agents are already running in production, the first move is not enforcement.

Write one card for one agent, five rules maximum, and attach it at the context boundaries you know about. Log everything, block nothing. Then instrument the boundaries and watch card survival for a fortnight — the number will be below 100% and the gap will point at a code path you did not know existed.

Next, require call-outs on a shortlist of hard-to-undo tools, still without blocking. The missing call-out rate here tells you how much of your agent’s behaviour was running on unstated assumptions.

Then block, one tool at a time. Then add the verifier. Then start moving rules from call_out to code and shrinking the card.

Teams that start at “block” generate enough false rejections in week one that the pattern gets rolled back before anyone sees the survival data — which was the actual finding.

Supervision evidence is a record that the control fired

Under SEC and CFTC oversight, and under Regulation SCI, the questions that follow an incident are about the control at the moment of the action — not the control as it exists today, and not the policy document describing it.

The call-out log answers that directly. For each hard-to-undo action it holds the card digest in force, the rule cited, the verbatim text as the agent read it, the claimed status, the verifier’s decision, and the identity of the workload. That is a stronger artifact than a transcript in which somebody appears to have been careful.

Here is the part I did not expect when we started. The call-out log is also the cleanest record we have of the rules we never wrote down. Reading rejected call-outs, you find agents citing constraints that exist nowhere on any card — picked up from a prompt, an example, a document in the corpus. Those are the rules your organization is actually operating on, and until you see them cited you have no idea they are there.

Rules you cannot see being followed are rules you cannot trust

The pattern is five steps and one idea: a constraint that produces no observable behaviour when it is working is a constraint you cannot operate. Make the check audible. Then count the silences.

The director in February did not get it wrong. She stated a clear condition in plain language, and the system she was using had no mechanism to carry that condition across a boundary it crossed on its own initiative. That is an architecture problem, and the two hundred deleted emails were the architecture reporting its state.

So: which “never” would hurt most if your AI forgot it halfway through a long task?