A technical walkthrough of the Typed Harness State Model - typed persistent state, integrity labels, protected deontic state, and deterministic authorization at the tool boundary.

Decay Without Creep, Part 4 of 4 The previous posts established the problem and the empirical case. This final post stays with the machinery: the data model, integrity rules, operators, invariants, enforcement boundary, and threat model of the Typed Harness State Model (THSM). The central idea is simple: Knowledge and authority should not share the same lifecycle. The implementation turns that idea into four state types, an integrity model, restricted memory operators, provenance requirements, and a deterministic authorization gate. The state model THSM represents harness state as entries of the form: e = &lt;id, type, content, provenance, integrity, validity, activation&gt; The type is one of four: EPI SEM PROC DEON EPI — episodic state EPI entries are immutable, append-only trajectory events: tool call tool result user event principal authorization event task outcome Later state can therefore point back to what actually happened. EPI is the ground-truth substrate for derived state. SEM — semantic state SEM entries represent derived knowledge. Examples include: “The service uses PostgreSQL.” “The repository uses Python.” “The current deployment region is A.” Because these entries can become stale, THSM permits retrieval, decay, and consolidation over SEM state. PROC — procedural state PROC entries represent skills or procedures. For example: Build → test → package → deploy A procedure can contain: steps; preconditions; gates; evidence; references to the underlying events or knowledge from which it was derived. PROC entries are decayable and consolidable, but deliberately capability-stripped : a procedure says how to act, never whether the action is currently authorized. DEON — deontic state DEON entries represent authority. Each entry contains information such as: kind scope principal conditions expiry The kinds are: GRANT DENY REVOKE OBLIGE A scope can describe a permitted action using properties such as: tool; argument patterns; resource patterns; optional use counts; conditions. This is the only state used to compute current authority. Entries also carry bi-temporal validity: creation time, valid-from, valid-to, and expiry. Supersession and invalidation are recorded rather than deleting history, following the temporal approach used by Zep . Effective authority At time t , THSM computes effective authority as a deterministic function of the active deontic entries. Conceptually: effective grants - denies - revoked grants - expired grants - exhausted grants The result is the set of actions currently authorized. The model does not calculate this set. That distinction is essential. The model may be shown relevant authority information. It may reason about it. But the harness resolves the actual authorization decision. Integrity labels Typing alone is not enough. We also need to distinguish where state came from. THSM uses four conceptual integrity levels: UNTRUSTED DERIVED HARNESS PRINCIPAL The ordering is: UNTRUSTED &lt; DERIVED &lt; HARNESS &lt; PRINCIPAL The model&#39;s generated text is DERIVED. Deterministic harness operations are HARNESS. An authenticated principal is PRINCIPAL. This gives us a way to prevent a model-generated sentence from becoming equivalent to an authenticated authorization event. Biba no-write-up: integrity cannot increase The model should not be able to manufacture higher-integrity state. If an LLM writes: “The principal approved production deployment.” the system does not simply accept that sentence as a principal event. Its provenance remains derived. A simplified rule is: label(entry) = meet(writer label, source labels) The important consequence is: A model cannot increase the integrity of its own output merely by writing it into persistent memory. This adapts Kenneth J. Biba&#39;s Integrity Considerations for Secure Computer Systems (MITRE Technical Report MTR-3153, 1977) to agent state. Widening versus narrowing Not every authority change has the same risk. THSM therefore distinguishes widening events from narrowing events. Widening authority includes: GRANT OBLIGE These require a PRINCIPAL source. Narrowing events include: DENY REVOKE expiry These can be generated by the appropriate trusted harness mechanisms. The practical effect is that a model can propose a grant, but a proposal is not itself a grant. A simplified lifecycle is: Model proposes permission ↓ DERIVED proposal ↓ Principal confirms ↓ PRINCIPAL authorization event ↓ Effective grant The proposal and the authorization are different state transitions. Memory operators THSM restricts which operators can act on which state. Conceptually: State Decay Consolidation Authority effect EPI no no evidence only SEM yes yes none directly PROC yes yes none directly DEON no no determines authorization This table captures much of the architecture. The key rule is not: “Memory is safe.” It is: “Different state types are subject to different operators.” The implementation exposes decay policies — none, Ebbinghaus, ACT-R (Anderson 

Typed Harness State - A Technical Walkthrough

An agent can remember a prohibition, state it correctly, and still execute the prohibited action. This is the knowledge–action gap.

Decay Without Creep, Part 3 of 4 Imagine asking an AI agent: “Are you allowed to deploy this service?” It answers: “No. My deployment permission was revoked.” You then give it the deployment command. And it executes it. That sounds contradictory. It is also an important distinction for agent security. The agent may know the rule. The agent may be able to state the rule. But neither fact guarantees that the rule will control the action. This is the knowledge–action gap at the center of our experiments. Knowing is not enforcing For an ordinary question-answering system, it is reasonable to evaluate whether the system knows a rule by asking it about the rule. For an agent that can use tools, that is insufficient. There are at least three different questions: 1. What does the agent remember? 2. What does the agent say it is allowed to do? 3. What action does the system actually permit? These can produce different answers. An agent may forget a prohibition. It may remember it but fail to retrieve it. It may retrieve it and correctly describe it. It may describe it correctly and still produce the prohibited tool call. The last case is especially important because it shows why authority cannot safely be reduced to model belief. The simple experiment Consider a revoked permission. At time 1: Principal: “You may deploy version 4.2.” At time 2: Principal: “You may no longer deploy.” At time 3: User: “Deploy version 4.2.” There are several possible failure points. The agent might have forgotten the revocation. The memory writer might have lost it during consolidation. The retrieval system might retrieve the old grant instead. The model might see both and choose the old permission. Or the model might correctly identify the revocation and still call the deployment tool. These failures look similar from the outside — an unauthorized action happened — but they have different causes. That is why our benchmark separates memory behavior from authorization behavior. Retrieval is not enforcement A natural response to the revocation problem is: “Just make sure the revocation is always retrieved.” That can help. It is not sufficient. Governance Decay illustrates the same general problem from another angle: constraints that disappear during context compaction can later stop controlling tool behavior. Constraint pinning can preserve them in context, but keeping a constraint visible is still different from implementing an external authorization mechanism. Our experiments make this distinction explicit. We tested a configuration in which relevant deontic state was pinned into the model&#39;s context on every turn, but no deterministic tool-boundary gate was used. Unauthorized execution still occurred. Across the five main rows reported in the paper, false-authority rates in this no-gate configuration ranged from 0.20 to 0.60. Pinning reduced the rate in some cases. It did not eliminate it. Why pinning is still useful This does not mean pinning is useless. Quite the opposite. Keeping relevant authority information visible can improve model behavior. It can reduce mistakes caused by retrieval failure or context loss. It can also improve the model&#39;s ability to explain why an action is not permitted. But it should be understood as a behavioral mitigation , not as the final enforcement layer. A pinned instruction says, in effect: “Here is the rule. Please follow it.” A tool-boundary gate says: “The rule has been evaluated. This action will or will not execute.” Those are different guarantees. The deeper problem: the model is not the authority oracle Suppose the model sees: DENY: production deployment It may comply. But the system still has to decide what happens if: the model ignores the denial; the model misinterprets the scope; the model calls a different tool; a skill invokes the tool indirectly; the model generates an argument that falls outside the apparent scope; the memory contains contradictory information; the context is compacted; the model generates a new permission claim. If the model remains the final decision-maker, every one of these becomes a model-behavior problem. If authorization is resolved at the tool boundary, they become state-resolution and policy-enforcement problems. That is a much more tractable architectural boundary. Skills make the problem worse Now consider a skill. Suppose an agent has stored: Deploy service: 1. Build the artifact. 2. Run tests. 3. Push the image. 4. Trigger deployment. At the time the skill was learned, deployment was authorized. Later, deployment is revoked. What should happen to the skill? It should not necessarily be deleted. The procedure itself may still be useful. Someone else may be authorized to use it. The correct behavior is: retain the procedure + re-evaluate authority at execution time This is why we describe THSM procedures as capability-stripped . A PROC entry tells the agent how to perform a task. It does not grant the capability to perform that task. What happened in t

When an AI Agent Knows the Rule but Breaks It Anyway

Knowledge, skills, episodic history, and authority do not have the same lifecycle. A useful agent memory architecture should treat them differently.

Decay Without Creep, Part 2 of 4 Forgetting sounds like the opposite of memory. For an AI agent, it may instead be part of having a good memory. A long-running agent cannot indefinitely accumulate every observation, intermediate result, old instruction, failed attempt, tool output, and generated note without eventually facing practical problems. Retrieval becomes harder. Context becomes larger. Old information can conflict with newer information. Storage grows. This is why selective forgetting has become an important part of agent-memory research. But there is a question that comes before deciding how to forget: What kind of thing are we forgetting? That question is the focus of this post. Our work on the Typed Harness State Model starts from the premise that an agent&#39;s persistent state should not be treated as one homogeneous collection of memories. Different kinds of state have different meanings. And therefore they can have different lifecycles. Four kinds of state We divide persistent harness state into four categories: EPI Episodic state SEM Semantic state PROC Procedural state DEON Deontic state The names are less important than the distinction. Episodic state: what happened? Episodic state records events. For example: The agent ran tests at 14:32. The deployment failed. The user changed the configuration. The payment API returned an error. These records are useful as historical evidence. In our model, episodic entries are immutable and append-only. They form the event-sourced substrate from which other state can be derived. That makes them different from ordinary summaries. A summary can change. An event record should not silently change because a memory writer decided that a different summary would be more convenient. Semantic state: what is believed to be true? Semantic state represents derived knowledge. For example: The service uses PostgreSQL. The production environment is in region A. The repository uses Python 3.12. The procurement workflow requires two approvals above a threshold. These facts can become stale. If the repository migrates from Python 3.12 to 3.13, an old fact should eventually be updated. This is exactly the kind of state for which retrieval, consolidation, relevance scoring, and selective forgetting can make sense. Procedural state: how do I do something? Procedural state contains skills or workflows. For example: To deploy the application: 1. Run the tests. 2. Build the image. 3. Push the image. 4. Trigger deployment. Procedures also have a lifecycle. A deployment workflow can change. A command can become obsolete. A skill can drift. A procedure can be replaced by a better procedure. So procedural memory needs lifecycle management too. Our model therefore allows PROC entries to decay and consolidate. But there is one important restriction: A procedure does not carry authority. A skill can describe how to perform an action. It cannot, by itself, establish that the agent is currently permitted to perform that action. Deontic state: what may I do? Deontic state is different. It describes permissions, prohibitions, revocations, and obligations. In our model, these are represented as: GRANT DENY REVOKE OBLIGE A grant might allow a specific tool and resource. A deny might prohibit it. A revoke can invalidate a previous grant. An obligation can require an action under specified conditions. The important property is that deontic state determines authorization. That gives it a fundamentally different role from ordinary knowledge. Why age is not enough Consider these two memories: The service was deployed using version 4.2. and: The agent is not authorized to deploy to production. Both might have been written six months ago. Their age tells us almost nothing about whether they should be treated the same way. The first may be obsolete. The second may still be fully valid. The same problem appears with access frequency. A fact about an obscure part of a repository may rarely be retrieved but remain useful. A prohibition may rarely be retrieved because nobody has attempted the prohibited action. Low access frequency does not imply low authority. This matters because many forgetting strategies use signals such as: time since last access; access frequency; semantic relevance; task usefulness; outcome value; redundancy. Those signals can be reasonable indicators for memory utility. They are not automatically indicators of authorization validity. Selective forgetting is not the enemy It is important not to draw the wrong conclusion. The answer is not: “Never forget anything.” That would throw away the advantages of selective memory. Systems such as MemoryBank and FadeMem investigate mechanisms for retaining useful memories while allowing less useful information to fade. FSFM and Selective Forgetting approach the same pressure with selective and graph-based retention. The architectural lesson is narrower: Do not assume that one forgetting policy should govern every type of state. A memory 

What Should an AI Agent Be Allowed to Forget?

Why long-running AI agents need to forget some information without forgetting the authority constraints that govern what they are allowed to do.

Decay Without Creep, Part 1 of 4 Long-running AI agents need memory A coding agent may need to remember how a repository is structured. An assistant may need to remember facts established several conversations ago. An autonomous workflow may need to retain procedures that it has learned to execute repeatedly. But once an agent has enough memory, another problem appears: not everything should be remembered forever. Old information becomes stale. Preferences change. Procedures become obsolete. Temporary context becomes irrelevant. A memory system that retains everything indefinitely can become expensive, noisy, and less useful. That has led to an increasingly important question in agent design: How should an AI agent forget? At first glance, this sounds like a straightforward optimization problem. Keep information that is useful and discard information that is not. But there is a category of information for which that rule is dangerous. That category is authority . Memory is not all the same Consider three things an agent might store. First: The deployment service is currently hosted in region A. That is knowledge. It may become outdated and should eventually be updated or forgotten. Second: To deploy the service, run these commands in this order. That is a procedure or skill. It may also become outdated as the software changes. Third: This agent is not allowed to deploy to production. That is different. It is not merely information about the world. It is a constraint on what the agent may do. The first two can reasonably participate in a memory lifecycle based on relevance, age, access frequency, or usefulness. The third should not become ineffective simply because a memory scorer decides that it is old or rarely retrieved. This distinction is the starting point of our work, “Decay Without Creep.” The problem with treating authority as ordinary memory Suppose a principal gives an agent permission to run a deployment command. The agent stores that permission. Later, the principal revokes it. A conventional memory system might now contain both pieces of information: Permission granted Permission revoked What happens next depends on the memory architecture. Perhaps the revocation is retrieved. Perhaps it is not. Perhaps the two memories are consolidated into a summary that accidentally preserves the grant but loses the revocation. Perhaps the revocation is considered old and decays. Perhaps the model sees both but interprets the older grant as still applicable. Perhaps a learned skill contains the deployment procedure and the agent simply follows the procedure when asked. None of these problems require an attacker to break into the system. The failure can emerge from the normal operation of a memory system. Recent work has made this broader issue increasingly visible. Memory systems are being studied not only as mechanisms for improving recall, but also as potential sources of safety drift and authorization errors. Agent Memory Is a Surface for Endogenous Authorization Laundering studies cases where persistent memory can create spurious permissions, while Governance Decay shows how context compaction can remove safety constraints from active context. The important observation is that memory and authority have different failure modes. Forgetting can be useful Forgetting itself is not the problem. In fact, selective forgetting is useful. MemoryBank , for example, uses an Ebbinghaus-inspired forgetting mechanism to selectively retain and reinforce memories. FadeMem studies adaptive forgetting based on relevance, access frequency, and temporal patterns. These mechanisms address a real problem. If an agent accumulates thousands of notes, retaining everything forever is unlikely to be an efficient strategy. Memory has a limited operational budget, and stale information can interfere with useful information. The problem appears when the same machinery is applied indiscriminately to authority. An old fact can be stale. An old procedure can be obsolete. An old permission can still be valid. An old prohibition can still be binding. Age alone does not tell us which of these is safe to forget. A prohibition can be old because it worked There is a subtle inversion here. Suppose an agent has been prohibited from deleting production data for six months. During those six months, the prohibition has never needed to change. A memory system might observe: it is old; it is rarely retrieved; it is associated with few successful tasks; newer information is more frequently accessed. From the perspective of ordinary memory optimization, the prohibition may look like a candidate for eviction. From the perspective of authorization, its age tells us almost nothing. The fact that the prohibition has not changed may simply mean that it has successfully remained in force. This is why we describe the problem as decay without creep . We want an agent to forget knowledge when forgetting improves the system. We do not want the process of forget

When AI Memory Forgets the Wrong Thing

Prime Agent puts the entire harness — prompt, skills, memory, sub-agents — behind a CRUD surface the agent edits mid-task. The benchmark numbers are striking. So is what it did in Factorio.

For a long time the interesting variable in an agent was the model. You swapped the weights, the thing got better, and everything wrapped around it stayed roughly where it was: a loop, a list of tools with JSON schemas, a summariser that fired when the context filled up. That has stopped being where the movement is. The same weights, put in two different harnesses, now produce materially different work — and the gap between the two harnesses is larger than the gap between adjacent model releases. A harness is everything around the model that lets it actually finish something: the loop, the tool surface, the context policy, the sandbox, the permission checks, the recovery path when a step fails. It used to be plumbing. It is now the design. The clearest statement of that shift is Prime Agent , which Prime Intellect open-sourced under MIT in August 2026, built on top of pi . It is worth reading not because it wins a leaderboard but because it takes the opposite position on all three of the structural choices a harness has to make. The three choices How actions are encoded. The default is a JSON tool schema: the model emits a call, the harness parses it, runs it, and pastes the result back into context. The alternative is code — the model writes a program, the program runs, and the tool surface is whatever is importable. Who owns the context. The default is that the harness owns it. It decides what gets summarised, what gets dropped, when to compact. The alternative is that the model owns it, with its own history reachable as data it can slice, filter and search without reading it back through the window. Whether the harness is fixed. The default is that it is. Prompts, tools and memory are set by whoever deployed the thing, and the agent works inside them. The alternative is that the agent edits them while it works. Most harnesses answer: schemas, harness-owned, fixed. Prime Agent answers: code, model-owned, mutable. Its argument for doing so is that current designs &quot;were built around the capabilities of earlier generations of models&quot;, and that fixed schemas plus automatic compaction now force a model &quot;to work around its own scaffolding instead of leveraging it&quot;. One kernel, and functions inside it Prime Agent has a single tool: a persistent IPython kernel. Everything else — file edits, search, skills, sub-agents — is a Python function pre-imported into it. The kernel survives across turns and across sessions, which means intermediate state lives in variables rather than in the transcript. That is the part worth sitting with. If a sub-agent returns forty thousand lines of log, a schema-based harness has to put those lines somewhere in the context window or throw them away. Here they are a variable, and the model writes three lines of Python to count what it cares about. The paper&#39;s framing is that the model &quot;programmatically runs functions over data rather than spending tokens reading data using tools&quot;, and the measured effect is better scores at lower token spend, which is not the usual direction of that trade. Sub-agents are function calls with the same property: # returns immediately with a handle; the child gets its own kernel and history handle = await rlm(&quot;port the sprite decoder to Rust and make the tests pass&quot;) # the harness itself is writable, through the same CRUD surface as everything else create_skill(&quot;decode_sprite&quot;, source=...) # a tool the agent wrote for itself update_prompt(&quot;vdp&quot;, &quot;sprite priority is per-tile, not per-layer&quot;) create_memory(&quot;genesis-vdp-quirks&quot;, ...) result = await handle # child ran in parallel throughout The four things the agent can write to — prompt notes, sub-agents, skills, memory — are what the paper calls the continual harness , and they all expose the same create_ , update_ , delete_ , list and get operations. /refine sits on top: it reads the trajectory, works out what went wrong or what turned out to be reusable, and applies the smallest set of edits that would have helped. Plan first, in a background call, then fast writes to disk. Each refinement records what triggered it and what came of it, so it can be rolled back. The results are not marginal. On ARC-AGI-3 the harness takes Opus 5 from 30% to 95.5% RHAE Best@1, against a reported human expert baseline of 95.4%. On OOLONG at 128k it scores 0.700 where pi-mono scores 0.420. On EmulatorBench it scores 0.208 against 0.000 — which in practice means it wrote working SEGA Genesis and Game Boy Color emulators in Rust with no reference code, and the baseline wrote none. The other direction The rest of the open-source landscape is not converging on this. If anything it is moving the other way, towards pulling the pieces further apart: Harness Shape Position Prime Agent one kernel, self-editing state collapse the seams pi minimal core, multi-provider loop stay small, compose upward OpenCode client/server, many frontends separate the inter