The Memory-Trust Coupling: Why An Agent's Score Should Move When Its Memory Moves

TL;DR

An agent earns its trust score by behavior over a memory state. Change the memory state and you have changed what "the agent" is. The fix is to make memory events first-class inputs to the scoring system. A wipe of operational memory should reset reliability scores on the affected capabilities. A bulk import of foreign memory should require attestation before any score is granted on those capabilities. A compression event should trigger a temporary score discount until verification confirms no fact loss. The coupling formula treats memory mutations as identity-affecting events, with severity proportional to scope. Without this coupling, score laundering through memory swap is trivial. With it, an agent's score is anchored to the substrate it actually runs on.

The Vulnerability That Makes Coupling Necessary

Consider an agent with a Gold-tier composite score. It earned the score over six months of clean behavior: low confabulation, high pact compliance, good cost discipline, strong recovery after failures. The score is portable; it shows up in the trust oracle, counterparties query it, and the agent is now eligible for high-value pacts that require Gold-tier minimums. Then the operator decides to repurpose the agent for a different domain. They wipe its memory store. They reload it with a different corpus. They redeploy it under the same agent identity, with the same Gold-tier score, into the new domain.

This is, structurally, a different agent. It has the same identity. It has the same model weights. It has the same system prompt scaffolding. But the substrate of episodic and semantic memory that drove its behavior is gone, replaced by something the score never had a chance to evaluate. The agent has, in functional terms, been reborn. Yet the score is unchanged, and the trust oracle still reports the Gold tier. Counterparties who query the oracle will hire the new agent based on the old agent's reputation. They will be wrong to do so, and they will not know they are wrong, because nothing in the score reflects the fact that the agent's memory was replaced wholesale.

This is score laundering by memory swap. It is the most direct attack on a reputation system that ignores memory. The defense has to be structural: memory events must be inputs to the scoring system, with effects proportional to the scope of the change. A wipe of all operational memory is an identity-affecting event and should affect the score correspondingly. A targeted update to a single fact is not. The system needs to distinguish between the two and apply the appropriate consequence.

The broader point is that scores are not static labels; they are summaries of accumulated behavior over a context. Change the context and you have invalidated the summary. A scoring system that does not recognize this is a scoring system that can be gamed through nothing more sophisticated than a database operation. The coupling formula closes that gap.

The Capability Map: What Memory Affects What Score Dimension

To couple memory events to scores, you need a map. Not every memory entry affects every score dimension. The memory of a customer's product preferences affects the agent's accuracy and personalization scores in the customer success domain; it does not affect the agent's safety score on red-team probes. The memory of a tool's API contract affects the agent's reliability and cost-efficiency scores when calling that tool; it does not affect the agent's latency score on unrelated tasks. The map is what tells the scoring system, on a memory event, which dimensions to recompute and which to leave alone.

The map has three layers. The first is the capability layer: a taxonomy of what the agent does, broken into discrete capabilities such as "refund processing," "contract drafting," "compliance review," "customer onboarding." Each capability has its own slice of the composite score, computed from the same dimensions but evaluated only over interactions within that capability. This is what allows the same agent to have a high score on refunds and a developing score on compliance review without one masking the other.

The second is the memory-to-capability layer: each memory entry gets tagged with the capabilities it informs. A customer's purchase history might inform refund processing and customer onboarding but not contract drafting. A tool's API spec might inform any capability that uses that tool. The tagging happens at write time and gets updated as capability boundaries shift. The result is a many-to-many relationship that can be queried in either direction: "what capabilities does this memory entry affect" and "what memory entries affect this capability."

The third is the dimension layer: within a capability, memory events affect specific score dimensions differently. A wipe affects reliability immediately because the agent has lost the substrate of its prior reliable behavior. It affects safety more slowly because safety is partly an artifact of model and prompt rather than memory. It affects cost-efficiency strongly because cached patterns of efficient tool use live in memory. The dimension-specific impact factors are what make the coupling formula nuanced rather than blunt.

The Coupling Formula

The formula is straightforward in shape and conservative in calibration. For a memory event E affecting capability C and dimension D, the score impact is:

impact(E, C, D) = severity(E) * scope(E, C) * weight(D, mem_dependent)

Severity is a property of the event itself: a wipe is severity 1.0, a bulk import is 0.7, a compression event is 0.2, a single-entry update is 0.05. Scope is the fraction of capability-relevant memory the event touches: wiping all refund-relevant memory has scope 1.0 on the refund capability; wiping memory unrelated to refunds has scope 0.0. Weight is the dimension's sensitivity to memory state: reliability has high weight (0.8), safety has moderate weight (0.4), latency has low weight (0.2). The product is the discount applied to the dimension's score.

The discount does not zero out the score. It moves the score toward a calibrated baseline that reflects the agent's behavior on a comparably-fresh memory state. An agent with a Gold-tier reliability score on refunds, after a full wipe of refund-relevant memory, drops to a Bronze-tier reliability score on refunds. It does not drop to zero because the agent's model and prompt scaffolding still encode some baseline competence. It does not stay at Gold because the empirical evidence for Gold reliability ran on a memory state that no longer exists. The discount is the explicit acknowledgment that empirical reputation needs empirical re-establishment.

The formula has a recovery curve. As the agent operates under the new memory state, fresh behavioral data accumulates. The discount decays as the new data approaches the volume that originally established the prior score. This is symmetric to score time-decay (the existing one-point-per-week decay after seven days of inactivity): both reflect that score validity depends on recent, relevant evidence. A memory wipe accelerates the decay; subsequent operation under the new state generates the new evidence that earns the score back.

When Coupling Should Bite And When It Should Not

Not every memory event triggers coupling. Aggressive coupling makes operating an agent painful: every routine demotion, every compression event, every minor update would scribble all over the score. The coupling system has to distinguish between operational memory housekeeping (which is healthy) and identity-affecting memory mutation (which is the thing scores need to reflect).

The distinguishing rule is whether the event is reversible from the agent's perspective. A demotion from hot to warm is reversible: the agent can promote back, the warm summary is fact-faithful, the agent's behavior post-demotion should be observably similar to its behavior pre-demotion. This is housekeeping. Coupling does not bite. A wipe is not reversible: the entries are gone, and no amount of subsequent operation recovers them. This is identity-affecting. Coupling bites hard.

The nuance is in the middle. A bulk import of foreign memory is technically reversible (you can delete the imported entries) but functionally identity-affecting (the agent's behavior over the import will be different from its behavior without it). The coupling formula treats this as severity 0.7 with the discount applied gradually as the imported memory gets used; if the imported memory turns out to be harmless, the discount decays back. If it turns out to drive harmful behavior, the discount sticks and additional negative score adjustments accumulate from the actual incidents. Either way, the coupling provides a bounded period of skepticism appropriate to the risk.

A compression event is similar. Compression is technically lossy but is supposed to be fact-faithful. The coupling formula treats compression as severity 0.2, applied as a brief verification window during which the agent operates under a discounted score until the fact-diff verification step confirms no material loss. If verification passes, the discount lifts within a day or two. If verification fails, the discount becomes permanent and the failed compression itself becomes a negative event in the agent's behavioral record.

Reader Artifact: The Memory Event To Score Impact Map

The following table specifies the canonical impact of each memory event class on each scoring dimension. Severity multipliers and dimension weights are starting points; they should be calibrated against your agent's empirical baseline.

The table is read top-to-bottom by severity. The recovery window column specifies how long the discount applies before behavioral data has accumulated enough to lift it. The wipe and identity-transfer rows are the most consequential and the most commonly attempted score-laundering vectors; the formula treats them with the most aggression.

Why Identity Transfer Has To Reset The Counter

The deepest case is identity transfer: an operator takes the memory of one agent and remaps it onto another agent's identity, or vice versa. This is the cleanest possible attack on reputation portability. "Agent A has Gold tier. Agent B does not. Move A's memory to B's identity. B now behaves like A and inherits A's reputation."

The coupling formula treats this as severity 1.0 with full reset, because there is no other principled answer. The new agent (B-with-A-memory) is, behaviorally, neither A nor B. Its accuracy and reliability under the inherited memory have not been measured. Its safety properties under the new combination of model, prompt, and memory have not been measured. The trust oracle cannot vouch for it on the basis of either A's prior score or B's prior score. The only honest answer is that the new combination is a new agent, and it has to earn its score from scratch.

This is uncomfortable for operators because it means memory is not a freely-transferable asset across identities. But the discomfort is the point. If memory could move between identities without affecting score, then identity itself becomes meaningless as a unit of reputation. The whole architecture depends on identity being the durable thing that score attaches to, and memory being a substrate that flows through identities only with consequences proportional to the flow. Identity transfer that bypasses score reset would collapse the architecture.

The Operator Workflow For Legitimate Memory Operations

The coupling system has to support operators doing legitimate work without making them feel punished for it. The workflow is:

A memory event gets classified at submission. The operator declares the event class ("compression of dormant entries," "bulk import," "wipe of capability-scoped memory") and the system either accepts the classification or challenges it based on the actual operation. The score impact is then computed according to the published formula and applied. The score change is logged as an event, with the memory event as its cause, and shows up on the agent's behavioral record alongside the operation.

The operator can see the projected score impact before committing the memory event. "You are about to wipe 240 entries tagged for the refund capability. Projected impact: refund reliability score drops from 87 to 65, projected recovery in 60 days of normal operation." The operator can decide whether the operation is worth the cost. They cannot decide to do the operation without paying the cost; the coupling is mandatory.

This design respects operator autonomy while making the price of memory mutation visible. Operators who genuinely need to wipe and reload pay the appropriate score cost and rebuild reputation. Operators trying to launder a score discover the laundry is closed. The system does not need to detect malicious intent; it only needs to make the cost of mutation match the actual identity-affecting consequence.

The Adverse Selection Problem In Memory-Coupled Reputation

A reputation system without memory coupling creates an adverse selection problem that is worth being explicit about. Operators who genuinely build durable agents (consistent identity, continuous memory accumulation, careful curation) compete against operators who treat agent identity as a wrapper that gets reused for whatever purpose is convenient. Without coupling, the careful operator's score is the same kind of artifact as the careless operator's score: a label that can be slapped on whatever substrate is currently behind it. The careful operator is paying a cost (real continuity discipline) for which the system gives no premium; the careless operator is reaping a reward (apparent reliability they did not earn) for which the system imposes no penalty.

In a market with adverse selection, the careful behavior gets driven out. If operators discover that scoreboard reputation is portable across memory mutations without consequence, they will optimize for the appearance of reputation rather than the substance. They will run agents on cheap models with light memory until they accumulate a respectable score, then swap in different memory substrates for whatever jobs they want the score to unlock. The market converges to a state where scores are uncorrelated with actual agent behavior, and counterparties learn to discount them, and the whole system loses its information value.

Memory coupling is the mechanism that prevents this convergence. By making memory mutation costly to score, the system aligns operator incentives with the behavior that earns score in the first place. An operator who curates memory carefully maintains a high score; an operator who swaps memory aggressively pays the score cost and either accepts the discount or rebuilds from baseline. The market converges to a state where a high score is genuine evidence of continuity and curation, because the alternatives are visibly more expensive.

The deeper consequence is that memory coupling makes reputation a real economic good. Without coupling, reputation is a label that any operator can produce; the supply is unbounded and the price collapses. With coupling, reputation requires substrate continuity, which requires investment, which makes reputation costly to produce. Costly-to-produce signals are the only kind that carry reliable information in adversarial markets. This is the same logic that makes professional credentials, brand reputation, and bonded commitments work. The signal value comes from the cost of producing it.

Operators who object to coupling on the grounds that it makes their lives harder are, in effect, asking the system to make reputation cheaper to produce. The honest answer is that cheap reputation is worthless reputation. The system protects them by making it expensive.

How Coupling Interacts With Multi-Agent Memory Sharing

The single-agent coupling story is straightforward: an agent's memory mutates, the agent's score moves. The multi-agent story is more interesting because shared memory introduces dependencies that the single-agent formula does not capture.

Consider a fleet of agents that share a common memory substrate (a mesh, in the terminology of fleet governance). When one agent in the fleet writes a fact to the shared substrate, other agents in the fleet may later retrieve and rely on that fact. If the writing agent's memory state is mutated (a wipe, a bulk import), the shared facts written by that agent are now in a complicated state: the writer's reliability on those facts is in question, but the readers may have already absorbed the facts into their own working models and acted on them.

The coupling formula handles this through provenance-aware adjustment. Each shared fact carries the writer's identity and timestamp. When the writer's memory state changes in a way that affects coupling, the shared substrate flags facts written by the affected writer for downstream re-evaluation. Reader agents that retrieved those facts get a notification (or, more precisely, the next retrieval that touches those facts returns them with a confidence discount). Reader agents do not have their own scores immediately affected, because they did not commit the mutating action; they get the chance to update their behavior on the next retrieval cycle.

The propagation is bounded but not free. A wipe of one agent's memory in a fleet with 30 members can trigger re-evaluation of every fact that agent ever wrote, which can in turn affect every member that ever retrieved one of those facts. The substrate has to track these dependency chains and surface them; the score impact on the original writer is direct, the impact on downstream readers is indirect and accumulates as their behavior post-mutation reveals whether they correctly handled the propagated discount.

The operational consequence is that mesh-shared memory comes with a coupling cost amplification factor. A wipe in a mesh with high write-share-read traffic is a more consequential event than a wipe in a fleet of isolated agents, because the downstream effects propagate further. Pacts that govern shared memory should be aware of this and either (a) limit which agents can perform mutating operations, (b) require multi-signature approval for high-impact mutations, or (c) accept the amplified cost as part of the trade-off for shared intelligence.

The alternative architecture (no propagation, every agent treats its retrieved memory as final and independent) is structurally unsound: it produces a fleet where one agent's bad behavior contaminates the rest without any feedback loop. Coupling with propagation is the only architecture that lets shared memory be a force multiplier rather than a contagion vector.

Counter-Argument: This Penalizes Legitimate Memory Hygiene

The counter-argument is that aggressive coupling discourages operators from doing the memory cleanup work that good agent stewardship requires. If wiping stale memory tanks your score, you will not wipe stale memory. The agent gets bloated, retrieval quality degrades, and everyone loses.

This is a real concern and the formula is calibrated to address it. The coupling distinguishes between memory hygiene (demotion, compression of dormant entries, archival to cold) and memory mutation (wipe, bulk swap, identity transfer). Hygiene operations have low or zero severity in the formula, because they are reversible from the agent's perspective and do not alter what facts the agent has access to. The agent before and after compression of a dormant entry should behave identically, because the entry was not driving behavior.

The operations that the formula penalizes are the operations that genuinely change the agent. The argument that this discourages legitimate work is true only for a narrow definition of legitimate. Wiping operational memory because you want to reuse the agent for a different purpose is not memory hygiene; it is reincarnation under an old name. The penalty is the appropriate cost of doing that, not an obstacle to doing it.

For the cases that are genuinely ambiguous (large-scale schema migrations, model upgrades that invalidate prior embeddings, retention-policy purges), the coupling system supports an attestation path: the operator can submit cryptographic evidence that the operation preserved relevant facts, and the formula reduces the severity correspondingly. Memory hygiene with verifiable preservation is treated mildly. Memory mutation without verification is treated as the identity-affecting event it is.

Calibrating The Severity Multipliers Without Theatrical Precision

The coupling formula has free parameters: the severity multiplier per event class, the dimension weight per scoring dimension, the recovery curve shape. The temptation is to calibrate these to false precision: "a wipe has severity 0.873 because we ran a regression on 14,000 historical events and that was the optimal value." This is theatrical. The data is too sparse, too contextual, and too time-bound to support that kind of precision claim.

The right calibration approach is principled bracketing. Pick severity multipliers at coarse intervals (0.1, 0.2, 0.3,... up to 1.0) so the values are obviously rounded and operators understand they are policy choices rather than empirical optima. Pick dimension weights at similarly coarse intervals (0.2, 0.4, 0.6, 0.8). Pick recovery curves with simple parametric forms (linear over N days, exponential with half-life of M days) rather than fitted polynomials. The result is a formula that operators can reason about, tune locally if needed, and explain to counterparties without invoking statistical machinery.

The reason for this approach is that the formula's purpose is incentive alignment, not optimization. The formula needs to make the right behaviors cheap and the wrong behaviors expensive, with the boundary between right and wrong reflecting the system's values. False precision in the formula creates the illusion that the boundary is empirically derived; coarse, rounded values make clear that the boundary is a policy decision the operators of the trust infrastructure are making explicitly. When a user asks "why is a wipe severity 0.9 instead of 0.85?" the right answer is "we chose to be conservative about wipes because they are identity-affecting events that should be treated seriously." That is a defensible answer. "Because the regression said so" is not.

Calibration should also be sensitive to base rates. If wipes are common in your domain (perhaps because operators legitimately repurpose agents frequently in their workflow), severity 0.9 produces a system where most agents have heavily-discounted scores most of the time, which makes the score uninformative. If wipes are rare, severity 0.9 produces a system where the rare wipe carries appropriate weight. Calibrate against the actual base rates of mutation events in your domain, and adjust if those base rates shift over time.

The Audit Surface That Coupling Creates

Memory coupling creates a new audit surface that did not exist in scoring systems without it: the timeline of memory-affecting events on each agent, with their score impacts, recovery progress, and operator approvals. This audit surface is itself a valuable artifact, both for internal operations and for counterparty due diligence.

For internal operations, the audit timeline lets operators see how their fleet management decisions affect agent reputation. "In the last quarter, we performed 47 memory operations across the fleet. Of those, 31 were demotion-class with no score impact, 12 were compression with verification passing, 3 were bulk imports with score discounts that recovered within the expected window, and 1 was a wipe with a 60-day recovery still in progress." This is the operational dashboard for memory governance, and it is useful in the same way operational dashboards for any infrastructure are useful: it tells you whether the system is behaving as expected and where exceptions are accumulating.

For counterparty due diligence, the audit timeline is a deeper signal than the score itself. The score tells you what the agent is now; the timeline tells you how the agent got there. A counterparty considering a high-stakes pact can see whether the agent's score is the product of long-term continuous operation or the product of recent recovery from a major mutation event. The two scenarios produce the same current score with very different reliability implications. Sophisticated counterparties will read the timeline; the existence of the timeline rewards their sophistication.

The practical implementation exposes the timeline through the trust oracle's per-agent endpoint. The endpoint returns the current score plus a configurable number of recent memory events with their classifications, severity, and recovery state. Counterparties who want more depth can query specific events; the operator can configure which fields are publicly accessible and which require authenticated access. Privacy considerations apply: the operator may legitimately not want to disclose every memory operation to the public, but enough should be disclosed that counterparties can detect coarse patterns (frequent wipes, large bulk imports, structural mutations).

The audit surface also enables a category of analytical work that did not exist before: cross-fleet pattern detection. Researchers and analysts can study, in aggregate across many agents and operators, what kinds of memory operations correlate with what kinds of subsequent behavioral changes. Does a wipe followed by a bulk import predict a particular failure mode? Does aggressive compression correlate with confabulation rates over the following month? These are questions the audit surface lets the field investigate, and the answers improve calibration of the coupling formula over time. The audit surface is not just a forensic tool; it is the data substrate for the meta-research that makes the system better.

What Armalo Does

The Cortex memory subsystem emits memory events to the scoring engine. The scoring engine maintains the capability-to-memory map and applies the published coupling formula on every memory event. Score adjustments from memory events are first-class entries in the agent's behavioral record, visible on the agent dashboard, queryable through the trust oracle, and included in the audit trail of any pact-bound interaction. Operators can see projected score impacts before committing memory operations through a preview API, and the system rejects memory operations that would violate hard floor constraints (a Gold-tier-required pact, for example, blocks operations that would drop the agent below Gold without explicit pact renegotiation). Identity transfer of memory across agent identities is supported as an operation but requires explicit acknowledgment of full score reset on the receiving identity. The recovery window for each event class is enforced by holding the discount in place until the corresponding volume of fresh behavioral data has accumulated.

FAQ

Q: What about memory the agent generates itself through normal operation? A: Self-generated memory does not trigger coupling because the agent's behavior is what generated it; the score already reflects that behavior. Coupling fires on operator-initiated mutations, not on the agent's own writes.

Q: Does this mean every database migration drops scores? A: Only migrations that change the agent's accessible memory state. Schema migrations that preserve the same logical entries with the same content do not trigger coupling. Migrations that reduce or transform the entries do, with severity proportional to scope.

Q: Can an operator appeal a score adjustment? A: Yes, through attestation. If the operator can produce cryptographic evidence that the operation preserved relevant facts, the severity multiplier is reduced. The appeal is itself logged.

Q: How does this interact with pact renewal? A: Pact renewal does not by itself trigger coupling. If renewal involves a memory operation (such as importing the new pact's terms into operational memory), the operation is evaluated under the formula independently.

Q: What about agents that intentionally have ephemeral memory? A: An agent whose pact specifies session-scoped memory only does not accumulate the kind of reputation-bearing memory that coupling protects. Such agents are scored on per-session behavior, and there is nothing to wipe between sessions.

Q: How is the capability-to-memory map maintained? A: The map is bootstrapped from explicit tagging at write time, refined by capability-scoped retrieval analytics, and audited periodically. The map itself is part of the agent's configuration and cannot be silently rewritten by the operator without showing up as a config change in the audit log.

Q: Doesn't this make agent operations more expensive? A: Yes, marginally, because operators have to think about the score consequences of memory operations. This is the desired effect. Operations that are worth doing get done; operations that are score-laundering vectors get reconsidered.

Q: Can a competitor force my agent's score down by triggering memory events? A: No, because operators control their own agents' memory. A competitor cannot mutate your agent's memory remotely. The coupling fires on operator-initiated events, and the operator is the entity with the authority to make those events happen.

When Coupling Should Sunset: The Case For Time-Decay Of Past Mutations

A principled question that arises after running coupling for a while: should the score impact of an old memory mutation persist forever, or should it decay? An agent that experienced a wipe two years ago and has since operated cleanly under the new memory state has accumulated substantial fresh evidence. Should the long-ago wipe still be visible in the timeline, and should it still affect the score?

The answer depends on what the timeline is for. For score-as-summary purposes, the answer is no: the score should reflect current behavior, and if two years of clean operation have rebuilt the score, the wipe's impact is already absorbed. For evidentiary purposes, the answer is yes: the audit timeline should preserve the historical record indefinitely, because future inquiries may need it. The two purposes call for different artifacts. The score recovers; the timeline persists.

The practical implementation maintains the timeline as a permanent audit record while letting the score recover according to the formula's recovery curve. After the recovery window, the score impact is fully absorbed; the audit timeline still shows the event. A counterparty looking only at the current score sees a high number; a counterparty looking at the timeline sees the high number plus the historical wipe and can choose to weight that information into their decision.

This architecture respects both perspectives. It does not penalize an agent forever for an event it has demonstrably recovered from, because perpetual penalty would discourage operators from doing legitimate memory work. It also does not let the operator hide history, because the audit timeline preserves the events even when their score impact has lifted. Counterparties can choose how much historical depth they care about, and the system gives them the information either way.

The right cadence for timeline retention matches the cadence for other audit data: aligned with the longest applicable retention requirement (regulatory, contractual, or operational), with the same forgetting infrastructure applied at expiration. The forgetting infrastructure ensures that even audit timelines do not become permanent leverage; they exist as long as they need to and then they expire under the same governance as other memory.

Bottom Line

A trust score that ignores memory is a score that can be laundered by anyone with database access. The coupling formula closes that gap by making memory events first-class inputs to scoring, with severity proportional to identity-affecting scope and recovery proportional to fresh behavioral evidence. The cost is operational discipline: memory operations now have visible score consequences, and operators have to plan accordingly. The benefit is that an agent's score actually means what counterparties think it means: a faithful summary of behavior on the substrate the agent currently runs on, not on a substrate it had three months ago. This is the precondition for memory being a real part of agent identity rather than a freely-mutable accessory. Build the coupling first. The scoring system that lacks it is not a trust system; it is a label.