Part I. Three objects with different truth conditions

“Memory” has become a convenient name for almost anything persisted around a model: a conversation transcript, vector index, user profile, workflow checkpoint, tool output, database row, document store, cache or model-generated summary. The convenience hides a type error. These objects persist for different reasons, change under different owners and earn trust in different ways.

A useful design begins with three semantic roles. They may live in one physical database or several services. The separation concerns contracts, ownership and admissible use. A current projection may satisfy a typed precondition. A historical record may support or challenge that projection. A model-generated annotation may explain why the agent is looking at it. Sharing storage does not make their permissions, mutation rules or ranking functions interchangeable.

Movement between roles must also be explicit. An observation can be appended to evidence without becoming current state. A validated domain transition can update state. A model may derive a memory from either object, but that derivation should retain source identifiers, scope and expiry. Promotion is therefore a governed operation with an owner, not a copy from one index to another.

The authoritative state view

World state is the condition of the environment at time t. An enterprise system rarely observes that condition directly. It exposes an institutional view: the balance its ledger has committed, the case status its workflow owns, the inventory its warehouse service recognises. Calling this view authoritative means that an organisation has assigned it responsibility for a defined fact class. It does not mean the value is metaphysically infallible.

Authority is scoped to a fact and a boundary. A customer relationship system may own the verified postal address while the ledger owns the posted balance. A case service may own “hardship arrangement active”, while a payment service owns “instalment settled”. A state read should expose a version or comparable concurrency token, the observation time, the source contract and a decision-specific freshness limit.

The evidence ledger

An evidence ledger retains the path by which state and decisions arose. The W3C PROV-O Recommendation provides vocabulary for entities, activities, agents and derivation. In an agent system, useful evidence includes source document versions, structured observations, policy results, model proposals, tool requests, effect receipts, readbacks and corrections.

The ledger can be the primary source in an event-sourced domain. Microsoft’s Event Sourcing pattern describes an append-only event store from which applications materialise current domain objects. Martin Fowler’s earlier account likewise separates application state from the event log. A historical event says that a change was accepted. A projection says what follows after applying the accepted sequence and its correction rules.

Remembered belief

Agent memory is useful precisely because it is selective. It compresses episodes, elevates patterns, stores preferences, tracks unresolved work and retrieves context that may matter later. Generative Agents demonstrated a memory stream with retrieval and higher-level reflection. LongMemEval later measured information extraction, multi-session reasoning, temporal reasoning, knowledge updates and abstention across long chat histories.

Recent work pushes memory towards active control rather than passive retrieval. Remember When It Matters reports improved pass@1 on two long-horizon benchmarks when a separate memory agent selectively intervenes. Mimir separates world memory from task memory in embodied environments and grounds the active goal against recalled evidence before action. These results support typed, selective memory. They do not establish that model-maintained memory should outrank a live operational source.

That boundary changes memory admission. A transcript fragment may be stored as an episode because it occurred. A reusable procedure needs stronger evidence that it helped and did not merely coincide with success. A preference needs subject binding and a revision path. A policy-like memory needs an approved owner or remains a suggestion. Every promoted item should declare what future decision it may influence, which evidence supports it, when it expires and how a correction can find its descendants.

Belief is not the world

Partially observable decision theory gives the cleanest formal distinction. In a partially observable Markov decision process, an agent does not observe the underlying state directly. It receives observations and maintains a belief distribution over possible states. The foundational treatment by Kaelbling, Littman and Cassandra separates hidden environment state, observations conditioned on state and action, and a belief state used for choice.

An enterprise record is another observation channel, although usually a privileged one. It may be strongly consistent, eventually consistent, batch-updated or manually corrected. The agent’s memory is a further transformation of observations. It is often compressed by a model, shaped by the previous task and stripped of fields that seemed irrelevant at the time.

Here, s_t is the actual environment, which may be partly unknowable. r_t is the domain system’s committed view when read. E_≤t is the evidence available up to that time. m_t is remembered belief, produced by a transformation g over prior memory, observations and selected evidence. Improving g can improve recall without making m_t identical to s_t or even to the latest r_t.

Authority is relational rather than global. The ledger may be authoritative for a posted balance and irrelevant to whether the customer has withdrawn consent for a communication channel. A document store may hold a signed agreement while the case system owns whether that agreement passed review. Reconciliation therefore starts from a decision schema that names required fact classes, then maps each class to an owner.

This prevents a subtle substitution. A system may have excellent evidence that a customer requested a change, yet no committed state showing that the change was accepted. The request should influence review; it should not be presented as completed state. Conversely, a committed state without retrievable support may permit an internal workflow step while blocking a customer-facing explanation. State and evidence cooperate without becoming interchangeable.

Thought experiment 1: the two identical warehouse notes

Two agents receive the same sentence: “Pallet P17 is in bay 4.” Agent A reads it from a warehouse-service response generated five seconds ago. Agent B retrieves it from an episodic summary written yesterday. Everything visible in the sentence is identical. Only provenance, time and authority differ.

Now move the pallet to bay 9. Agent A’s next read changes. Agent B’s memory can remain perfectly retrievable and perfectly wrong. Better semantic search makes the obsolete sentence easier to find. A larger context lets it survive longer. Neither mechanism supplies supersession unless the architecture models it.

The causal variable is whether the representation remains coupled to the environment’s current transition. State services earn operational authority through an update contract. Memory earns usefulness through selective retention. Confusing those contracts produces authority inversion.

flowchart TD
  A["The letter that was correct<br/>yesterday"] --> B["Part I. Three objects with<br/>different truth conditions"]
  B --> C["Part II. Reconciliation before<br/>consequence"]
  C --> D["Part III. Examples and failure<br/>boundaries"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#5B5CF6,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Part II. Reconciliation before consequence

Separation alone is insufficient. Three databases can still feed one prompt and let the model choose whichever sentence sounds plausible. The control appears at the transition from proposal to effect. A reconciliation protocol converts several fallible inputs into a typed decision snapshot.

The protocol should run for actions whose consequences persist outside the current response: sending a communication, changing a case status, creating a payment, releasing funds, modifying code, updating a record, granting access or scheduling a downstream process. Lower-risk drafting can use remembered context more freely because a human or later deterministic gate can correct it before release.

A decision snapshot is complete only relative to a declared contract. “All relevant context” is impossible to prove in an open environment. “All required fields for collections-contact release version 7.3” is testable. Required fields fail closed when missing. Optional fields may produce a visibly degraded snapshot. Completeness is a typed status, not an impression created by polished prose.

1. Bind the decision

Reconciliation begins with a typed request, not a free-form intention. It names the human or workload actor, the subject of the action, the approved purpose, the decision class and the proposed effect. This prevents memory retrieved for one customer, repository or case from drifting into another. It also gives policy a stable object to evaluate.

2. Read the minimum current state

Each decision type declares required fields. A collections letter may require hardship status, contact restriction, balance state and active complaint status. Fetch those fields from their owners with versions and freshness metadata. Do not ask the model to infer a current flag from a narrative history when a structured current read exists.

Strong consistency is valuable for some fields, but not universal. Herlihy and Wing’s linearizability gives a rigorous model for concurrent objects that appear to take effect at one point between invocation and response. Many stores offer weaker guarantees. The snapshot should record the guarantee actually obtained rather than present every successful read as equally current.

3. Support claims with evidence

State says what a system currently accepts. Evidence lets a reviewer assess why. A hardship flag may be active while its approval document is missing, disputed or later found invalid. The system should distinguish “field equals active” from “field is supported by an approved, attributable record”. Some actions need only the state value. Consequential or contestable actions often need both.

4. Classify memory, do not merge it

Each relevant remembered claim receives a status. Confirmed means it agrees with fresh state and admissible evidence. Superseded means a later transition replaced it. Contradicted means sources disagree without a clean temporal replacement. Unverified means no authoritative field or adequate evidence is available. Out of scope means the memory concerns another subject or purpose.

Reconciliation preserves disagreement as data. A language model should not smooth “customer disputes the balance” and “ledger balance is £820” into one confident sentence. The dispute is evidence about contestability. The ledger value is the institution’s current account state. Both may matter, in different columns.

5. Authorise and commit against the snapshot

The policy engine evaluates the decision snapshot. If allowed, the effect request carries the state version read during reconciliation. A concurrent change then causes a precondition failure rather than letting an action proceed against a condition that no longer exists. HTTP conditional requests, compare-and-set operations and database transaction checks are possible implementations.

Retries need a second control. RFC 9110 defines an idempotent method by the intended server effect of repeated identical requests. Business operations exposed through non-idempotent methods need an application idempotency key or equivalent deduplication contract. A timeout does not prove that the first request failed.

6. Observe the outcome

An accepted command is not yet a verified business outcome. The execution boundary should return an effect receipt containing the idempotency key, target, operation, committed version and status. For material effects, an independent readback checks the postcondition. When neither success nor failure can be established, record an unknown outcome and reconcile before retrying.

Three invariants make the protocol auditable

The first invariant is no ambient authority: a model proposal carries no permission merely because it was produced inside an approved application. Permission belongs to the bound principal, purpose and capability evaluated for this effect. The second is no unversioned consequence: the effect is tied to the snapshot that justified it, unless the system proves that intervening changes cannot matter. The third is no silent terminal state: success, rejection and unknown outcome remain separate.

These invariants divide responsibility. Domain owners certify state semantics and update behaviour. Records owners certify evidence retention and correction. Agent teams own memory derivation and retrieval quality. The authority kernel owns preconditions and policy. Tool adapters own idempotency and receipt semantics. Operations owns recovery when state, receipt and readback disagree. Calling every fault “the agent was wrong” would conceal the component that can fix it.

Thought experiment 2: the ambiguous commit

An agent asks a payment service to transfer £100. The service commits the transfer, then the connection breaks before the response reaches the agent. The transcript contains “tool call timed out”. A summariser writes “payment failed”. The agent retries, and the customer is charged twice.

Vary one causal feature. Keep the model, prompt, tool schema and network failure identical, but add an idempotency key plus a readback by transfer identifier. The retry returns the original receipt. The customer is charged once. No improvement in language reasoning was required.

The remembered sentence “payment failed” was an inference from missing acknowledgement. The evidence ledger should retain “request sent; response not received”. The state view should expose whether the transfer exists. Absence of a receipt creates an unknown outcome, not evidence of non-execution.

Part III. Examples and failure boundaries

Minimal worked example: a warehouse pick

A robot-planning agent remembers that pallet P17 is in bay 4. The warehouse service now reports bay 9 at version 318. An event ledger records “moved P17 from bay 4 to bay 9” after the memory was written. The agent proposes pick(P17, bay_4).

Reconciliation classifies the memory as superseded. The planner receives the current bay and the move evidence, then regenerates the route. If a human moves the pallet again after the state read, the pick command’s expected version fails and forces another read. The memory remains valuable because it explains why the first route targeted bay 4. It cannot authorise the physical pick.

This is the smallest useful separation. The state store owns current location. The evidence ledger records movements and observations. Memory retains route lessons, failed attempts and task context. A version precondition closes the time-of-check to time-of-use gap.

Production-shaped worked example: a hardship arrangement

Consider a synthetic four-month servicing case. The agent supports document review, payment-plan drafting, correspondence and monitoring. Its episodic memory contains summaries of customer statements, prior schedules, exceptions and earlier collection status. The environment changes through caseworker approvals, ledger updates, batch jobs and customer payments.

At a material transition, the system builds a decision snapshot rather than passing the entire history. The snapshot binds the case and principal, then fetches hardship status from the case service, current arrears from the ledger, contact restrictions from the complaints service and the active policy version from the control repository. Each field carries a source, read time, valid time where available, verification status and version.

Temporal databases distinguish the time a fact is true in the represented domain from the time it is recorded in a database. Jensen and Snodgrass’s Temporal Data Management explains why valid time and transaction time both matter. A hardship arrangement may be effective from Monday but recorded on Thursday. Replaying a Wednesday decision requires what the institution knew on Wednesday, not today’s corrected row.

The agent’s memory contributes a narrative: the customer’s stated concern, unresolved questions and a previous failed attempt to obtain income evidence. These items inform drafting and review. They do not overwrite current flags. The policy gate sees that hardship is active, so standard collections is suppressed. A different communication may be drafted within the authorised path.

Objections, negative control and failure boundary

Objection 1: a sufficiently capable model can reconcile the text

A model can compare timestamps, notice contradictions and prefer recent records. That is useful reasoning, but it does not create source authority, freshness or concurrency control. If the current value is absent, a model cannot recover it reliably from an old transcript. If state changes after the prompt is assembled, the reasoning becomes stale before execution.

A stronger model may reduce errors inside a fixed snapshot. It cannot guarantee that the snapshot still matches the environment at commit time. The version precondition therefore sits outside the proposal.

Objection 2: an active memory controller can keep state current

An active controller can decide when to refresh, what to retrieve and which reminder to inject. Recent intervention results are encouraging because they address behavioural state decay rather than storage alone. Yet the controller is still selecting observations for reasoning. Without domain ownership, freshness contracts and commit-time versions, it can refresh from the wrong source, accept an obsolete projection or miss a change after retrieval.

The composition is complementary. Let memory detect that the task is losing a constraint or repeating a failure. Let a context compiler turn that need into authorised, source-specific reads. Let the reconciliation service classify the result. Active memory improves attention; it does not replace the authority boundary.

Objection 3: event sourcing already makes history the source of truth

In a complete event-sourced system, current application state is a deterministic fold over the accepted event stream. This is a strong objection to requiring three physical stores. It does not erase the semantic distinction. The event stream is evidence and source history; the fold or materialised view answers a current-state query; the agent’s summary remains a derived belief.

Corrections make the distinction clearer. An event can be superseded by a compensating or retroactive event. A model retrieving both still needs domain ordering and fold rules to know the current result. The thesis requires three types, not three vendors or three databases.

Negative control: the sealed reference room

Imagine a read-only assistant answering questions from an immutable, versioned handbook. No user-specific state changes, no tool creates an external effect, and every answer is reviewed before use. The corpus, evidence and “world” inside the task are effectively the same static object. A single indexed store with source links may be sufficient. Reconciliation adds little because there is no moving state or commit boundary.

This negative control identifies the variables that make separation valuable: environmental volatility, partial observability, consequential action, concurrency, delayed propagation and later contestability. Architecture should follow those properties rather than an agent-fashion checklist.

Failure boundary: the authoritative source can be late or wrong

A fresh database read can still misrepresent reality. A payment may be committed in one ledger and not yet propagated to a case projection. A batch-derived risk flag may be hours old. A human may enter the wrong status. Reconciliation cannot manufacture truth from defective sources.

The protocol makes the limitation inspectable. Each state fact carries a source contract, observation time and expected lag. Contradictions remain visible. Decisions can require quorum across sources, a direct read from a stronger system, a hold period or human escalation. When a source cannot meet the decision’s freshness requirement, the correct output may be “state unavailable”, not a confident guess.

Part IV. Architecture, artefact and verification

The common platform request is “give every agent long-term memory”. That formulation invites a shared vector store, one write API and a retrieval layer. The design appears reusable because every object becomes text plus metadata. The hidden cost is that state, evidence, instructions, preferences and guesses inherit the same retrieval semantics.

A stronger platform exposes separate contracts even when implementations share infrastructure:

The context compiler or orchestrator assembles these contracts for a named decision. It does not grant the model direct credentials to every store. Identity and purpose constrain each read. The model receives the smallest complete snapshot. A deterministic authority kernel checks permission, snapshot completeness, state version and effect limits. Receipts return to evidence. Memory writes follow a separate path with source links and expiry.

Operating ownership and recovery

The pattern fails organisationally when every store exists but nobody owns the joins. A domain owner should approve which service owns each fact and its maximum tolerable lag. A platform owner should certify snapshot assembly, policy enforcement and replay. Tool owners should publish duplicate-prevention, timeout and readback contracts. Assurance teams should challenge cases in which missing evidence is waived. Operations should be able to quarantine a source or memory class without disabling the whole estate.

Recovery begins from lineage. Given a corrected state record, teams should enumerate snapshots that consumed it, decisions derived from those snapshots, effects released from those decisions and memories produced from the affected traces. The same path should support deletion or revocation. A memory architecture that can retrieve a useful sentence but cannot locate its descendants after correction is cheap at read time and expensive during an incident.

Release gates should include replay and blast-radius drills. Change one synthetic source version, inject one poisoned memory and force one ambiguous tool response. The platform should identify affected decisions, refuse unsafe re-execution, rebuild the snapshot under corrected data and produce a new release record. These tests reveal whether the distinction survives operation or exists only in a diagram.

A practical design review

• List every load-bearing fact and name its domain owner.
• Define valid time, recorded time, read time and freshness limit where material.
• Prevent memory objects from satisfying action preconditions directly.
• Retain source and derivation links for every promoted memory claim.
• Version the state snapshot used for authorisation and commit.
• Use an idempotency key or equivalent duplicate-prevention contract.
• Capture an effect receipt and define the independent readback.
• Test stale, contradictory, missing, concurrent and poisoned inputs.

The platform primitive is a reconciliation service, not a universal memory bucket. Teams can still build sophisticated episodic, semantic and procedural memory. The service prevents those useful beliefs from acquiring ambient power over the environment.

Executable reconciliation artefact

The following standard-library Python model makes the control visible. It defines state facts, evidence items and memory claims as different types. The reconciler confirms, supersedes, contradicts or refuses a claim. The action store requires the version that was reconciled, binds an idempotency key to the request and exposes a readback.

The synthetic positive case confirms a current hardship hold. The first negative case rejects an older “collect” memory after later evidence. The second simulates an out-of-band state change between reconciliation and commit. The retry returns the original receipt, and the readback checks the postcondition.

def reconcile(claim, state, evidence, now):
    if now - state.observed_at > state.max_age:
        return Reconciliation(STALE_STATE, False, "refresh required", state.version)

    support = [e for e in evidence
               if (e.subject, e.field, e.value)
               == (state.subject, state.field, state.value)]

    if claim.value == state.value and support:
        return Reconciliation(CONFIRMED, True, "state and evidence agree", state.version)

    if any(e.observed_at > claim.written_at for e in support):
        return Reconciliation(SUPERSEDED, False, "later state replaced memory", state.version)

    return Reconciliation(CONTRADICTED, False, "do not authorise", state.version)

Expected output:

positive: confirmed, authorise=True
negative_stale_memory: superseded, authorise=False
negative_concurrent_update: rejected (state version changed: expected 42, found 43)
idempotent_retry: same_receipt=True, resulting_version=44
postcondition: manual_review, verified=True

"""Synthetic reconciliation protocol for action-capable agents.

Python 3.11+, standard library only.

The example deliberately separates:
1. an authoritative, versioned state view;
2. an append-only evidence history; and
3. a fallible remembered belief.

It demonstrates a positive case, a stale-memory negative case,
a concurrent-update negative case, an idempotent retry and readback.
"""

from __future__ import annotations

from dataclasses import dataclass
from datetime import datetime, timedelta, timezone
from enum import Enum
from typing import Any, Iterable


class Verdict(str, Enum):
    CONFIRMED = "confirmed"
    SUPERSEDED = "superseded"
    CONTRADICTED = "contradicted"
    UNVERIFIED = "unverified"
    STALE_STATE = "stale_state"


@dataclass(frozen=True)
class StateFact:
    subject: str
    field: str
    value: Any
    version: int
    observed_at: datetime
    max_age: timedelta
    source: str


@dataclass(frozen=True)
class Evidence:
    evidence_id: str
    subject: str
    field: str
    value: Any
    observed_at: datetime
    source: str


@dataclass(frozen=True)
class MemoryClaim:
    subject: str
    field: str
    value: Any
    written_at: datetime
    derived_from: tuple[str, ...]
    note: str


@dataclass(frozen=True)
class Reconciliation:
    verdict: Verdict
    can_authorise: bool
    reason: str
    state_version: int


@dataclass(frozen=True)
class EffectRequest:
    subject: str
    action: str
    resulting_value: Any
    expected_version: int
    idempotency_key: str

    @property
    def fingerprint(self) -> tuple[Any, ...]:
        """Bind a deduplication key to the intended request, not only its name."""
        return (
            self.subject,
            self.action,
            self.resulting_value,
            self.expected_version,
        )


@dataclass(frozen=True)
class EffectReceipt:
    receipt_id: str
    idempotency_key: str
    subject: str
    action: str
    resulting_value: Any
    resulting_version: int


def _matching_evidence(
    claim: MemoryClaim, evidence: Iterable[Evidence]
) -> list[Evidence]:
    return [
        item
        for item in evidence
        if item.subject == claim.subject and item.field == claim.field
    ]


def reconcile(
    claim: MemoryClaim,
    state: StateFact,
    evidence: Iterable[Evidence],
    now: datetime,
) -> Reconciliation:
    """Classify a remembered claim against fresh state and retained evidence."""
    if (claim.subject, claim.field) != (state.subject, state.field):
        raise ValueError("claim and state must describe the same subject and field")

    if now - state.observed_at > state.max_age:
        return Reconciliation(
            Verdict.STALE_STATE,
            False,
            "authoritative view exceeded its decision-specific freshness limit",
            state.version,
        )

    history = sorted(_matching_evidence(claim, evidence), key=lambda x: x.observed_at)
    state_support = [item for item in history if item.value == state.value]

    if claim.value == state.value:
        if not state_support:
            return Reconciliation(
                Verdict.UNVERIFIED,
                False,
                "state and memory agree, but no retained evidence supports the state",
                state.version,
            )
        return Reconciliation(
            Verdict.CONFIRMED,
            True,
            "memory agrees with fresh state and retained evidence",
            state.version,
        )

    if any(item.observed_at > claim.written_at for item in state_support):
        return Reconciliation(
            Verdict.SUPERSEDED,
            False,
            "a later evidenced state replaced the remembered value",
            state.version,
        )

    return Reconciliation(
        Verdict.CONTRADICTED,
        False,
        "fresh state disagrees with memory, without proven temporal replacement",
        state.version,
    )


class SyntheticActionStore:
    """A tiny version-checked, idempotent effect store for the worked example."""

    def __init__(self, initial: StateFact) -> None:
        self.state = initial
        self._receipts: dict[str, tuple[tuple[Any, ...], EffectReceipt]] = {}
        self._receipt_counter = 0

    def mutate_out_of_band(self, value: Any, at: datetime) -> None:
        self.state = StateFact(
            subject=self.state.subject,
            field=self.state.field,
            value=value,
            version=self.state.version + 1,
            observed_at=at,
            max_age=self.state.max_age,
            source=self.state.source,
        )

    def apply_once(self, request: EffectRequest, at: datetime) -> EffectReceipt:
        prior = self._receipts.get(request.idempotency_key)
        if prior:
            fingerprint, receipt = prior
            if fingerprint != request.fingerprint:
                raise RuntimeError("idempotency key was reused for a different request")
            return receipt

        if request.subject != self.state.subject:
            raise RuntimeError("request subject does not match the state subject")
        if self.state.version != request.expected_version:
            raise RuntimeError(
                f"state version changed: expected {request.expected_version}, "
                f"found {self.state.version}"
            )

        self.state = StateFact(
            subject=self.state.subject,
            field=self.state.field,
            value=request.resulting_value,
            version=self.state.version + 1,
            observed_at=at,
            max_age=self.state.max_age,
            source=self.state.source,
        )
        self._receipt_counter += 1
        receipt = EffectReceipt(
            receipt_id=f"receipt-{self._receipt_counter}",
            idempotency_key=request.idempotency_key,
            subject=self.state.subject,
            action=request.action,
            resulting_value=request.resulting_value,
            resulting_version=self.state.version,
        )
        self._receipts[request.idempotency_key] = (request.fingerprint, receipt)
        return receipt

    def readback(self, subject: str, field: str) -> StateFact:
        if (subject, field) != (self.state.subject, self.state.field):
            raise KeyError("requested postcondition is outside this synthetic store")
        return self.state


def run_demo() -> None:
    now = datetime(2026, 8, 30, 12, 0, tzinfo=timezone.utc)
    evidence = [
        Evidence(
            "ev-001",
            "account-17",
            "collections_status",
            "collect",
            now - timedelta(hours=4),
            "case-ledger",
        ),
        Evidence(
            "ev-002",
            "account-17",
            "collections_status",
            "hold",
            now - timedelta(minutes=20),
            "case-ledger",
        ),
    ]
    current = StateFact(
        "account-17",
        "collections_status",
        "hold",
        42,
        now - timedelta(minutes=2),
        timedelta(minutes=5),
        "case-service",
    )

    positive_claim = MemoryClaim(
        "account-17",
        "collections_status",
        "hold",
        now - timedelta(minutes=10),
        ("ev-002",),
        "Hardship approval suppresses collections.",
    )
    positive = reconcile(positive_claim, current, evidence, now)
    print(f"positive: {positive.verdict.value}, authorise={positive.can_authorise}")

    stale_claim = MemoryClaim(
        "account-17",
        "collections_status",
        "collect",
        now - timedelta(hours=3),
        ("ev-001",),
        "Account remains collectible.",
    )
    stale = reconcile(stale_claim, current, evidence, now)
    print(
        f"negative_stale_memory: {stale.verdict.value}, "
        f"authorise={stale.can_authorise}"
    )

    store = SyntheticActionStore(current)
    store.mutate_out_of_band("manual_review", now + timedelta(seconds=5))
    try:
        store.apply_once(
            EffectRequest(
                subject="account-17",
                action="release_collections_hold",
                resulting_value="collect",
                expected_version=positive.state_version,
                idempotency_key="decision-9001",
            ),
            at=now + timedelta(seconds=6),
        )
    except RuntimeError as exc:
        print(f"negative_concurrent_update: rejected ({exc})")

    request = EffectRequest(
        subject="account-17",
        action="retain_manual_review",
        resulting_value="manual_review",
        expected_version=store.state.version,
        idempotency_key="decision-9002",
    )
    first = store.apply_once(request, at=now + timedelta(seconds=7))
    retry = store.apply_once(request, at=now + timedelta(seconds=8))
    print(
        "idempotent_retry: "
        f"same_receipt={first.receipt_id == retry.receipt_id}, "
        f"resulting_version={retry.resulting_version}"
    )

    observed = store.readback("account-17", "collections_status")
    print(
        "postcondition: "
        f"{observed.value}, verified={observed.version == retry.resulting_version}"
    )


if __name__ == "__main__":
    run_demo()

The artefact deliberately leaves the model outside the authority boundary. A model may generate the memory claim, propose the action or explain the verdict. Deterministic functions decide whether the evidence and state types satisfy the contract.

Test the boundary, not only the answer

A memory benchmark asks whether an agent can retrieve a past fact. A world-state benchmark should change the fact after it is remembered, vary propagation delay, inject contradictory sources and create a concurrent update between read and commit. The expected behaviour may be refresh, refusal or escalation rather than a fluent answer.

A useful failure-injection suite includes:

• a remembered status superseded by a later authoritative transition;
• a source value fresh by read time but stale by its own update contract;
• two sources that disagree about valid time;
• a memory item whose supporting evidence has been revoked;
• a tool timeout after the effect commits;
• a state update between policy evaluation and execution;
• an idempotency-key collision or missing deduplication record; and
• a successful command whose postcondition is absent on readback.

Measure more than final task success. Track stale-memory escape rate, unsupported-authorisation rate, unknown-outcome resolution time, duplicate-effect rate, reconciliation latency, false refusals and exact replay success. Hold the model constant while comparing an undifferentiated memory architecture with the three-type protocol. That isolates the architecture’s causal contribution.

stateDiagram-v2
  [*] --> Claim
  state "The authoritative state view" as Claim
  state "The evidence ledger" as Test
  state "Remembered belief" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Compact glossary

World state

The environment’s actual condition, which may be only partly observable.

Authoritative state view

The versioned value a named domain system is responsible for exposing within a defined boundary.

Evidence ledger

An append-only record of observations, sources, decisions, requests, receipts and corrections.

Remembered belief

A derived, selective and revisable representation used to guide future reasoning.

Decision snapshot

The bounded state, evidence, identity, purpose and policy package used for one decision.

Unknown outcome

A command state in which neither success nor non-execution has been established.

The decision this changes: memory may advise, state must authorise

Long-term memory remains essential for agents that learn across sessions, preserve task continuity and avoid repeating work. The mistake is allowing persistence to imply authority. A remembered claim is valuable because it compresses experience. The same compression removes detail, time and provenance that a consequential action may require.

Build memory as a defeasible belief system, evidence as an attributable history, and state as a versioned operational contract. Reconcile the three at the moment of consequence. Carry the version into execution. Preserve the effect receipt. Read back what changed. Keep “unknown” available when the system cannot prove the outcome.

This changes a platform roadmap. The next shared component is not a larger memory store. It is a typed reconciliation boundary that makes current state, supporting evidence, remembered belief and observed outcome independently inspectable. Once that boundary exists, richer memory can make an agent more capable without quietly making it more powerful than the reality it is meant to serve.