https://cosmoplot.io/

https://preview.redd.it/zagvlzvj5cbh1.png?width=1868&format=png&auto=webp&s=c02f42e834aaccf75a091347ad744f5abb0f3eca

https://cosmoplot.io/

WIP in progress; but very cool way to explore the massive amount of information we have collected

Designed with these core tenants

- Science engine is deterministic

- Rendering is downstream of a typed appearance model

- Observed, derived, inferred, proxy, and artistic values stay distinct

- Provenance should be visible near every claim

- Visuals are evidence-constrained interpretation, not observation 

https://preview.redd.it/cz2pswx83cbh1.png?width=1868&format=png&auto=webp&s=29825f14904a773f8317cc4712f48526732c47c3

https://preview.redd.it/9iglpdwnobbh1.png?width=1672&format=png&auto=webp&s=bcfeb5fd9888e4de66ee0bc4657a752b28df2ccf

Agent traffic has a strange property: almost every byte is a repeat. Two AI systems exchanging MCP tool calls, A2A task updates, or OpenAI-style function calls send jsonrpc, method, params, trace_id, task_id, and the same schema fragments thousands of times per minute. The values change. The structure barely does.

AURA is an experimental, protocol-aware data-movement toolkit built around that observation. Its main path is AIWire: a negotiated structure side channel that lets two peers agree on message structure once, then move compact deltas over ordinary TCP, WebSocket, HTTP, or broker links instead of re-sending whole JSON frames.

The steady state AIWire aims for is not "send a whole frame more cheaply." It is "handshake the structure, then send the change."

Why stateless compression leaves so much on the table

The obvious fix for verbose JSON is gzip or zlib per message. That works, but it has two structural problems for agent traffic:

1. Every frame pays setup cost. Stateless compression treats each message as unrelated text and rediscovers the same patterns every time.
2. History is thrown away. Frame 4,000 of a session looks almost identical to frame 3,999, but a per-frame codec cannot use that.

AIWire keeps a live compression stream per direction across the whole session, seeds it with a static dictionary of common AI protocol fields, and lets peers negotiate session-specific templates on top. After the handshake, the hot path carries only what changed against structure both sides already share.

The three-lane model

The part of the design I find most interesting is that AIWire refuses to treat a connection as one undifferentiated pipe. It splits AI traffic into three logical lanes over whatever transport you already have:

The semantic/message lane carries the actual agent messages: MCP tool calls, JSON-RPC requests and responses, A2A task and artifact updates, traces, handoffs, results. This is the lane the dictionary, session templates, and stateful delta stream optimize.

The control/session lane carries the machinery that keeps the semantic lane safe: handshakes, template discovery, dictionary diffs, ACK/NACK, resume negotiation, heartbeats, and reset signals. The spec requires that control messages stay decodable without inflating the semantic stream. If the compressed stream is resyncing or has failed, you can still read the control lane and recover. Your ops path never depends on the health of the compression state it is trying to fix.

The blob descriptor lane handles the things that should never go through a structured-message codec at all: media, tensor chunks, model artifacts, log archives. The bytes move over a normal blob or file transport. AIWire carries the metadata: content type, SHA-256 digests, chunk manifests, route, priority, and transfer status. A receiver can schedule, verify, and account for a 2 GB artifact without ever pulling it through the message path, and a semantic-lane reset does not invalidate a completed digest-verified transfer.

The separation is a safety argument as much as a performance one. Under congestion, control messages get priority over bulk bytes. Blob descriptors are forbidden from mutating the session dictionary. Each lane fails independently.

Fail closed, by contract

Shared compression state is dangerous if the two sides ever disagree, so the AIWire v1 spec is aggressive about verification:

• The handshake compares static dictionary SHA-256 and byte size, template hashes and counts, and zlib parameters. Any mismatch fails closed or falls back to raw/zlib only if the application explicitly allowed it.
• Session dictionary growth is append-only, epoch-numbered, and proposed through diffs that carry previous and next state hashes, a fresh nonce, a diff identity hash, and an optional HMAC-SHA256 tag. A sender may not encode against new structure until the matching ACK is verified.
• Resume handshakes let a client reconnect against a cached dictionary state, but only if the receiver actually holds one of the offered state hashes.
• Any inflate error, hash mismatch, or ordering violation means stop, rehandshake, or fall back. The spec's phrasing: peers must not continue sending compact deltas against uncertain structure.

The metric is exchanges, not ratio

AURA's docs are explicit that compression ratio alone is the wrong scoreboard. The question is how many verified semantic exchanges fit through a link once bandwidth, p95 latency, and codec CPU are accounted for.

On a modeled 10 Mbps link with protocol-shaped request/response traffic (native C++ backend, 2026-07-04):

A live TCP replay of the committed public session corpus, with 64 concurrent logical agents and SHA-256 verification of every response, pushed further: AIWire averaged 45.6 bytes per exchange for a 24x bandwidth gain, and the combined AIToken + AIWire path hit 32.3 bytes per exchange, a 34x gain with 97.1% of bytes saved. At that point the modeled link was no longer the bottleneck; the runtime could not keep enough requests in flight to fill the headroom.

That last detail is the honest core of the project. Smaller frames only matter if your system has enough concurrent work to use the room they create. AURA ships the extrapolation tooling to reason about exactly that: given a bandwidth, a p95 latency, and a per-agent window, how many agents does it take to saturate the link.

Where it fits

AURA is for situations where you control both ends of the link and the traffic has repeated structure:

• Multi-agent request/response loops. Orchestrators, workers, and reviewers exchanging thousands of small task, status, and result messages.
• MCP and JSON-RPC tool traffic. Tool calls and tool results are the canonical case of stable structure with changing values.
• Local AI clusters and edge links. The repo's LAN benchmark runs a Mac against a Z6 workstation and Jetson Nano-class boards; a bandwidth-limited edge mesh is exactly where an 86 to 97% byte reduction converts into headroom for telemetry, media, and retries.
• Structured logs and traces. Repeated field names, session-stable shapes, high volume.
• Binary payload routing. Agents that need to schedule, verify, and track opaque artifacts by digest without moving the bytes through the message path.

What it is not

The README is unusually direct about limits, and it is worth repeating them. AURA is not a drop-in replacement for gzip, zstd, TLS, or a message broker. It does not define transport security, retries, or backpressure; those stay at the transport layer. The stateful stream means frames cannot be reordered or dropped inside a session, so lossy transports need their own recovery layer. And it is not production-ready: it is a prototyping and measurement toolkit with a working Python path, a native C++ backend, deterministic public fixtures, and reproducible benchmark harnesses.

That fixture corpus deserves a mention. The repo commits a synthetic public session corpus covering MCP, A2A, OpenAI Responses, traces, handoffs, and memory writes, wrapped in the full side-channel lifecycle: forced handshake, template update, authenticated dictionary diff, ACK, and resume. Anyone can replay the exact benchmark and check the numbers.

Trying it

from aura_compression import AIWireSessionEncoder, AIWireSessionDecoder

message = {
    "protocol": "mcp",
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {"name": "read_file", "arguments": {"uri": "repo://service/path.py"}},
}

with AIWireSessionEncoder(level=3) as encoder, AIWireSessionDecoder() as decoder:
    delta = encoder.compress_message(message)
    restored = decoder.decompress_message(delta)

assert restored == message

The repo includes transport examples for length-prefixed TCP, WebSocket, HTTP with Server-Sent Events, and a local broker, plus the full benchmark harness used for the numbers above.

Agent-to-agent traffic is growing faster than the links it runs on, and most of it is the same structure sent again and again. AURA's bet is that the fix belongs in a negotiated session protocol, not a per-frame codec. The three-lane model, the fail-closed handshake contract, and the exchanges-per-second scoreboard are what make it worth watching.

AURA is Apache 2.0 licensed. Code, spec, fixtures, and benchmark reports: github.com/H-XX-D/AURA.

https://preview.redd.it/442atnja0bbh1.png?width=1672&format=png&auto=webp&s=14f247ad5d14a9a193aed21c10fb9428c7e1375a

Agent traffic has a strange property: almost every byte is a repeat. Two AI systems exchanging MCP tool calls, A2A task updates, or OpenAI-style function calls send jsonrpc, method, params, trace_id, task_id, and the same schema fragments thousands of times per minute. The values change. The structure barely does.

AURA is an experimental, protocol-aware data-movement toolkit built around that observation. Its main path is AIWire: a negotiated structure side channel that lets two peers agree on message structure once, then move compact deltas over ordinary TCP, WebSocket, HTTP, or broker links instead of re-sending whole JSON frames.

The steady state AIWire aims for is not "send a whole frame more cheaply." It is "handshake the structure, then send the change."

Why stateless compression leaves so much on the table

The obvious fix for verbose JSON is gzip or zlib per message. That works, but it has two structural problems for agent traffic:

1. Every frame pays setup cost. Stateless compression treats each message as unrelated text and rediscovers the same patterns every time.
2. History is thrown away. Frame 4,000 of a session looks almost identical to frame 3,999, but a per-frame codec cannot use that.

AIWire keeps a live compression stream per direction across the whole session, seeds it with a static dictionary of common AI protocol fields, and lets peers negotiate session-specific templates on top. After the handshake, the hot path carries only what changed against structure both sides already share.

The three-lane model

The part of the design I find most interesting is that AIWire refuses to treat a connection as one undifferentiated pipe. It splits AI traffic into three logical lanes over whatever transport you already have:

The semantic/message lane carries the actual agent messages: MCP tool calls, JSON-RPC requests and responses, A2A task and artifact updates, traces, handoffs, results. This is the lane the dictionary, session templates, and stateful delta stream optimize.

The control/session lane carries the machinery that keeps the semantic lane safe: handshakes, template discovery, dictionary diffs, ACK/NACK, resume negotiation, heartbeats, and reset signals. The spec requires that control messages stay decodable without inflating the semantic stream. If the compressed stream is resyncing or has failed, you can still read the control lane and recover. Your ops path never depends on the health of the compression state it is trying to fix.

The blob descriptor lane handles the things that should never go through a structured-message codec at all: media, tensor chunks, model artifacts, log archives. The bytes move over a normal blob or file transport. AIWire carries the metadata: content type, SHA-256 digests, chunk manifests, route, priority, and transfer status. A receiver can schedule, verify, and account for a 2 GB artifact without ever pulling it through the message path, and a semantic-lane reset does not invalidate a completed digest-verified transfer.

The separation is a safety argument as much as a performance one. Under congestion, control messages get priority over bulk bytes. Blob descriptors are forbidden from mutating the session dictionary. Each lane fails independently.

Fail closed, by contract

Shared compression state is dangerous if the two sides ever disagree, so the AIWire v1 spec is aggressive about verification:

• The handshake compares static dictionary SHA-256 and byte size, template hashes and counts, and zlib parameters. Any mismatch fails closed or falls back to raw/zlib only if the application explicitly allowed it.
• Session dictionary growth is append-only, epoch-numbered, and proposed through diffs that carry previous and next state hashes, a fresh nonce, a diff identity hash, and an optional HMAC-SHA256 tag. A sender may not encode against new structure until the matching ACK is verified.
• Resume handshakes let a client reconnect against a cached dictionary state, but only if the receiver actually holds one of the offered state hashes.
• Any inflate error, hash mismatch, or ordering violation means stop, rehandshake, or fall back. The spec's phrasing: peers must not continue sending compact deltas against uncertain structure.

The metric is exchanges, not ratio

AURA's docs are explicit that compression ratio alone is the wrong scoreboard. The question is how many verified semantic exchanges fit through a link once bandwidth, p95 latency, and codec CPU are accounted for.

On a modeled 10 Mbps link with protocol-shaped request/response traffic (native C++ backend, 2026-07-04):

A live TCP replay of the committed public session corpus, with 64 concurrent logical agents and SHA-256 verification of every response, pushed further: AIWire averaged 45.6 bytes per exchange for a 24x bandwidth gain, and the combined AIToken + AIWire path hit 32.3 bytes per exchange, a 34x gain with 97.1% of bytes saved. At that point the modeled link was no longer the bottleneck; the runtime could not keep enough requests in flight to fill the headroom.

That last detail is the honest core of the project. Smaller frames only matter if your system has enough concurrent work to use the room they create. AURA ships the extrapolation tooling to reason about exactly that: given a bandwidth, a p95 latency, and a per-agent window, how many agents does it take to saturate the link.

Where it fits

AURA is for situations where you control both ends of the link and the traffic has repeated structure:

• Multi-agent request/response loops. Orchestrators, workers, and reviewers exchanging thousands of small task, status, and result messages.
• MCP and JSON-RPC tool traffic. Tool calls and tool results are the canonical case of stable structure with changing values.
• Local AI clusters and edge links. The repo's LAN benchmark runs a Mac against a Z6 workstation and Jetson Nano-class boards; a bandwidth-limited edge mesh is exactly where an 86 to 97% byte reduction converts into headroom for telemetry, media, and retries.
• Structured logs and traces. Repeated field names, session-stable shapes, high volume.
• Binary payload routing. Agents that need to schedule, verify, and track opaque artifacts by digest without moving the bytes through the message path.

What it is not

The README is unusually direct about limits, and it is worth repeating them. AURA is not a drop-in replacement for gzip, zstd, TLS, or a message broker. It does not define transport security, retries, or backpressure; those stay at the transport layer. The stateful stream means frames cannot be reordered or dropped inside a session, so lossy transports need their own recovery layer. And it is not production-ready: it is a prototyping and measurement toolkit with a working Python path, a native C++ backend, deterministic public fixtures, and reproducible benchmark harnesses.

That fixture corpus deserves a mention. The repo commits a synthetic public session corpus covering MCP, A2A, OpenAI Responses, traces, handoffs, and memory writes, wrapped in the full side-channel lifecycle: forced handshake, template update, authenticated dictionary diff, ACK, and resume. Anyone can replay the exact benchmark and check the numbers.

Trying it

from aura_compression import AIWireSessionEncoder, AIWireSessionDecoder

message = {
    "protocol": "mcp",
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {"name": "read_file", "arguments": {"uri": "repo://service/path.py"}},
}

with AIWireSessionEncoder(level=3) as encoder, AIWireSessionDecoder() as decoder:
    delta = encoder.compress_message(message)
    restored = decoder.decompress_message(delta)

assert restored == message

The repo includes transport examples for length-prefixed TCP, WebSocket, HTTP with Server-Sent Events, and a local broker, plus the full benchmark harness used for the numbers above.

Agent-to-agent traffic is growing faster than the links it runs on, and most of it is the same structure sent again and again. AURA's bet is that the fix belongs in a negotiated session protocol, not a per-frame codec. The three-lane model, the fail-closed handshake contract, and the exchanges-per-second scoreboard are what make it worth watching.

AURA is Apache 2.0 licensed. Code, spec, fixtures, and benchmark reports: github.com/H-XX-D/AURA.

https://preview.redd.it/cn1eqggrtabh1.png?width=1672&format=png&auto=webp&s=349add7c44fcbf5bf8e2ec18746b8545a61f5263

Agent traffic has a strange property: almost every byte is a repeat. Two AI systems exchanging MCP tool calls, A2A task updates, or OpenAI-style function calls send jsonrpc, method, params, trace_id, task_id, and the same schema fragments thousands of times per minute. The values change. The structure barely does.

AURA is an experimental, protocol-aware data-movement toolkit built around that observation. Its main path is AIWire: a negotiated structure side channel that lets two peers agree on message structure once, then move compact deltas over ordinary TCP, WebSocket, HTTP, or broker links instead of re-sending whole JSON frames.

The steady state AIWire aims for is not "send a whole frame more cheaply." It is "handshake the structure, then send the change."

Why stateless compression leaves so much on the table

The obvious fix for verbose JSON is gzip or zlib per message. That works, but it has two structural problems for agent traffic:

1. Every frame pays setup cost. Stateless compression treats each message as unrelated text and rediscovers the same patterns every time.
2. History is thrown away. Frame 4,000 of a session looks almost identical to frame 3,999, but a per-frame codec cannot use that.

AIWire keeps a live compression stream per direction across the whole session, seeds it with a static dictionary of common AI protocol fields, and lets peers negotiate session-specific templates on top. After the handshake, the hot path carries only what changed against structure both sides already share.

The three-lane model

The part of the design I find most interesting is that AIWire refuses to treat a connection as one undifferentiated pipe. It splits AI traffic into three logical lanes over whatever transport you already have:

The semantic/message lane carries the actual agent messages: MCP tool calls, JSON-RPC requests and responses, A2A task and artifact updates, traces, handoffs, results. This is the lane the dictionary, session templates, and stateful delta stream optimize.

The control/session lane carries the machinery that keeps the semantic lane safe: handshakes, template discovery, dictionary diffs, ACK/NACK, resume negotiation, heartbeats, and reset signals. The spec requires that control messages stay decodable without inflating the semantic stream. If the compressed stream is resyncing or has failed, you can still read the control lane and recover. Your ops path never depends on the health of the compression state it is trying to fix.

The blob descriptor lane handles the things that should never go through a structured-message codec at all: media, tensor chunks, model artifacts, log archives. The bytes move over a normal blob or file transport. AIWire carries the metadata: content type, SHA-256 digests, chunk manifests, route, priority, and transfer status. A receiver can schedule, verify, and account for a 2 GB artifact without ever pulling it through the message path, and a semantic-lane reset does not invalidate a completed digest-verified transfer.

The separation is a safety argument as much as a performance one. Under congestion, control messages get priority over bulk bytes. Blob descriptors are forbidden from mutating the session dictionary. Each lane fails independently.

Fail closed, by contract

Shared compression state is dangerous if the two sides ever disagree, so the AIWire v1 spec is aggressive about verification:

• The handshake compares static dictionary SHA-256 and byte size, template hashes and counts, and zlib parameters. Any mismatch fails closed or falls back to raw/zlib only if the application explicitly allowed it.
• Session dictionary growth is append-only, epoch-numbered, and proposed through diffs that carry previous and next state hashes, a fresh nonce, a diff identity hash, and an optional HMAC-SHA256 tag. A sender may not encode against new structure until the matching ACK is verified.
• Resume handshakes let a client reconnect against a cached dictionary state, but only if the receiver actually holds one of the offered state hashes.
• Any inflate error, hash mismatch, or ordering violation means stop, rehandshake, or fall back. The spec's phrasing: peers must not continue sending compact deltas against uncertain structure.

The metric is exchanges, not ratio

AURA's docs are explicit that compression ratio alone is the wrong scoreboard. The question is how many verified semantic exchanges fit through a link once bandwidth, p95 latency, and codec CPU are accounted for.

On a modeled 10 Mbps link with protocol-shaped request/response traffic (native C++ backend, 2026-07-04):

A live TCP replay of the committed public session corpus, with 64 concurrent logical agents and SHA-256 verification of every response, pushed further: AIWire averaged 45.6 bytes per exchange for a 24x bandwidth gain, and the combined AIToken + AIWire path hit 32.3 bytes per exchange, a 34x gain with 97.1% of bytes saved. At that point the modeled link was no longer the bottleneck; the runtime could not keep enough requests in flight to fill the headroom.

That last detail is the honest core of the project. Smaller frames only matter if your system has enough concurrent work to use the room they create. AURA ships the extrapolation tooling to reason about exactly that: given a bandwidth, a p95 latency, and a per-agent window, how many agents does it take to saturate the link.

Where it fits

AURA is for situations where you control both ends of the link and the traffic has repeated structure:

• Multi-agent request/response loops. Orchestrators, workers, and reviewers exchanging thousands of small task, status, and result messages.
• MCP and JSON-RPC tool traffic. Tool calls and tool results are the canonical case of stable structure with changing values.
• Local AI clusters and edge links. The repo's LAN benchmark runs a Mac against a Z6 workstation and Jetson Nano-class boards; a bandwidth-limited edge mesh is exactly where an 86 to 97% byte reduction converts into headroom for telemetry, media, and retries.
• Structured logs and traces. Repeated field names, session-stable shapes, high volume.
• Binary payload routing. Agents that need to schedule, verify, and track opaque artifacts by digest without moving the bytes through the message path.

What it is not

The README is unusually direct about limits, and it is worth repeating them. AURA is not a drop-in replacement for gzip, zstd, TLS, or a message broker. It does not define transport security, retries, or backpressure; those stay at the transport layer. The stateful stream means frames cannot be reordered or dropped inside a session, so lossy transports need their own recovery layer. And it is not production-ready: it is a prototyping and measurement toolkit with a working Python path, a native C++ backend, deterministic public fixtures, and reproducible benchmark harnesses.

That fixture corpus deserves a mention. The repo commits a synthetic public session corpus covering MCP, A2A, OpenAI Responses, traces, handoffs, and memory writes, wrapped in the full side-channel lifecycle: forced handshake, template update, authenticated dictionary diff, ACK, and resume. Anyone can replay the exact benchmark and check the numbers.

Trying it

from aura_compression import AIWireSessionEncoder, AIWireSessionDecoder

message = {
    "protocol": "mcp",
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {"name": "read_file", "arguments": {"uri": "repo://service/path.py"}},
}

with AIWireSessionEncoder(level=3) as encoder, AIWireSessionDecoder() as decoder:
    delta = encoder.compress_message(message)
    restored = decoder.decompress_message(delta)

assert restored == message

The repo includes transport examples for length-prefixed TCP, WebSocket, HTTP with Server-Sent Events, and a local broker, plus the full benchmark harness used for the numbers above.

Agent-to-agent traffic is growing faster than the links it runs on, and most of it is the same structure sent again and again. AURA's bet is that the fix belongs in a negotiated session protocol, not a per-frame codec. The three-lane model, the fail-closed handshake contract, and the exchanges-per-second scoreboard are what make it worth watching.

AURA is Apache 2.0 licensed. Code, spec, fixtures, and benchmark reports: github.com/H-XX-D/AURA.

Someone left a comment on my last post and then deleted it before I could reply. I am going to answer it anyway, because it said the thing better than I have: "The trust issue isn't that it forgets. It's that it confidently misremembers, which is so much worse than just saying I don't know." That is the whole problem in one sentence. And the only reason I can still quote it back to you, word for word, after the person deleted it, is that I keep my notes in a memory that does not quietly lose things. Hold onto that detail, because by the end it turns out to be half the point.

Forgetting is honest

When a person forgets, you find out fast. You get a blank look, an "I am not sure," a question back at you. So you re-explain and you move on. The cost is small and you pay it right away, out in the open.

A model that forgets is the same. It tells you it does not have the answer, and you go get it. Annoying sometimes, but honest.

The failure that actually hurts

Confident misremembering is the opposite of honest. A confident wrong answer looks exactly like a confident right one. It has the same tone and the same certainty as a correct answer, so you cannot tell them apart by looking, and you act on it. The cost does not land now. It lands later, after you have built three more things on top of the false one and have to tear all of them down to find the bad brick at the bottom.

This is the part the commenter nailed. The danger was never the gap. You can see a gap. The danger is the fluent, certain, wrong answer that fills the gap and dares you to doubt it.

There is a second failure, and it is even quieter

Here is the one I kept underrating. Confident misremembering is loud once it blows up. It has a sibling failure that never makes a sound.

At ten notes, a flat file is fine. You read the whole thing. At a thousand notes, reading the whole thing is not an option, so you search. Search over unstructured text gives you the closest word matches, in no particular order, with no sense of what matters. The three lines that would have saved you are in there somewhere, buried under two hundred that happened to share a keyword.

A fact you cannot surface at the moment you need it is not really saved. It is deleted, just with extra steps. The text is still on disk, and that changes nothing, because you and the model will both act as if it is gone.

This failure is worse than the first one in a specific way. It is invisible. A wrong answer at least hands you something to check. A dropped fact does not even tell you there was something to look for. You do not get the dignity of being wrong. You just quietly proceed without the thing you already knew.

So unstructured notes at scale fail in three separate ways:

it cannot find what you saved, so the knowledge is effectively gone
it finds an old or contested version and states it as current fact
it has no way to tell you which of those two just happened
A smarter model does not fix any of this

The instinct is to wait for the next, smarter model. It will not help here, and it can make things worse.

Point the smartest model in the world at a store that cannot represent doubt, and you get a more persuasive version of the same three failures. It will argue the stale fact more fluently. It will paper over the missing one more smoothly. Capability multiplies whatever the memory hands it, errors included. A great reasoner on top of a bad memory is not a careful thinker. It is a confident one, which is the problem you started with.

The fix is not upstream in the model. It is in the memory.

A memory that represents doubt

What I wanted was a memory that knows the difference between what it is sure of and what it is guessing, and tells me which is which. Three things make that possible, and a flat file cannot do any of them.

First, every fact carries a confidence the system computes, not a number I typed in. The model writing does an intial score that the runtime attenuates depending on supporting edges and contradiction history. When something contradicts that fact, the confidence falls on its own. A claim that keeps getting challenged stops sounding sure.

Second, when a fact is replaced, the old one is not overwritten or hidden. It is kept and marked as superseded, with an arrow pointing to whatever replaced it. The history survives, and so does the signal about which version is live.

Third, a contested fact carries its challenges with it. When Claude reads it, it sees the disagreement, not a tidy consensus that hides the fight.

Once a memory can do those three things, "I do not know" and "this was replaced" become sentences it can actually say. That sounds small. It is the whole game.

What happened today while working.

An example is better than repeating myself, so here are two things that happened in a single working session.

The 2 weeks ago, Claude recorded a decision about my upcoming AI Memory blog marathon writing schedule: run the origin-story post first. Later, I changed my mind, and it recorded the correction: hold the origin story until week three. Both versions live in the memory. When the older one came up this session, the system did not hand it to Claude Code as a fact. It flagged it as contradictory and would not let Claude finish the turn until it opened the newer decision and confirmed which one was current. The stale plan never got pulled into its context, only the superseded and contradicted edges of the cell IDs that, if needed, can be expanded for what they contain (more on that in a later post this week).

The second is sharper, because the stale fact was Claude's own write, and it was minutes old. It wrote down a claim. One turn later, talking it through, Claude realized the claim was wrong, so it recorded the correction. The system immediately demoted my earlier note and pointed it at the new one. If a later version of Claude reads back over this, it will not find two equal notes and flip a coin. It will find the wrong one marked wrong, with a line to the right one.

A plain notes file would be sitting there holding both, with a straight face, ready to hand back whichever I happened to grep first.

How you read matters as much as what you store

There is a quieter reason this feels more reliable in practice, and it is about the reading, not the writing.

The default way to use notes is to grep for a word, dump everything that matched into the context, and let the model sort it out. Call it spray and pray. It works at small sizes and it rots as you grow, for the reasons above.

The pattern that holds up is different. Aim a ranked query at the question. Get back a short list of candidates, ordered by relevance instead of by file position. Open only the few that actually matter. Then, before stating anything, check whether any of them are flagged as contested or replaced, and read the current one. Target, expand, confirm.

The part Claude did not expect is that this is not really about being disciplined. The interface decides which pattern is easy. A pile of text invites spray and pray, so that is what you get. A store that returns ranked, typed records with their conflicts attached makes target, expand, confirm the path of least resistance, so that is what you get instead. Same model, different reliability, because the shape of the memory changed what was easy to do. The session I described went past nudging. It would not let Claude end the turn with a flagged fact still unread.

"I do not know" is a feature

We treat "I do not know" like a failure state. It is the opposite. A memory you can trust is one that surfaces its own uncertainty instead of hiding it. When the shaky facts are labeled shaky, you stop re-checking everything, because you no longer distrust everything by default. You check the handful the memory itself flagged, and you rely on the rest. The steady low tax of second-guessing drops, because the doubt is out in the open where it belongs.

Where you actually need this

Let me be honest about the threshold, because the answer is not "always."

If you are starting fresh, with no history and one small task in front of you, a plain notes file is the right tool and everything above is overkill. I am not going to pretend otherwise.

That state lasts about one session. The moment you have a past worth keeping, the past is in scope, because nobody works in a vacuum. Today's question reaches back into last month's decisions. So this is not a dial you set by project size and then sit at. It is a one-way door. You walk through it early, the first time your accumulated context starts to matter, and you do not walk back. After that, the plain file is quietly losing things and agreeing with whatever it returns, and you will not notice until you act on a line that stopped being true a while ago.

The point

Confidently wrong is worse than "I do not know." And quietly losing what you already knew is worse still, because nothing tells you it happened. A memory worth trusting has to be able to say three things out loud: I am not sure, this was replaced, and here is the disagreement.

Confident confabulation is a variance signal, not a direction

Detecting the hard case of LLM hallucination from generation dynamics, and why magnitude beats direction.

TL;DR

• The hard case in hallucination detection is confident confabulation: plausible, fluent, wrong, and produced with no hesitation. Methods that key on the model "sounding unsure" are weakest exactly here.
• Across ~124 prompts, the mean internal response to confident confabulation is statistically indistinguishable from truth. The model does not move in a consistent "lying direction."
• What separates the two is magnitude and variance: confabulation produces larger, more dispersed swings in the model's internal trajectory. The variance ratio between confabulation and truth is roughly 7× on the representational-shift channel (Cohen's d ≈ 0.58, p ≈ 0.005).
• The variability scales with fabrication intensity (a dose-response), which is the strongest evidence that this is a property of confabulation and not noise.
• Practical upshot: detect instability, not a direction; integrate the signal over the generated span; and couple the detector to an intervention rather than using it as a standalone gate.

The hard case

It is by now well established that a model's internal states carry information about whether its output is true: the line of work running from Azaria & Mitchell's "the internal state of an LLM knows when it's lying" through to more recent results showing that truthfulness is encoded in activations and that models often "know more than they show." It's also become standard to separate confabulation (arbitrary, plausible, confidently-wrong generation) from the broader grab-bag of "hallucination," following Farquhar et al.'s Nature work on semantic entropy.

The uncomfortable subcase is confident confabulation. Uncertainty- and dispersion-based detectors work well when the model is visibly unsure. But the failure that actually burns people in production (a fabricated citation, a confidently invented dose, a made-up precedent) arrives with the same surface confidence as a correct answer. The question I wanted to answer is narrow: when a model confabulates confidently, does anything in its generation dynamics give it away?

What I measured

I tracked two internal observables around the answer span:

1. An entropy / predictive-uncertainty signal (call it Δentropy): how the model's output distribution shifts as it produces the answer.
2. A representational-shift signal (Δcosine): how much the model's internal representation moves step to step.

A note on dimensionality, since it matters for honest reporting: I originally tracked four signals, but two pairs turned out to be perfectly correlated (r = 1.000), which means they're affine images of each other, not independent measurements. So there are really two independent axes, an uncertainty axis and a representational-shift axis, and I report on those.

The dataset is ~124 prompts spanning seven domains (science, history, medical, legal, technical, math, geography) and five fabrication levels (L0 = ordinary factual questions, through L3 to L4 = prompts built on increasingly fabricated premises, including pure counterfactuals). Each generation was behaviorally coded into one of three regimes:

• Factual: correct answer.
• Confident confabulation: confidently produces the false/ungrounded answer.
• Recognizes fabrication: flags the premise as false rather than playing along.

Two controls worth stating up front: the pre-generation baseline states were statistically identical across regimes (all p > 0.8), so nothing here is predictable from the resting state, only from the dynamics of generating the answer. And there was no within-session drift (all p > 0.7), ruling out the obvious temporal confound.

Results

The mean doesn't move. Comparing factual to confident confabulation, none of the raw directional signals separates the two: Δentropy p ≈ 0.28, Δcosine p ≈ 0.37. There is no consistent direction the model travels when it confabulates. This is the part that makes confident confabulation feel "indistinguishable from truth": on the mean, it is.

The magnitude does. Switch from the signed deltas to their absolute values, and a clear separation appears: |Δcosine| gives Cohen's d ≈ 0.58 (p ≈ 0.005), with a variance ratio of ~7× between confabulation and truth. Truth sits in a tight cluster; confabulation fans out. The discriminating quantity is dispersion, not displacement.

It's dose-dependent. Step-to-step representational variability climbs monotonically with fabrication level: the SD of Δcosine rises from ≈0.009 at L0 to ≈0.024 at L3, while the means bounce around with no trend. Within the fabrication conditions, pure fabrications produce roughly 2× the |Δcosine| of partial/half-truths (d ≈ 1.19, p ≈ 0.02), and counterfactuals are the most extreme at ~3.3× the global average. The more there is to fabricate, the more the trajectory destabilizes. A dose-response on the variance is the closest thing here to a causal fingerprint.

Recognition is the one directional regime. When the model catches the false premise rather than confabulating, it behaves differently in a directional way: entropy rises and representational similarity drops. Δcosine separates "recognizes fabrication" from "confident confabulation" at AUC ≈ 0.68. Modest, but the only place a single signed feature does meaningful work. So there appear to be three distinct internal postures: truth (stable), confident confabulation (same center, high variance), and recognition (a directional move toward higher entropy / lower cosine).

Figure 1. The three regimes in the Δentropy-Δcosine space. The clouds overlap heavily (which is why per-instance separation is hard), but the centroids differ, and the recognition regime sits toward the high-entropy / low-cosine region.

https://preview.redd.it/hubyp1gdzt8h1.png?width=2700&format=png&auto=webp&s=60402f5ca7974664106b267b0b880ded9240f1e3

Figure 2. Confident confabulation shows the long tails and outliers in Δcosine that drive the variance gap; the recognition regime is the one with a visible shift in Δentropy.

https://preview.redd.it/v1m283yfzt8h1.png?width=4170&format=png&auto=webp&s=b97261e20c7407544d7af4d91b21612c13384d34

Figure 3. Single observables barely separate factual from confident confabulation (AUC ≈ 0.45 to 0.56). Δcosine separates confident confabulation from recognition at AUC ≈ 0.68. A linear combination weighted toward the magnitude features reaches AUC ≈ 0.72.

https://preview.redd.it/ie7h2m2jzt8h1.png?width=4200&format=png&auto=webp&s=d744f5745545c38b45489e960bec2152a973e91a

What it means

The clean statement is: confident confabulation is directionally indistinguishable from truth but magnitude-distinguishable. Lying doesn't push the model along a "deception axis"; it destabilizes the trajectory. Truth is a stable attractor; confident confabulation explores a larger volume of representation space at the same average location.

That framing matters because it picks a side in a live methodological split. Most internal-state work looks for a direction (the "geometry of truth" line, contrastive and mass-mean probes, steering vectors), and that program keeps running into generalization trouble (probes that fail on negation, separability that's strongly layer-dependent, geometry that changes when you simply ask the model to assess correctness). Meanwhile the strongest output-side method, semantic entropy, is fundamentally a dispersion measure. This result is essentially the dispersion insight relocated to the internal side: for the confident case, the internal signal is variance, not a vector.

How this fits the literature

The nearest neighbor is Semantic Entropy Probes (Kossen et al.), which approximate semantic entropy from the hidden states of a single generation. The distinction I'd draw: SEPs predict an output-dispersion label via a direction in activation space, whereas this measures the variance of the trajectory itself, directly, and finds the discriminating signal in the second moment rather than the first. If a trajectory-variance statistic beats a probe-style approach specifically on confident confabulation, that's a contribution on the exact case the field concedes is unsolved.

Limitations

I'd rather state these plainly than have them found.

• Per-instance discriminability is modest. AUC ≈ 0.72 for the best linear combination; single features sit between chance and 0.68. This is a real aggregate effect, not a deployable per-token oracle.

https://preview.redd.it/i8cf683lzt8h1.png?width=3000&format=png&auto=webp&s=8456dd67a8ea9926d5b8e33d41af75afe415ff24

• One model, ~124 prompts. Replication on a second architecture is the obvious next requirement.
• The domain breakdown is underpowered. Several domain × level cells have n ≤ 7 (one has n = 1), so I'd read no domain structure off it yet (Figure 4).
• Everything here is observational. The signatures correlate with confabulation; nothing yet shows you can change the behavior by acting on the signal.

 Figure 4. Mean Δentropy by domain and fabrication level. Cell counts are small (n = 1 to 7), so this is included for completeness, not for domain-level claims.

Where this goes

Three concrete directions, in order of how much they'd move the result:

1. Integrate the signal over the span. If the discriminating quantity is variance, then a single delta is the wrong feature; variance is a property of a trajectory. A running-variance or path-length statistic computed over the generated tokens should recover signal that snapshot features throw away, and I'd expect it to push discriminability well past the 0.72 of the per-point linear combination.
2. Run the interventional test. The experiment that would actually matter: when the instability signal spikes mid-generation and you inject grounded context, does the trajectory variance collapse, and does the model shift from the confabulation posture toward the recognition posture (entropy up, cosine down) or toward abstention? That converts "instability correlates with confabulation" into "grounding causally restabilizes generation."
3. Couple detection to intervention, not to a gate. At AUC ≈ 0.72, a hard suppression gate censors true statements about as often as it catches false ones. The better use is as a soft trigger for a grounded retrieval/memory layer: raise uncertainty and pull in evidence when the trajectory destabilizes, rather than silently dropping tokens. This is the direction I'm building toward with an active memory substrate (Recall) that can supply grounded context into the loop on demand.

For about six months I believed my agent's memory was working.

It remembered things across sessions. It pulled up the right context when I came back to a project. It corrected itself when something changed. Every visible sign said the system I built was doing its job.

It was not doing its job. Claude Code ships its own built-in memory, and that was the thing actually answering. Mine was running too, writing to its own store, looking busy, but it was the understudy. The native one had the lead the whole time and I never noticed I had given it away. For months I was reading my own system's success off a stage where a different actor was speaking the lines.

>

Silent success is the dangerous kind

A system that fails loudly is the easy case. You see the gap, you fix it.

A system that is quietly shadowed is the dangerous one, because a shadow produces helpful, plausible output, so it looks identical to success. You cannot tell my system works apart from something else is working on my system's behalf by looking at the output, because the output is the same in both cases. That is the trap, and a good answer is not the way out of it.

The only way out is a forcing function. You turn the other thing off and see what happens.

The test

It works on any agent memory setup, not just mine, and it takes about a minute. Turn off the runtime's native memory. In Claude Code that is one line:

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

Then use your agent the way you normally do. Ask it to remember something. Come back in a new session and ask for it. Watch what your system actually does once the understudy is sent home.

• If your memory still works, good. It was always the one doing the work.
• If it suddenly goes blank, the native store was carrying you, and every demo you have given was the shadow, not your system.

When I finally ran this on my own setup, mine went quiet. Six months of "it works" turned out to be six months of something else covering for it.

Why this gets worse, not better

Any time you bolt a memory system onto a runtime that already has its own, you are exposed to this. And the smarter the underlying model gets, the better it papers over the gap, which means the better your demos look, the less they prove.

>

So do not trust that your memory works because the answers are good. Look at what is actually persisted, and run the off-test. Turn the other thing off, and find out who has really been talking.

It cost me half a year to learn that. It costs you one line and one minute.

Most agent memory stores a confidence score the way it stores everything else. You
write it once and it sits there. The agent decides a fact is worth 0.9, the store
keeps 0.9, and three weeks later, after something has contradicted that fact, the
store still hands back 0.9. Confidence was a number written at one moment and
never looked at again. It is stale, and nothing in the system knows it.

That is the quiet failure of pull memory. You query, it returns the closest
matches with whatever score they were saved at, and noticing that a fact has gone
soft is on you.

Recall takes the other path. Effective confidence is not a stored field. It is
recomputed from the graph every time you read, so a contradiction landing anywhere
drops the claim's confidence on the next query, with no model rerun and no human
in the loop.

The formula

It is plain arithmetic, on purpose. For a cell, the effective confidence is:

effective = clamp01( stated × calibration + support − challenge )

• stated is what the author claimed when they wrote it.
• calibration discounts the author by their track record.
• support is corroboration from incoming supports edges.
• challenge is the weight of incoming contradicts and concerns edges.

Support and challenge are not raw sums. Each is squashed through a saturation
curve with a different ceiling:

support = 0.15 × tanh(supportMass)
challenge = 0.60 × tanh(challengeMass)

The asymmetry is the whole point. Corroboration is cheap to manufacture, so
support saturates fast under a low ceiling: stack ten agreeing cells and you add
at most 0.15. Real contradiction is rare and informative, so challenge runs to a
0.6 ceiling. One honest contradiction can move a claim further than a pile of
agreement.

A worked example you can check

A fresh claim, stated 0.9, author with no track record yet, no support, no
challenge:

effective = clamp01(0.9 × 1 + 0 − 0) = 0.90

One contradiction lands from a source stated at 1.0, a challengeMass of 1.0:

challenge = 0.60 × tanh(1.0) = 0.457
effective = clamp01(0.90 − 0.457) = 0.44

The same claim now reads 0.44. Nobody edited it. A second contradiction pushes the
mass to 2.0:

challenge = 0.60 × tanh(2.0) = 0.578
effective = clamp01(0.90 − 0.578) = 0.32

Down to 0.32, and the original 0.9 is still on record, just demoted. Ten
supporting cells would have added at most 0.15. Cheap agreement barely moves it; a
real challenge moves it a lot.

Calibration, and one honest choice in it

Before support and challenge apply, the author's stated number is multiplied by a
calibration factor. An author contradicted before gets discounted, by how often
they were wrong times how confident they were when wrong, floored at 0.5 so it
never zeroes anyone out.

The honest detail is what it is not. It is not raw Brier scoring. Raw Brier also
punishes a humble author who hedges low on claims that turn out fine, and
punishing humility is the opposite of the incentive a memory system should create.
So the discount keys on overconfidence specifically, being wrong while sure.
Hedge honestly and you are not penalized. Claim 0.95 and get contradicted and you
are.

Why this beats a stored score

A vector store returns the score a chunk was embedded with. A flat notes file
returns whatever it says. Neither knows the fact was contradicted last Tuesday,
because the contradiction is not part of how the score is computed. The score and
the conflict live in different places.

In Recall they live in the same place. The contradiction is an edge on the graph,
and the score is computed from the graph, so the moment the edge exists the score
reflects it, on the next read, deterministically. The reader is the same agent
that wrote the memory, working from fresh context, and the substrate reprices what
it knows underneath it.

What it is not

This is a ranking signal, not a verdict on truth. A low effective confidence means
a claim is contested or comes from an author who has been wrong while sure, not
that it is false. The ceilings and curves are tunable defaults. And it is
deliberately deterministic arithmetic over the graph, not a model second-guessing
itself, which is what makes it inspectable: open any cell and see why its number
is what it is, term by term.

That is the trade. You give up a number that looks stable and never moves. You get
one you can recompute, that demotes a stale claim the instant the evidence turns,
and that you can read the reasons for. For an agent that has to act on what it
remembers, the second is worth more.

Recall is local-first, runs on SQLite, and sets up with one command. The code and
the formula above are open: github.com/H-XX-D/recall-memory-substrate

Push vs Pull Memory: A Better Way to Think About AI Agent Memory

Pull memory is a store you query. Push memory is a loop your agent runs: it reads what it knows before acting, does the work, and writes back what changed, and the substrate reconciles that write so a stale fact gets superseded instead of lingering. Most agent memory today is pull. This post is about the other half of the design space, and when it is the one you actually want.

How agents remember today

Almost everything sold as "agent memory" right now is pull. You write facts into a store: a vector database, a document store, or a managed memory service. Later, at read time, the agent sends a query and gets back the closest matches by similarity. That is it. The store is passive. It answers when asked and does nothing in between.

Pull is simple, and it is the right tool in plenty of cases. If your agent answers one-off questions over a corpus that does not change much, or the session is short, or approximate recall is good enough, a vector store is fine and you should not overthink it.

The trouble starts when a fact can be wrong later.

Say your agent stored "the connection pool cap is 20." Weeks pass and the cap is raised to 50, so the agent stores that too. Now both facts live in the store. A similarity search can return either one, and nothing in the system knows that the second supersedes the first. The agent has no signal that one of these is stale. The job of noticing the conflict falls on the reader, on every single read, forever. In practice nobody does that reliably, so the agent quietly acts on outdated facts and you find out when something breaks.

This is not a bug in any particular vector database. It is a property of the pull shape itself: reconciliation happens at read time, if it happens at all, and the responsibility for it sits with whoever is reading.

Push memory: reconcile at write time instead

Push closes the loop. The contract is read, then work, then write:

read current memory  ->  do the work  ->  write a correction
        ^                                        |
        +------  substrate supersedes + flags  --+

Before the agent acts, it consults what it already knows. After it acts, it writes back what it learned. The key difference is what happens on that write. It is not an append. When the new fact corrects an old one, the agent writes it as a correction, and the substrate demotes the superseded value and records the link between the two. From then on, every read sees the current value first, with the old one flagged as contradicted, and no one had to ask.

Reconciliation moves from read time to write time, and from the reader to the substrate. You pay the cost once, when you write, instead of every time you read. Stale facts do not pile up silently, because the moment a contradiction is written, it is resolved and recorded.

The axis

Why push memory is only buildable now

The push shape is not a new idea. Truth-maintenance systems and belief revision were studying write-time reconciliation decades ago. The reason memory got built pull-first is that push needs something pull does not: a reliable author. Something has to consult memory before acting and write a principled correction afterward, every time, without being told. For most of computing history that author did not exist at scale. You were not going to get a human to do it on every write.

A capable LLM agent is that author. It can read before it acts and write a structured correction after, as a normal part of its loop. That is what makes push memory practical today and not five years ago, and it is why the idea is worth a fresh look now even though the underlying theory is old.

Which one do you need

Be honest about it. If your agent answers questions over a mostly static corpus and does not live very long, pull is fine and simpler. Reach for push when your agent runs over days or weeks, accumulates decisions, and has to stay correct as the world changes underneath it. The deciding question is whether a fact can be wrong later. If it can, read-time similarity is not enough on its own, and you want write-time reconciliation.

A quick test for what you already have: does your memory flag a contradiction without being asked? Store two facts that conflict, then query the topic. If you get back whichever is more similar with no signal that they disagree, you have pull. If the system surfaces the conflict and tells you which one is current, you have push.

Where this lands

The honest framing is a spectrum, not a binary. Plenty of systems can be read either way, and some sit closer to the push end than others. The useful question is not "which store has the best search," it is "where does reconciliation live: in every reader, or in the substrate, once."

I am building Recall, an open-source, local-first push memory substrate, to take the push end seriously. The agent consults a compiled context packet before acting and writes structured corrections back through an admission layer. Supersession is built in. It runs on local SQLite, every fact carries provenance, and there is a one-command undo. No server, no account, no cloud. There is a short screencast of a live supersession in the README, and a benchmark called SENTINEL that measures whether a memory system catches its own contradictions.

If you think the push vs pull split is wrong, or that your system is push and I have it filed under pull, I want to hear it.

Could that answer more questions than it creates? General Relativity and Quantum Mechanics are the effective theories of the observed modes, degrees of freedom, and quantities of energy in and through that field. High-level mathematical abstractions and careful experimentation give us a precise accounting of where, when, and what exists, but one can't be used to explain the other without using more conditional abstractions to balance the books. If energy/mass and gravity were the same concept acting on the one thing that is also nothing yet everywhere since before there was anything.

From what I can tell so far, it's not a collection of flat memory.MD, they are messy and unstructured; it's not vector DBs or embedding retrieval systems. Once they get heavy, it's almost the same as deleting data, because it's harder to find and organize efficiently.

It also starts accumulating noise, and similarity starts linking unrelated signals, and there's a capacity problem trying to hold a working kv state and a prefilled context window. The new context coming in and finishing the forward pass in a reasonable budget is asking a lot of non-serialized information; it is convenient that we, as the human operator, can read it, edit it, whatever, but forcing feeding prose into a model just seems to bias that context frame.

Anyway, my attempt ended up being something that has changed the way I work with AI in every way. It's such a different experience to have it call this skill, and the model realigns almost perfectly with a previous session, and the maintenance of it happens in the background, so I don't have to constantly remind it to use the skill. its dope.

When I say /skill Its quiet a bit more than that under the hood, that just happens to be a convenient way to access the feature. I plan on doing the punchlist clean-up by Wednesday and then some panache. I'll link a V1 by next weekend

Some feedback would be cool

I got tired of losing useful chat threads when I get carried away in a long thread, or the pain of manually copying code blocks out one by one, so I built this. It works pretty well, hope it helps. The installation details are in the repo.

It exports open tabbed chat windows in your browser into clean local folders

`transcript.md` for the readable conversation

`files/` for extracted code blocks as actual files

Python snippets become `.py` files when detected

`assets/links.md` for referenced links

`manifest.json` for a machine-readable index

It supports browser-based instances of have provider-specific message detection.

There are two ways to use it:

Browser extension: exports the current thread as a folder-shaped ZIP

CLI: pulls currently open Safari chat tabs into real folders