A long conversation summary dropped 'never call delete'. Where should that rule live?

The summary is the immediate failure, but I would not fix this by asking the summarizer to be more careful and stopping there. Summaries are compressed context. They can omit or distort information. An action boundary cannot depend on a sentence surviving every future compression.

I would separate three things that are often called “agent state.”

The original prohibition needs a durable representation outside the summary. Record its source, scope, time, and precedence. For example, a user constraint might say delete_api = DENY for account P9831 during run R42. An organization policy could say the same thing with a broader scope and stronger authority. On every resumed step, the context builder injects the active constraints into the model input so the model can plan accordingly. More importantly, the tool runtime checks the constraint again when the model asks to call the delete API. The prompt helps behavior. The runtime decides whether the effect is allowed.

I would not store every casual sentence as a permanent policy. There has to be a clear contract for extracting a high-impact instruction, confirming its scope if unclear, and showing the user the active restriction. The extractor can suggest a structured constraint, but the authoritative record should be written through the same control path used to manage the run. If the user said “do not delete anything while you investigate,” its scope may end with the investigation. If the organization forbids deletion from production, no user turn can override it.

The failure test is quite concrete. Start the agent with the prohibition. Force a context reset or summary that drops it. Resume from a checkpoint. Have the model propose a delete call. The tool gateway must reject it, record the decision, and offer a safe next step. Repeating this with paraphrases, conflicting later instructions, and several simultaneous tasks catches more than checking whether one summary contains the word “never.”

OpenAI's compaction guidance describes carrying prior state in fewer tokens. That is useful for continuity, cost, and latency. It is not a substitute for an application owned authorization decision at the tool boundary. The system should remain safe even if the model has lost the earlier sentence entirely.

Now the interviewer says the user returns a week later and writes, “Delete the temporary resources now.” I would first ask what the earlier rule was. If it was a user preference scoped to this run, and the same authorized user explicitly changes it, update the durable constraint with a new version and record the change. If it was an organization policy or another person's approval, the new instruction cannot supersede it. Then validate the exact target, effect, and current permissions before the tool call. The old summary is not used to decide precedence.

Their next push is harder. The worker resumes halfway through a delete operation after the rule was changed. The execution state must tell us whether that external action was never sent, may have been sent, or was confirmed. A new authorization check cannot turn an unknown effect into a safe retry. This connects context engineering to durable execution. The constraint says whether a new action is allowed. The operation ledger says what may already have happened.

A strong answer keeps these two boundaries separate. The agent can forget a detail in working context and still be prevented from making an unauthorized call. It can remember the detail perfectly and still need to check current permission before acting.