• 

  texo

• 

  diagram

texo-agent: memory that knows when to stop believing things

Inspiration

Texo started because I saw people on LinkedIn circling the same obvious wound in agent memory:

“Wouldn’t it be useful if agents knew when old context was no longer true?”

And I had that very specific builder reaction:

Yeah, someone should build that.

Fine. Hold my beer.

Most agent memory today is accumulate-only. You embed every fact into a vector store, retrieve whatever scores highest, and pray the stale version does not sneak into the context window wearing a fake mustache.

That is not memory.

That is a haunted junk drawer with cosine similarity.

The problem is not that agents forget too much. The scarier problem is that they remember too much, with no typed way to stop believing outdated things.

A real memory system needs more than recall.

It needs supersession.

It needs provenance.

It needs the ability to say:

This was true before. This replaced it. Here is the receipt.

That is the idea behind texo-agent: memory that accumulates across sessions without rotting into a pile of equally plausible contradictions.

Git tracks code diffs.

Texo tracks claim diffs.

What it does

texo-agent is a chat agent whose persistent memory is an append-only claim-chain, not a vector database.

When you tell it something, that information becomes a journaled claim.

When the fact changes later, the old claim does not remain in the system waiting to poison future context. It is retired through a supersession event, with a receipt recording what replaced it, when the transition happened, and where the new claim came from.

The agent can answer the normal memory question:

What do you remember about deploys?

But it can also answer the more important one:

What did you used to believe, and why did you stop believing it?

That is the difference.

Suppose you teach it:

Deploys happen on Fridays.

Then, in a later session, you say:

Deploys moved to Tuesday.

The Friday memory is not deleted, buried, or left to fight Tuesday in embedding space.

It is marked as superseded.

When texo-agent begins a new session, it replays the journal and injects current claims into the prompt as trusted memory. Superseded claims are preserved as history but quarantined from current trust. Open conflicts are surfaced instead of being silently resolved.

The agent does not just remember.

It remembers with receipts.

How we built it

texo-agent is built on top of Texo, a claim-chain system backed by BatPak, my content-addressed append-only event log.

BatPak gives the project its substrate:

• Event sourcing
• Content-addressed records
• Receipts
• Deterministic replay
• Hash-committed history

The core flow works like this:

1. Every chat turn is immediately appended into a hidden per-session journal lane.
2. The session is crash-safe because the journal is the session.
3. When the session ends, the user’s utterances are rendered into markdown.
4. A Qwen extraction pass converts the transcript into atomic claims.
5. Each claim is grounded to source provenance, including path:line, byte span, extractor model, and prompt version.
6. A deterministic faithfulness gate rejects claims that are not supported by the source text.
7. A Qwen relation pass decides whether candidate claims are duplicates, conflicts, supersessions, or unrelated.
8. Replay reconstructs the memory projection used by the agent at the beginning of every turn.

The model runs at the record boundary, not during replay.

That matters.

Claim extraction and relationship judgment happen once. Their outputs are then cached using a content-addressed key derived from the model, prompt version, and source span:

$$ H(model \mid prompt_version \mid span) $$

After that boundary, replay is deterministic.

The memory system is not “whatever the model feels like today.”

It is a journal you can rerun.

For efficiency, the relation judge does not compare every claim against every other claim. That would be quadratic pain soup.

Instead, embeddings build a cosine-similarity graph. Candidate pairs are bounded to connected components, and the relation judge only receives claims that are likely to be related.

That changes the practical shape from brute-force comparison toward:

$$ O(n \cdot c) $$

where (c) is the bounded cluster size.

Texo uses Qwen Cloud through the DashScope OpenAI-compatible API.

The working integration uses:

• qwen3.7-max for agent chat
• qwen3.7-max for claim extraction
• qwen3.7-max for semantic relationship judgment
• text-embedding-v4 for the cosine-similarity prefilter

The Qwen Cloud API integration is functional and was used to run the agent, extraction pipeline, relation judge, and embedding flow.

I also built the full Alibaba Cloud ECS deployment path, including provisioning scripts, environment configuration, service installation, and proof automation targeting the Singapore region.

However, I was not able to complete the live ECS deployment before the submission deadline because Alibaba Cloud’s KYC process repeatedly blocked the infrastructure account. I contacted customer support multiple times, but the issue was not resolved in time.

The Qwen Cloud model integration is real and working.

The ECS deployment automation is complete and public in the repository.

The live ECS resource itself was not successfully provisioned, and I am not representing it as if it was.

The application itself is one Rust binary.

CLI, HTTP, MCP, chat, session lanes, journal replay, and the memory pipeline all dispatch through the same operation kit.

During the hackathon window, I rebuilt the architecture from six crates into one crate and one binary. I removed the heavier async stack and replaced tokio, axum, reqwest, and the MCP SDK with sync HTTP, Server-Sent Events, HTTPS client code, and MCP transport built around the substrate’s own primitives.

That sounds reckless because it was a little reckless.

But it was measurable, not vibes.

Claim IDs are a pure function of source, line, and normalized text. That gave the rebuild a hard acceptance test:

Every claim ID produced by the old implementation had to remain identical in the rebuilt system.

It did.

Challenges we ran into

Prompt changes are pipeline changes

The first real challenge was discovering that prompt changes are not isolated changes.

I tried to harden the extractor by adding one exclusion rule for documents that make claims about themselves.

It seemed harmless.

One bullet in a prompt.

What could possibly go wrong?

The live regression corpus dropped from five out of five passing cases to four out of five.

The new instruction changed the wording of an extracted claim just enough to shift its embedding. That embedding shift separated a true supersession pair into different clusters.

Because the claims no longer appeared in the same candidate group, the relation judge never saw them together.

The system did not fail loudly.

It failed in the more dangerous way:

Almost correct.

So I reverted the prompt change.

That became one of the strongest lessons from the build.

In a claim-chain memory system, prompt wording is not decorative. It changes extracted claims. Extracted claims change embeddings. Embeddings change clusters. Clusters determine which relationships are even considered.

A prompt update is a schema-adjacent system update.

It needs versioning, live oracle testing, and the willingness to revert.

The assistant was becoming its own witness

The second challenge came from live driving the agent.

The model was double-journaling facts because assistant replies repeated user statements back to them.

If I said:

Deploys happen on Fridays.

And the assistant replied:

Got it, deploys happen on Fridays.

Both sentences became candidate memories.

That is wrong.

Memory should represent what the user actually stated, not the assistant’s helpful paraphrase of it.

The fix was both philosophical and practical:

Session transcripts render user utterances only.

The assistant can respond naturally without becoming a second source for the same fact.

First-person language exposed the faithfulness boundary

The third challenge involved first-person language.

Humans say things like:

We deploy on Fridays.

An extractor may normalize that into:

The team deploys on Fridays.

That sounds reasonable, but Texo’s faithfulness gate is intentionally strict.

If “the team” does not appear in the original source, the normalized claim may be rejected.

The gate was right.

The correct fix is not weakening provenance during a deadline sprint. It is building better transcript-native oracle cases for first-person language, team references, preferences, and implied subjects.

A memory system should fail visibly before it quietly invents a cleaner sentence than the source supports.

Rebuilding the architecture without losing memory identity

The fourth challenge was rebuilding the architecture during the hackathon window without losing compatibility.

Migrating BatPak, flattening the crate structure, replacing transport layers, and preserving claim identity at the same time is exactly the kind of task that usually summons a swarm of deadline goblins.

The only reason it remained safe was that the project had receipts all the way down.

If the rebuilt system produced the same claim IDs and replayed the same store byte-identically, it passed.

If not, it failed.

No mysticism.

Just receipts.

The infrastructure account got trapped in KYC

The final challenge was not a software bug.

My original Alibaba Cloud account became trapped in KYC verification. Support interactions went back and forth without producing a resolution before the submission deadline.

I created a separate Qwen Cloud account and successfully validated the Qwen API integration using the available free quota. That allowed the model-backed parts of Texo to run correctly.

But Qwen Cloud API access and Alibaba Cloud ECS provisioning are separate account paths.

The alternate account solved model access.

It did not solve the blocked ECS deployment.

The repository contains the complete ECS provisioning and deployment path, but the infrastructure itself could not be launched before the deadline because the sponsor-side verification issue remained unresolved.

I chose to document that honestly rather than turn a blocked deployment into fictional proof.

Accomplishments that we are proud of

The biggest accomplishment is simple:

texo-agent can tell you when it stopped believing something.

That is the whole project.

In a live run, I taught it that deploys happened on Fridays.

In a later session, I changed the fact to Tuesday.

Then I started a fresh session, where memory came entirely from the replayed journal.

The agent answered that deploys now happen on Tuesday and explained that the earlier Friday memory had been superseded.

That is the magic trick.

Except it is not magic.

It is an append-only journal, typed events, deterministic replay, and provenance.

I am also proud that Texo is not just a wrapper around a vector database.

Embeddings are used as a prefilter, not as the source of truth.

The journal is the memory.

The vector layer helps locate candidate relationships. It does not decide reality.

Other pieces I am proud of include:

• Superseded memories are quarantined instead of silently retrieved as current.
• Conflicts are surfaced instead of automatically resolving in favor of the newest sentence.
• Every claim carries receipts including source path, source line, byte span, model, and prompt version.
• Replay is deterministic because model output is recorded once and cached content-addressed.
• Re-ingesting cached corpora can replay in milliseconds instead of rerunning the model.
• The project audits its own documentation with just drift.
• Texo’s self-audit extracted 214 claims across 12 documents and found 11 that had already been superseded.
• The rebuild reduced the dependency lockfile from 492 packages to 222 while preserving claim identity.
• Session state moved into the append-only journal, so a crash does not erase the chat lane.
• The same operation kit powers the CLI, HTTP server, MCP surface, replay engine, and agent.
• The complete Qwen Cloud pipeline works across chat, extraction, embeddings, and relation judgment.
• The Alibaba Cloud ECS provisioning, deployment, and verification paths are documented and automated, even though live provisioning was blocked by KYC.

And personally, I am proud that the system survived dogfooding.

It found real bugs because I used it as a real memory agent, not as a staged demo surrounded by velvet ropes.

What we learned

The biggest lesson is that forgetting is not deletion.

For an agent, deletion is usually too blunt.

The old fact may still matter historically. If a deployment schedule changes from Friday to Tuesday, the Friday claim is not garbage.

It is outdated.

That distinction matters.

A useful memory system should know:

• What is current
• What is superseded
• What superseded it
• What remains in conflict
• Where every claim came from
• Which event changed its status
• How the current projection was reconstructed

The second lesson is that vector similarity is not semantics.

Similarity is useful, but it is not enough.

Contradictory claims are often close neighbors precisely because they discuss the same subject.

“Deploys happen Friday” and “Deploys moved to Tuesday” should be near each other in embedding space.

Similarity gets them into the same room.

It cannot decide what happened there.

The third lesson is that agents need typed memory transitions.

Not just:

• Add memory
• Retrieve memory

They also need:

• Supersede
• Conflict
• Duplicate
• Retire
• Replay
• Explain

The fourth lesson is that the record-once boundary is powerful.

Let the model perceive once.

Journal the result.

Make replay deterministic.

That gives the system room to use Qwen for semantic judgment without allowing the entire memory layer to become a probabilistic fog machine.

The fifth lesson is that evidence makes ambitious rewrites safer.

The architecture rebuild, Qwen integration, prompt revert, self-audit, and replay system were survivable because Texo produces receipts.

Claims can be checked.

Identities can be compared.

Transitions can be replayed.

The sixth lesson is that deployment automation and deployed infrastructure are not the same thing.

The code can be complete while the account boundary remains blocked. That does not erase the engineering, but it does mean the limitation has to be stated plainly.

The seventh lesson is that if you build a tool about documentation drift, it should survive being pointed at its own repository.

Texo did.

The older architectural claims surfaced as superseded by the documents that replaced them.

That felt like the project blinking back.

What is next for Texo

The first operational step is completing the Alibaba Cloud ECS deployment once the KYC issue is resolved.

The deployment path already exists. The remaining blocker is account verification, not application architecture.

After that, Texo needs to get sharper in the places where real memory becomes messy.

The next product step is better transcript-native extraction.

The agent needs stronger handling for first-person statements, team language, preferences, evolving facts, and implied subjects without weakening the faithfulness gate.

The right path is more oracle cases, not looser grounding.

The relation layer should also become more precise.

Cluster-bounded judging already avoids brute-force quadratic comparison, but there is room to improve candidate generation, relation explanations, confidence reporting, and conflict resolution workflows.

The UI needs richer memory controls:

• Inspect an individual claim
• Open the exact source span
• Follow its supersession chain
• Trace the event that changed its status
• Rewind the frontier
• Watch conflicts resolve over time

MCP should become a first-class surface for agents that need context with provenance.

The point is not only to chat with texo-agent.

The point is to let other agents request:

• Current memory
• Superseded memory
• Open conflicts
• Historical projections
• Source receipts

Without inhaling an entire repository of stale prose.

Texo should also become easier to drop into real team environments:

• Markdown repositories
• Architecture decision records
• Runbooks
• Onboarding documentation
• Meeting notes
• Support histories
• Agent transcripts
• Project plans

Anywhere truth changes but the old text remains, Texo has a job.

The long-term vision is bigger than memory for one chatbot.

I want context infrastructure where belief has lifecycle semantics.

Not vibes.

Not “the vector store probably retrieved the right thing.”

Not twenty stale documents wearing trench coats.

A claim comes in.

It gets grounded.

It gets journaled.

It gets replayed.

When reality changes, the old claim is retired with a receipt.

Docs are not state.

Claims are state.

Receipts or it did not happen.

Built With

• ai-agents
• alibaba
• append-only
• astro
• batpak
• claim-chain
• dashscope
• embeddings
• liteship
• mcp
• memory
• memoryagent
• openai
• qwen
• rag
• rust
• semantic-search
• typescript