DEV Community: Oleksander

AI Agents Don't Need a Bigger Prompt. They Need Governed Memory

Oleksander — Fri, 17 Jul 2026 10:41:45 +0000

Most AI agents have a memory problem disguised as a prompting problem.

We keep adding conversation history to the context window, summarizing old messages, or placing documents in a vector database. These techniques are useful, but they do not answer several important questions:

What should be remembered for hours, weeks, or months?
What should decay when it stops being useful?
Which source supports a stored claim?
What happens when two memories contradict each other?
Why was a particular memory returned?
How do we prevent one user's memory from leaking into another user's context?

I built Aura Memory to explore a different approach: memory as a governed cognitive layer that runs beside the model.

The model can remain stateless. Aura owns persistence, retrieval, lifecycle, provenance, and bounded adaptation.

A transcript is not a memory system

A chat transcript records what happened. A memory system decides what remains useful.

That distinction matters once an agent runs longer than a single conversation. Raw history grows without bound. Summaries lose detail. Vector search can find semantically similar text, but similarity alone does not express durability, trust, contradiction, or whether a record has been superseded.

For an agent to develop useful continuity, memory needs its own lifecycle:

interaction
    ↓
store an observation, decision, outcome, or preference
    ↓
retrieve bounded context for the next task
    ↓
inspect provenance and uncertainty
    ↓
decay, promote, consolidate, correct, or archive

This is the role Aura is designed to fill.

What Aura Memory is

Aura is an open-source cognitive memory runtime with a Rust core and Python bindings. Core memory operations run locally and do not require an LLM call, an embedding API, or a cloud database.

The basic interface is intentionally small:

pip install aura-memory

from aura import Aura, Level

brain = Aura("./agent_memory")

brain.store(
    "The user always deploys to staging before production",
    level=Level.Domain,
    tags=["deployment", "preference"],
)

brain.store(
    "A staging deploy caught a migration error",
    level=Level.Decisions,
    tags=["deployment", "outcome"],
)

context = brain.recall(
    "How should I deploy this release?",
    token_budget=1200,
)

print(context)

The returned value is bounded context that can be inserted into a model prompt or used by an agent tool. Storage and retrieval are separate from model inference, so the same memory can be used with Claude, Gemini, OpenAI models, Ollama, CrewAI, LangChain, or an MCP client.

Memory has different timescales

Not every record deserves permanent storage. Aura organizes records into four levels:

Level	Typical role	Expected timescale
Working	Temporary task context	Hours
Decisions	Choices, actions, and active work	Days
Domain	Project knowledge and stable preferences	Weeks
Identity	Durable rules and identity-level facts	Months or longer

Maintenance cycles apply decay, promotion, consolidation, and archival. Frequently useful or important records can persist; low-value working context can fade.

report = brain.run_maintenance()

This is deliberately different from appending every message forever. Forgetting is part of the design, not an error condition.

From records to cognitive structure

Raw records are only the first layer. Aura can build bounded cognitive overlays:

Records → Beliefs → Concepts → Causal Patterns → Policy Hints

Records preserve observations, decisions, preferences, and outcomes.
Beliefs group supporting and conflicting evidence.
Concepts capture recurring abstractions across stable beliefs.
Causal patterns represent repeated cause-and-effect relationships.
Policy hints surface advisory guidance such as “prefer staging first.”

The important word is advisory. A policy hint does not execute an action. Cognitive reranking is bounded, inspectable, and can be disabled. The application remains responsible for deciding what the agent is allowed to do.

brain.enable_full_cognitive_stack()

hints = brain.get_surfaced_policy_hints()

This separation helps avoid a dangerous design pattern: allowing an automatically generated memory to silently become an instruction with unlimited authority.

Retrieval should explain itself

When memory influences an agent answer, “the vector database returned it” is not enough of an explanation.

Aura exposes inspection surfaces such as:

brain.explain_recall("deployment decision", top_k=5)
brain.explain_record(record_id)
brain.provenance_chain(record_id)

The goal is to make memory behavior operator-visible. Applications can inspect why a record surfaced, how it was derived, whether it conflicts with other information, and whether a correction is pending.

Aura also supports governed correction and bounded adaptation. Experiences can enter a reviewable pipeline rather than directly rewriting model weights or silently mutating high-trust knowledge.

What changed in version 1.5.6

The 1.5.6 release focuses on a problem that becomes critical for research and production agents: a plausible claim is not the same as a verifiable claim.

Immutable evidence lineage

Evidence lineage binds a claim to:

a specific source document revision;
the exact byte span used as evidence;
a content hash;
verification status;
an independent answer-permission decision.

A high confidence score cannot override a changed source hash, a superseded claim, or blocked citation admission. Evidence-aware reports only compose admitted findings, preventing blocked source material from being reintroduced indirectly through free-form synthesis.

Deterministic context capsules

An agent often needs a stable “working set” for a task. Re-running broad recall can produce unnecessary context churn, while maintaining a second wiki creates another source of truth.

Context capsules provide a read-only, token-bounded projection over existing memory:

capsule = brain.build_context_capsule(
    purpose="continue the current reliability investigation",
    token_budget=2000,
    namespace="reliability-team",
)

A capsule reports why each record was selected, how many records were omitted, its estimated token count, and a stable content hash. Blocked or superseded records are excluded.

Observable empty recall

“The search completed successfully but found nothing” is an operational event, not merely an empty list.

Version 1.5.6 adds counters for total and empty recall/search outcomes across formatted recall, structured recall, tier recall, and exact search. This makes it possible to monitor empty-recall rates and distinguish missing knowledge from transport or model failures.

One user, one isolated memory boundary

Local development is simple: one agent process can use one Aura directory.

A hosted multi-user system needs an explicit isolation strategy. The safest model is to treat each user's memory as a separate data boundary:

from pathlib import Path
from aura import Aura

def brain_for(user_id: str) -> Aura:
    safe_id = validate_user_id(user_id)
    return Aura(Path("./memory") / safe_id)

Namespaces can provide additional logical isolation, but authentication and authorization still belong to the application. Never accept an arbitrary storage path or namespace directly from a browser request.

For a hosted TypeScript frontend, Aura should run behind a trusted backend or dedicated memory service. The frontend calls an authenticated API; the service selects the correct user-owned store. The Python package is not meant to run inside a static frontend bundle.

This deployment detail is easy to miss. A library can make local installation simple, but persistent memory still has to run somewhere and its data has to be backed up, encrypted, observed, and isolated.

What Aura does not do

Aura is not a language model and does not generate the final answer. It does not make unverified input true. It does not replace application authorization, tool permission checks, or a backup strategy.

It is also not a hosted database-as-a-service. If you deploy it on a server, you own the runtime and storage lifecycle. That tradeoff is intentional: local control and offline operation come with operational responsibility.

Sparse Distributed Representation indexing is the default local retrieval path, while optional embeddings can be supplied when an application needs them. Performance depends on workload and hardware; the project includes benchmarks, but production systems should measure their own corpus and access patterns.

Why build memory outside the model?

Models change. Providers change. Context-window pricing changes. Agent memory should not have to disappear every time the inference layer is replaced.

Keeping memory outside the model creates a stable boundary:

Agent runtime
    ├── model: reasoning and generation
    ├── tools: actions in the world
    └── Aura: persistence, retrieval, evidence, lifecycle, correction

That boundary makes memory portable across models and easier to inspect independently. More importantly, it gives operators somewhere concrete to enforce retention, provenance, isolation, and correction policies.

The project is MIT licensed. You can explore the source code and examples on GitHub, install the package from PyPI, or read the overview at aurasdk.dev.

I am especially interested in how other developers handle three questions:

Where do you draw the boundary between conversation history and durable memory?
How do you isolate memory in multi-user agents?
What evidence should an agent be required to carry before using a stored claim in an answer?

Can a System Grow Its Own Tests? Judges Born from Consequences

Oleksander — Thu, 16 Jul 2026 12:28:24 +0000

This is part four of the “Can You Build an Alternative to LLMs?” series. Part one separated real memory from a polished demo; part two tested self-correction; part three asked whether knowledge is merely a store. Code and experiment logs: AuraSDK.

A repository can have a green cargo test run while a bug is still alive in one of its functions.

That is not a paradox. A conventional test checks a handful of known agreements. If a mutation does not violate those particular agreements, it survives. For an autonomous system, then, the question is not only “can it run tests?” It is harder:

Can it construct a new judging test from the consequences of running code—one that separates a correct implementation from a plausible but incorrect one?

I did not ask a system to “invent a useful test” in free-form text. It gets a constrained process: observe execution, propose simple properties, try to break them on correct code, and turn only the survivors into Rust property tests. The final verdict is not delivered by a Python wrapper or an LLM. It is delivered by cargo test.

Why generating an assertion is not enough

The most dangerous test is not the one that finds nothing. It is the one that confidently fails on correct code.

Imagine a system sees several runs and infers: “whenever the result is non-empty, its length is always at least 3.” That may merely be an accidental bound of the examples it observed. Such a test can reject future correct implementations.

So a candidate property does not immediately become a test. It must pass this cycle:

live code executions
    → candidate property
    → attack it on correct code
    → reject it or scar the false generalization
    → test it against held-out mutations
    → Rust #[test] → cargo test

I call this an invented judge: not “a test written by a model,” but a constrained judge born from consequences and forced to survive refutation.

Five gates, not one attractive run

The first synthetic version showed that the mechanism could work: it killed 5 of 5 held-out mutations with maximum false-fire = 0.0.

That did not mean we had learned how to test Rust code. The experiment therefore passed through five gates:

a synthetic Python world;
a bridge to real cargo test;
seven ports of real Aura functions, compared with a static miner;
a property judge that is actually rendered into Rust;
a combined code-world gate over bodies of real Aura functions.

Two early results matter precisely because they were inconvenient.

First, an early “real Cargo gate” honestly ended as NOT_PROVEN, even though it already had kill = 1.0 and false-fire = 0.0. Its rule was trivial: it added no new power beyond the weak existing test. To fix this, the experiment added an abs_ratio mutation. It passed the weak Cargo test and evaded a simple boundary judge, but failed the arithmetic property matches_division.

Second, simply carrying a result from Python into Rust would have been self-deception. In the final version, each candidate property is rendered into a #[test] in tests/judges.rs; the same cargo test result is used for our method and the control groups.

What the final gate actually tested

The final script, scripts/run_invented_judge_cargo_property_gate.py, works with literal Rust bodies from six AuraSDK functions:

filter_selected;
disjoint;
accuracy_per_mille;
the count projection of prune_deaths;
a bit version of presence_jaccard_rank_key;
has_duplicates.

It introduced 12 mutations in the style of cargo-mutants. Four were killed by the base Cargo tests—a useful sanity check. Eight survived the weak suite, and those eight became the targets for new judges.

There is no Python oracle quietly supplying the correct answer in this gate. There is a Rust trace harness, a restricted vocabulary of property primitives, and a generated Rust test. The vocabulary is intentionally small: >=/<= bounds, scalar length, subset, empty output on empty input, symmetry, monotonicity, and permutation invariants.

That restriction matters. The system is not discovering arbitrary new mathematics. It is selecting and validating judges from a known, auditable language of properties.

A result that does not hide its own boundary

Under stable bounds, future inputs stayed in a regime already represented by the “lived” executions. Across three independent seeds, both approaches produced the same outcome:

Regime	Approach	Kill rate	False-fire	Net
Stable bounds	Invented judge	1.00	0.00	+1.00
Stable bounds	Static miner	1.00	0.00	+1.00

There is no reason to declare victory here. When past data truly covers the future, static generalization works too.

The interesting result appeared in the fragile-bounds regime. Here, future correct cases cross an accidental bound that the static miner had seen in earlier traces.

Regime	Approach	Kill rate	False-fire	Net
Fragile bounds	Invented judge	0.75	0.00	+0.75
Fragile bounds	Static miner	1.00	0.50	−0.50

At first glance, the static miner looks better: it killed every mutation. But it also falsely accused correct code in half of the held-out cases. Its net result is therefore negative.

Our judge missed one mutation. It did not do so because it failed to see it; its candidate bound turned out to be accidental. The process scarred that generalization and returned ABSTAIN instead of a false verdict. The key advantage here is not “kill more.” It is do not lie when the consequences are insufficient to justify generalization.

What “growing a test” means in a narrow, testable sense

This result does not say that a system now understands product requirements on its own. It establishes a narrower claim:

Within a specified language of properties, a system can use correct-code execution and mutation blind spots, discard some false generalizations, generate a Rust property test, and obtain an independent verdict through Cargo.

The formulation has four necessary parts:

consequences, not only static code reading;
counterexamples, not the first plausible hypothesis;
refusal to judge when a property does not survive scrutiny;
independent execution of the generated test in the project’s normal toolchain.

Without the last part, it is easy to accidentally measure the quality of your own evaluator rather than the quality of a test.

What this does not prove yet

The limits of the experiment should not be hidden in a footnote:

the mutations were handwritten in the style of cargo-mutants, not generated by cargo-mutants itself;
probe-input generators are still manually specified;
the scale is six functions and eight mutations that survived the weak suite;
the property vocabulary is predefined and restricted;
this is a code-world gate, not evidence across an entire repository or arbitrary specifications.

The honest next step is either to integrate the loop into real development, or to replace manual mutations and probes with independent tools. It would be wrong to conclude that autonomous testing is solved.

Still, this is stronger than assertion autocomplete. The system does not merely write test text. It has to earn the right to write it: first by surviving refutation on correct code.

The final number

Stable regime: kill 1.00 at false-fire 0.00.
Fragile bounds: invented judge net +0.75; static miner net −0.50.

The important number is not only the kill rate. It says something else: when the future leaves the range of what has been lived, an honest ABSTAIN can be more valuable than a test that is confidently wrong.

The code, gate scenarios, and logs are available in AuraSDK. The next part of the series will test a different boundary: whether such loops can preserve a useful trace over time when the system is no longer allowed to look into the future.

Knowledge Is Not a Store: Why Every Container Died and Every Loop Survived

Oleksander — Thu, 09 Jul 2026 13:02:39 +0000

This is the third article in a research series about trying to build something adjacent to — and in some ways alternative to — large language models, rather than a wrapper around one. Part 1: "My Synthetic Eval Said 30/30. LoCoMo Said 0.13." Part 2: "Can You Build an Alternative to LLMs? 8 Months, ~200 Failed Experiments, One Wall." The code that survived is open source in AuraSDK.

In the previous part I showed the wall: every knowledge carrier I tried failed at transferring causal binding. This part is about a different, narrower, and more useful question that remained after the failures:

If so many containers died and some loops survived — what exactly separates the two?

The answer turned out to be one sentence. And it killed half my designs on the whiteboard, before the first run:

storage preserves an event;
knowledge must change the next action.

It sounds trivial. The consequences are not.

1. The Trap Almost Every Memory System Falls Into

The default answer to "give the system knowledge" is always the same:

store facts;
build a graph;
add embeddings;
add typed edges;
retrieve relevant chunks.

All of these store a statement. A statement is a container. It sits there and waits for someone to retrieve it.

Here is what dead knowledge looks like:

"windows(0) causes a panic"     ← a fact. a dead number. a container.

It looks like knowledge. But it is a string that can lie on a new input. It does not know WHERE it came from, it does not know WHEN it no longer applies, and it changes nothing about the system's next action — until some separate layer (an agent, a prompt, an inference step) decides what to do with it.

And here is the same thing as a lived consequence:

state:       calling slice.windows(window_size)
action:      set window_size = 0
consequence: the world returned panic "size > 0"
conclusion:  this transition refutes the route for the boundary/window-guard class
links:       guard, invalid-parameter, runtime-invariant, panic-before-assert

The difference is not cosmetic. The first is what SOMEONE described. The second was born from EXECUTION: the world returned a panic the author did not know in advance.

2. The Core Prohibition: A Unit of Knowledge Is Not a Container

After ~200 failures, I formulated a prohibition that became filter #1:

A universal unit of knowledge must not be a container.

Because the moment it becomes a container, it is a JSON / graph / table again, and we get dead numbers again. This has been falsified many times: storing links between empty symbols does not produce knowledge.

A unit has to be operational. Three actions must work on it:

1. SELECT   — it can be used to choose an action in a new situation
2. COMPARE  — it can be matched to a new situation by consequence, not by surface
3. VERIFY   — it can be confirmed or refuted by a new consequence (it mutates)

If a unit cannot be (1) used to choose, (2) compared by consequence, and (3) updated by a new consequence — it is a container, not knowledge.

3. The Falsify-Tooth: One Test That Separates Alive From Dead

The problem with prohibitions is that during implementation the unit quietly slides back into a container. So I reduced everything to one test — the irreversibility-into-form tooth:

TEST: can this unit be generated WITHOUT executing in the world?

  yes → it is a FORM (someone described or filled it) → CONTAINER → dead
  no  → it could only be born from a lived collision
        (the world returned a consequence we did not know in advance) → ALIVE unit

It is a sharp, almost brutal criterion. But it works.

windows(0) → panic passes: this consequence is born from execution, the world returns the panic, and you cannot honestly write it from your head without running it.

A co-occurrence graph, a summary, a typed-edge table, an embedding — all fail: they can be filled by hand or by an LLM with no collision with the world at all. So they are containers in disguise.

One sentence worth a whole section: a real unit of knowledge contains a consequence the author did not know until they took the action.

4. The Zero-Action Law: Knowledge Without Action Is Guessing

The most useful result was negative, and it put everything else in its place.

I wanted a carrier that "knows" the correct answer to an unseen situation immediately, with no action at all. Zero-probe transfer. One gate tested this directly:

0-probe unseen transfer:
  no given role       -> selection WRONG, hidden verifier fails
  with given role     -> read-path selects RIGHT
  with shuffled role  -> selection WRONG, hidden verifier fails

Reading that table honestly: the read mechanism works only if the role has already been lived or supplied. Without an action that produces or projects the role, the system does not "know" the unseen answer. Transfer = 0.

This is not a defect. It follows from the nature of the thing:

knowing the answer without action = guessing
guessing without verification = a consensus machine / an LLM
a consequence machine, therefore, needs a consequence to know

This is exactly the line to an LLM. An LLM answers without action because it guesses the most probable continuation. A consequence machine honestly says "I don't know" or performs a minimal check. So abstain is not a weakness — it is the core of its honesty.

5. What This Changes About the Carrier's Goal

The zero-action law inverted the goal itself:

NOT: a carrier that knows the right answer without action
YES: a carrier that minimizes the action needed for an honest consequence-check

Route-state, role-equivalence, scars, cheap-check — these are not "magic 0-probe knowledge." They are organs of cheapening the check. They prune the search, rank, block lies, turn an expensive full probe into a cheaper partial probe. But they do not cancel the principle itself: new knowledge is born from consequence.

The practical criterion I now apply to every experiment:

If a gate shows only fewer probes / cheaper probes / wrong=0 via abstain —
that is NOT a carrier that knows, it's an organ of optimized verification.

That's good if the goal is truthful action at minimal cost.
It must NOT be inflated to "the system knows the unseen without a check."

6. Container Died, Loop Survived — With Numbers

Now the specifics, because this series is held together by numbers, not by morals.

The container (zero-probe) — died. A carrier required to know the unseen without action gave transfer = 0. With a given role, reading works; shuffle the role as a control and the selection is wrong again, the hidden verifier fails. So there was no "knowledge" there; there was a dependence on an already-lived / supplied role.

The loop (cheap-probe) — survived, but only on real overlap. Here is the most important honest story of a single gate. The first version of transferring the selection to unseen cases gave:

2/4  ← a coin flip

The temptation is to declare failure. But the diagnosis was more precise: the unseen situations had been constructed so that they were NOT genuinely related to the trained ones. And the carrier honestly said "I don't know" on 50%, instead of guessing at random. When I rebuilt the unseen cases as normalized mixtures of trained situations — i.e. gave them REAL distributed overlap — the result was:

4/4

The key point: selection generalizes where there is real overlap, and honestly does NOT where there is none. On the genuinely-new, the carrier does not hallucinate a selection — it stays silent. That is exactly the behavior an LLM does not give you.

The difference between the two sides:

container that claims to know without action -> 0 transfer
loop that cheaply checks by consequence      -> 4/4 on real overlap,
                                                honest coin flip (2/4 = abstain)
                                                on fake overlap

7. The Honest Boundary

This does not solve the whole knowledge-carrier problem. How these units compose, how they transfer to the genuinely-new, how they scale — all still open (the wall from part 2 has not gone anywhere). And I'll name the boundary myself, before it gets named for me: this is one person, eight months, a CPU, not a lab. There may be a container I never tried.

But the most important thing is done: I finally named precisely WHAT the carrier has to carry. Not data. Not facts. Not semantics. A unit of a lived causal transition that can be selected, compared by consequence, and refuted.

And from there followed the single question I now use to judge every experiment:

Does it create a unit of lived consequence —
or just a prettier container?

That question saves months. Because a prettier container always looks like progress — right up until you ask it to transfer.

8. Conclusion

The eight-month post-mortem produced a less glamorous but more useful thesis than the one I was chasing:

containers store statements that can lie;
loops store consequences the world has already confirmed;
knowledge without action is guessing;
a cheaper honest check > a confident answer with no check.

Every container I built died at transfer. Every loop tied to a consequence survived exactly as far as it honestly stayed silent where there was no overlap.

The final number:

zero-probe unseen transfer: 0
cheap-probe on real overlap: 4/4
the same cheap-probe on fake overlap: 2/4 = honest abstain, not guessing

The mechanisms that survived (append-only memory, scar logic, cheap-probe consequence checks) are open source: AuraSDK on GitHub. If you have seen a unit of knowledge that passes the falsify-tooth from section 3 and is still not a container — tell me in the comments, I genuinely want to see it.

Can You Build an Alternative to LLMs? 8 Months, ~200 Failed Experiments, One Wall. 2

Oleksander — Sun, 05 Jul 2026 07:22:18 +0000

This is part 2 of a research series documenting an attempt to build something adjacent to — and in some ways alternative to — large language models. Part 1: "My Synthetic Eval Said 30/30. LoCoMo Said 0.13." The code that survived lives in AuraSDK.

Not a chatbot wrapper.

Not another prompt stack.

Not a vector database with a nicer UI.

The question was narrower and more dangerous:

Can a non-neural, CPU-only system accumulate experience, mutate its own internal state, and improve future behavior without retraining an LLM?

After eight months, the honest answer is not "yes".

The honest answer is:

some mechanisms survived,
most carriers failed,
and the wall became precise.

The wall is not storage. Storage is easy.

The wall is transferable causal transition:

condition -> action -> consequence -> when NOT to apply it

That is the thing I kept failing to preserve.

1. What I Mean by "Alternative to LLMs"

The phrase is too broad, so I need to narrow it.

I was not trying to build a new frontier model. I was not training a transformer from scratch. I was not trying to beat GPT-class models at language.

The target was smaller:

Find a knowledge substrate that behaves like a tiny, mutable set of weights.

The required properties were:

it changes after experience;
it survives restart;
it changes future behavior without code changes;
it transfers to unseen but related cases;
it fails shuffled/null controls if the signal is fake;
it is compact in a behavioral sense, not merely compressed bytes;
it abstains when unsupported instead of confidently guessing.

In other words, I was looking for something between memory and weights.

Memory stores what happened.

Weights change what happens next.

The experiment was to find a symbolic or hybrid substrate that could cross that line.

2. Why Normal Memory Was Not Enough

The first tempting answer is always memory:

append the conversation;
summarize it;
store facts;
retrieve relevant chunks;
build a graph;
add embeddings;
add scores;
add typed edges.

All of those are useful engineering tools. None of them automatically become knowledge.

The distinction became brutal:

storage can preserve an event;
knowledge must change the next action.

A log can say:

candidate A failed in situation X
candidate B worked in situation X

But a useful system must do more:

in a new situation X',
recognize what is shared with X,
avoid A-like actions,
try B-like actions,
and know when the analogy no longer applies.

That last line is where most designs died.

3. The Carrier Bakeoff

I tested many candidate "carriers" of knowledge. A carrier is the internal form that is supposed to hold experience and make it reusable.

The early list looked reasonable:

Carrier	What it preserved	Where it failed
append-only memory	event history	did not transfer to unseen cases
surface compression	shorter text	compressed language, not behavior
graph / n-gram links	co-occurrence	became an index, not a causal model
route state	role and expectation	changed behavior, but stayed narrow
typed edges	relation labels	helped only when the relation grammar was already given
graded vectors	magnitude and pressure	carried direction, not an executable mechanism
living cells	local conflict	transferred some signal, but could transfer the wrong action
Jacobian-like footprint	local numeric effect	worked on linear repairs, failed on branching and bit-shift semantics
topology fields	learned attraction basins	signal on synthetic worlds; on real cargo snippets — 0/5 correct, 5/5 abstain

The pattern was consistent.

Each carrier preserved one aspect of consequence:

that something was supported;
that something was refuted;
that a choice had pressure;
that two roles were related;
that a numeric direction changed;
that a local conflict existed;
that a state transition had a shape.

But none of the early carriers preserved the full causal transition.

That is the difference between:

"A was good near B"

and:

"When input has property P and state has condition C,
action A changes state S in direction D,
unless boundary condition B is active."

The second form is much closer to knowledge.

It is also much harder to acquire without already having a model that can do it.

4. Signals That Were Real but Not Enough

Some results were not failures in the simple sense. They were real signals.

One route-state experiment proved that internal state can change behavior without changing code. The system saw support and refutation, mutated its state, and later selected differently. The shuffled-state control failed. That was important.

But it did not prove a replacement for weights. It proved that a narrow symbolic state can influence selection.

Another experiment used graded consequence vectors. The vector was updated by experience, not by gradient training. It showed useful properties:

same direction, more support       -> larger magnitude
50% shared experience              -> similarity ~0.41
0% shared experience               -> similarity ~0.05  (margin 0.35)
support followed by scar evidence  -> direction flipped
random nudges                      -> near-zero similarity

An important detail: 0.41 (not 1.0) on partially shared experience is exactly what real generalization looks like, as opposed to memorization. The similarity emerges from structure; it is not hard-coded. That too was a real signal.

But it was not enough. It carried pressure and similarity. It did not carry the executable rule of when a transition should fire.

The most honest label for these results:

SIGNAL, not solution.

That distinction saved months of self-deception.

5. The "Abstain" Lesson

One of the most useful discoveries was negative:

A weak knowledge carrier should abstain instead of guessing.

In several gates, the system got better when unsupported cases were answered with "I do not know" instead of being forced into the nearest known pattern.

This matters because many memory systems look good only because they always answer. But in a causal system, a wrong transfer is worse than silence.

If a stored pattern says:

this action repaired the previous case

and the new case looks similar but has a different boundary condition, reusing the action can be actively harmful.

The real requirement became:

transfer when supported;
abstain when the binding is not justified;
never convert weak similarity into certainty.

This is where many memory architectures quietly fail. They retrieve something. The model uses it. The answer looks grounded. But the binding between old evidence and the new situation may be invalid.

6. Executable Worlds Made the Failure Sharper

Synthetic gates are useful, but dangerous. If you design the world, you can accidentally design the success.

So part of the testing moved into small executable worlds: code snippets, controlled bugs, compiler feedback, repair attempts, and real pass/fail consequences.

The results became sharper.

A local numeric footprint could transfer part of a lived consequence pattern. It worked when the change was close to a linear repair:

increase this value;
change this numeric boundary;
map this local residual to that local patch.

But it failed on cases that required real mechanism:

bit-shift semantics;
branch behavior;
boundary conditions;
state transitions.

That mattered. Passing a generated linear-repair gate does not mean the system learned code. It means the carrier can reuse a local numeric direction.

The criterion became stricter:

a carrier must survive mixed nonlinear executable snippets:

- numeric delta;
- bit shift;
- boundary condition;
- state transition;
- negative abstain.

If it only passes local-linear repair, it is a helper operator, not a candidate core.

7. The Single-File Brain Attempt

One direction looked especially attractive:

What if the entire learned state lived in one mutable file?

The idea was simple:

The system acts.
The world returns consequences.
The state file mutates.
After restart, the file still changes future behavior.

This was not supposed to be a database. It was supposed to be a growing behavioral substrate.

The result was mixed:

transfer cycle: 3/5
blind baseline: 1/5
wrong: 1

So the file was not dead storage. It grew. It mutated. It transferred some lived transition experience. It beat the blind baseline.

But wrong=1 matters more than the improvement.

The system did not merely abstain on unsupported transfer. It sometimes confidently selected a wrong action. For a knowledge carrier, that is a critical failure.

The diagnosis:

bound transition-cells increased capacity,
but did not preserve enough mechanism.

This is a recurring pattern:

more structure != more knowledge

A richer container can still carry the wrong abstraction.

8. The Wall Became a Binding Problem

After many carrier failures, the question changed.

At first I asked:

Which carrier stores knowledge best?

Later, the better question was:

How does a new situation bind to old experience?

The binding is the hard part.

Suppose the system has learned a useful transition in one world:

node A influences node B
changing A repairs failure F

Now it sees a new world with different node names and a different surface form.

Which node corresponds to A?

Which node corresponds to B?

Which local structure is the same mechanism, and which is only superficially similar?

Without an anchor, this turns into graph matching. In one of the gates I attempted an autonomous bijection between train and heldout worlds directly — and failed exactly here: computing the correspondence required already knowing the correspondence. That is graph isomorphism, NP-hard without an anchor. Not an engineering obstacle — a fundamental one.

This produced the anchor trilemma.

9. The Anchor Trilemma

Every attempted solution fell into one of three buckets.

Option 1: The anchor is given

If a human or a hand-written rule tells the system which parts correspond, transfer becomes much easier.

But then the hard part was not learned. It was supplied.

This can still be useful engineering. It is not an alternative knowledge substrate.

Option 2: The anchor is searched

If the system searches over possible bindings, it can sometimes find the match.

But the search explodes quickly. The more nodes, relations, states, and conditions, the less attractive this becomes.

You have not built cheap knowledge. You have moved the cost into combinatorial search.

Option 3: The anchor is learned by a model

If an LLM, an embedding model, an analyzer, or a world-probing system supplies the binding, the system works much better.

But then the symbolic substrate is no longer the source of the core intelligence. It becomes a memory, a cache, a verifier, or an optimizer around another intelligence source.

That may be a good product.

It is no longer the original hypothesis.

The trilemma:

given anchor    -> not learned
searched anchor -> too expensive or unstable
learned anchor  -> not independent from the model/teacher

This was the wall.

10. What Actually Survived

The failed broad claim was:

A symbolic carrier can become alternative weights by storing enough structured consequences.

That did not survive.

What survived was narrower.

1. Consequence loops matter

The system improves only when it receives world feedback:

try -> observe -> mutate -> retry

Static documents, summaries, and graphs are weak unless tied to consequences.

2. Deterministic guards matter

Some fields must not be entrusted to a generative or fuzzy substrate:

IDs;
dates;
amounts;
names;
paths;
exact constraints;
status changes.

Extract them and preserve them explicitly.

3. World judges matter

The compiler, tests, and executable checks were more honest than internal scores.

They do not care how elegant the architecture is. They return:

pass / fail

4. Abstention is a feature

A weak system that abstains is more useful than a weak system that always transfers.

5. Some organs are still valuable

Route-state, scars, typed relations, date guards, append-only memory, cheap probes, and executable judges are not useless.

They are useful organs.

They are not a full brain.

11. What I Am Not Claiming

I am not claiming I built an alternative to LLMs.

I am not claiming symbolic systems cannot work.

I am not claiming all memory systems are useless.

I am not claiming the wall is mathematically insurmountable in every form.

The honest claim is narrower:

In my experiments, every carrier that tried to preserve knowledge as stored structure eventually failed at transferable causal binding.

And there is an even narrower boundary I have to state myself, before someone states it for me: this is one person working for 8 months on a CPU, not the output of a lab. There may be a carrier I never tried. But 150+ gates kept failing at the same point so consistently that the pattern outweighs any single failure — and that point coincides with why symbolic AI historically lost to learning: the correspondence metric has to be learned, not postulated.

That is still useful.

It prevents wasting another cycle on prettier containers.

12. The Test for Any New Approach

After these failures, a new approach is worth testing only if it clears a stricter bar.

It must:

change future behavior without code changes;
survive restart;
beat shuffled and null controls;
transfer to unseen cases;
abstain on unsupported cases;
preserve exact fields separately;
operate in a world with consequences;
handle nonlinear transitions, not only local numeric repair;
show value over a simple baseline.

And most importantly:

it must carry the transition,
not just an aspect of the transition.

This is the line that killed most of my designs.

13. Why This Still Matters

A negative result is not the same as no result.

Before these experiments, the problem looked like:

find a better memory structure

After the failures, it looks like:

store and transfer executable causal transitions with valid binding

That is a much better problem statement.

It also changes product thinking. A useful system does not need to pretend it replaces an LLM. It can be valuable if it provides:

cheaper long-session memory;
evidence-preserving state;
deterministic guards;
world-verified actions;
refusal to overwrite known scars;
test generation from consequences;
bounded automation around external judges.

Those are real mechanisms.

They just should not be sold as "alternative weights" until they pass the binding wall.

14. Conclusion

The original dream was:

build a CPU-only mutable substrate that behaves like alternative weights

The experiments produced something less glamorous and more useful:

storage is easy;
behavioral mutation is possible;
transfer is fragile;
causal binding is the wall.

The wall is not that the system cannot remember.

The wall is that remembering is not enough.

To act intelligently in a new situation, the system must know what old experience corresponds to, which transition applies, and where the analogy breaks.

That is the part I could not solve with another graph, vector, summary, route state, or mutable file.

The final number:

~200 experiments, 30+ candidate carriers, 1 wall.

Series: "Can You Build an Alternative to LLMs? 8 Months of Experiments, 200 Failures, and One Wall" 1

Oleksander — Thu, 02 Jul 2026 12:59:15 +0000

I tested a simple hypothesis: can long LLM sessions be made cheaper by replacing the full transcript with a compact memory state, without losing answer correctness?

On my own synthetic eval, the system passed 30/30. On an external benchmark for long-term conversational memory, the score collapsed to 0.13. The failure was not caused by one bad prompt. It came from the type of memory being preserved: the local eval tested exact facts, while LoCoMo tested episodic memory.

After several failed approaches, one narrow architecture survived: append-only memory plus deterministic guards for exact fields, especially dates. It is not general-purpose memory, but it produced an honest result: 94% retention with 60% per-query saving on 200 QA.

The main lesson: synthetic evals are useful as regression tests, but dangerous as evidence. If an eval is written around the mechanism being tested, the system can look strong exactly where it proves the least.

1. The Problem

Long LLM sessions are expensive. If every new request receives the entire previous transcript, cost grows with conversation length. The obvious engineering response is to compress the history into a compact state and give the model that state plus the most recent turns.

The hypothesis was:

Compact session state can reduce prompt/context usage without losing answer correctness.

This is attractive. It promises smaller prompts, longer sessions, cheaper agents, and less irrelevant context. But it hides a trap: if the state compresses the wrong type of information, it does not optimize memory. It deletes data.

2. The Local Eval Looked Good

I started with my own 30-case corpus. It covered:

exact facts;
support notes;
CRM-style notes;
coding sessions;
RAG-like context;
mixed-language facts;
preferences and decisions;
negative short-context cases.

Example:

{
  "id": "exact_authorization_code",
  "question": "What is the authorization code? Answer only the code.",
  "expected_fragments": ["RX-4471"]
}

On this corpus, the system looked good. But the first pretty numbers were dry-runs. A dry-run does not call the model: the answer equals the expected fragments by construction. That mode is useful for checking the pipeline, but it is not evidence of quality.

The first full real-model run, after fixing checker artifacts and a mixed-language gap, gave:

corpus:       30 cases
noise:        +40 turns
accuracy:     1.000  (30/30)
effectiveness_rate: 1.000
context_window_saved_pct: 82.86%
false savings: 0
GATE: PASS

This was stronger than a dry-run. But the central problem remained: the corpus was mine. It was written around what the mechanism was already good at preserving.

3. Why Synthetic 30/30 Was Not Enough

The local eval mostly tested exact facts and durable decisions:

codes;
dates in strict formats;
IDs;
file paths;
explicit preferences;
short rules;
"do not forget" facts.

That is important for regression testing. But it is not the same as long-term conversational memory.

Real conversational memory often asks:

when something happened;
what "yesterday" meant relative to a specific session;
how events across several dialogues are connected;
who said what;
what two people have in common;
which fact is needed for an answer even though it is not named in the question.

My local eval tested the type of memory I already knew how to compress. The external benchmark tested what I had not shaped around my own mechanism.

4. LoCoMo Broke the Claim

For an external check, I used LoCoMo: a benchmark for very long-term conversational memory. LoCoMo dialogues average around 300 turns, 9K tokens, and up to 35 sessions. It tests long-term memory through QA, event summarization, and multi-session dialogue understanding.

The first result was harsh:

raw              : 8/15 = 0.53
projected_facts  : 2/15 = 0.13
projected_hybrid : 2/15 = 0.13

The optimized state retained only about a quarter of the correct answers preserved by raw context. The context saving looked excellent: 94-99%.

That was not optimization. It was deletion of needed information.

After adding session timestamps to dialogue lines, the raw baseline improved:

raw              : 0.80
projected_hybrid : 0.20
retained_vs_raw  : 0.25

So the issue did not disappear with a better baseline. It became clearer that the projected state was not preserving the required memory type.

There is an important methodological caveat: the early 0.13 used a strict substring/token checker. Such a checker can miss semantically correct date answers. For example, the gold answer may be the sunday before 25 May 2023, while the model answers 20 May 2023.

But the gap was too large to dismiss as a checker artifact: raw had 8 correct answers, projected had 2.

5. What Failed

After LoCoMo, three failures became visible.

5.1 Static Facts Are Not Episodic Memory

The initial state preserved exact facts well:

codes;
paths;
IDs;
strict dates;
explicit user decisions;
preferences;
constraints.

But it poorly preserved:

event sequence;
relative dates;
"yesterday" relative to a session date;
shared interests;
multi-hop links;
evidence-neighbor context.

LoCoMo asked for episodic memory: who did what, when, where, and how it connects across sessions.

5.2 Lexical Retrieval Was Not Enough

I also tested a retrieval-style approach: instead of compressing everything into one state, select relevant chunks for each question.

Result:

append_full      : 32/60 = 0.533, query saving 45.89%
append_retrieved : 25/60 = 0.417, query saving 90.73%

append_retrieved looked better economically, but quality dropped. The reason is simple: lexical overlap fails when the question and the evidence do not share words.

Typical failures:

"What did Caroline research?" did not retrieve adoption agencies;
a shared-destress question did not retrieve dance;
a martial-arts question did not retrieve Kickboxing, Taekwondo;
temporal and multi-hop questions broke more often.

5.3 Dates Were a Separate Failure Class

At 200 QA, the main gap localized to the temporal category:

raw         : 126/200 = 0.63
append-only : 111/200 = 0.56
retention   : 88%

by category:
multi-hop   : 46 / 45   (~98%)
temporal    : 58 / 46   (~79%)
open-domain : 18 / 16
single-hop  : 4 / 4

This distinction mattered. The memory was not uniformly bad. Temporal anchors were bad.

When the diagnosis is precise, the fix can be precise.

6. Ladder of Attempts

There was no direct jump from the first failure to the final result. Several approaches died for specific reasons.

Approach	Result	Why it failed or narrowed
text compression / projected state	`2/15 = 0.13`	kept exact facts, lost episodic memory
MinHash-style lexical retrieval	`3/15 = 0.20`	lexical overlap missed paraphrase; evidence hit about `42%`
evidence oracle	`0.30` under strict checker	even exact evidence lines did not guarantee date-equivalent substring match
recode-to-notation smoke	`3/3 = 1.00`	small smoke was too optimistic
recode-to-notation larger slice	unstable: `0.35` in one slice, `0.70` vs raw `0.75` under LLM judge in another	interesting signal, not stable enough
append-only without date-guard	`111/200 = 0.56`, retention `88%`	most loss concentrated in temporal questions
append-only + date-guard	`94% retention`, `60% per-query saving`	first narrow result that survived scale better

This table is the real research story. The useful mechanism was not guessed. It survived because prettier mechanisms died first.

7. What Survived

The surviving design had two constraints.

First: do not re-summarize the whole state.

Second: protect exact fields deterministically.

The append-only rule is simple:

Compress only the new exchange.
Freeze the compressed chunk.
Append it to memory.
Never re-compress old chunks.

Why this matters: if old facts repeatedly pass through a compressor, small losses accumulate. If each exchange is compressed once and then frozen, loss cannot compound in the same way.

Early append-only results looked even better than raw: 103% retention on 6 conversations. That was a small-sample artifact. At 200 QA, retention fell to 88%. This was useful: it showed that the architecture helped, but the temporal gap was still real.

8. Date-Guard

The fix was deterministic date protection.

The idea:

extract absolute time expressions;
extract relative time expressions;
attach session date to relative expressions;
append these time anchors to the compressed state.

This does not ask the LLM to be careful with dates. It removes the choice. The compressor can shorten prose, but date anchors survive as explicit fields.

Result on the 200 QA setup:

without guard:
retention        88%
temporal cat     79%
per-query saving 45%

with date-guard:
retention        94%
temporal cat     96%
per-query saving 60%

Saving improved because the prose compressor could become more aggressive once dates were protected separately.

Final honest number:

append-only + date-guard: 94% retention, 60% per-query saving

This is not solved memory. It is not a universal alternative to LLM context. It is a narrow result: append-only compression plus deterministic protection for exact fields.

9. Cost and Scope

This mechanism is not useful for short chats.

On short sessions, fixed overhead can exceed savings:

0 added noise exchanges: projected is worse than raw
1 added noise exchange : projected is still usually worse

Another important distinction: context-window saving and API-cost saving are not the same metric.

One real-provider smoke test showed:

context_window_saved_pct_vs_raw_estimate: 14.61
provider_total_saved_pct_vs_raw: -2.83

The final prompt was smaller, but total provider cost was worse because preparation added calls.

For append-only full on 60 QA:

query_saved_pct_vs_raw   : 45.89%
product_saved_pct_vs_raw : 23.92%
break_even_queries       : 28.72
net_saved_pct_at_200     : 39.30%

So the mechanism is only interesting for long sessions where setup cost can be amortized.

10. Lessons

Lesson 1: Synthetic eval is not evidence by itself

Synthetic eval is useful for regression. It is weak evidence for generalization.

If the author writes the eval around their own mechanism, the system can pass by matching the author's blind spots.

Lesson 2: Compression ratio is a vanity metric without retention

99% context saving is meaningless if answer retention collapses.

The key metric is not "how much did we delete?" but "how much correct behavior survived?"

Lesson 3: Memory is not one thing

Exact facts, preferences, episodic events, temporal anchors, multi-hop relations and source evidence are different memory types.

A compressor can preserve one and destroy another.

Lesson 4: Deterministic guards matter

Some fields should not be entrusted to a generative summary:

dates;
amounts;
IDs;
codes;
names;
statuses;
paths;
constraints.

If losing a field breaks correctness, extract it deterministically and preserve it explicitly.

Lesson 5: Small samples lie

The 103% retention result on 6 conversations looked exciting. At 200 QA it became 88%. The useful signal was not the optimistic number, but the category breakdown showing where the loss happened.

11. Limitations

This is not an academic benchmark paper.

Limitations:

one main external conversational-memory benchmark;
small and medium QA slices before the 200-QA run;
no statistical significance analysis;
some early measurements used strict substring checking;
LLM-judge checks reduce one problem but introduce another;
final 94%/60% should be published with a compact appendix table before being treated as a stable claim.

The result is best read as an engineering research note: a failed broad claim, a localized diagnosis, and a narrower mechanism that survived better tests.

12. Conclusion

The local eval said:

30/30

The external benchmark said:

0.13

The final surviving mechanism said:

94% retention / 60% per-query saving

The important result is not that this "solves memory". It does not.

The important result is that an external benchmark forced the system to stop lying through its own eval. The useful architecture appeared only after the original success story failed.

References

LoCoMo: "Evaluating Very Long-Term Conversational Memory of LLM Agents" — https://arxiv.org/abs/2402.17753
Lost in the Middle: "How Language Models Use Long Contexts" — https://arxiv.org/abs/2307.03172
"Investigating Data Contamination in Modern Benchmarks for Large Language Models" — https://arxiv.org/abs/2311.09783
"Data Contamination Quiz: A Tool to Detect and Estimate Contamination in Large Language Models" — https://arxiv.org/abs/2311.06233

Why AI Needs an External Cognitive Layer Beyond Memory

Oleksander — Thu, 02 Apr 2026 16:30:15 +0000

Why AI Needs an External Cognitive Layer Beyond Memory

Most AI agents today are still built around a thin pattern:

a large language model,
a prompt,
a tool loop,
and some form of memory or retrieval.

That stack can look impressive in demos, but it breaks down once the agent needs continuity, specialization, self-consistency, and long-lived behavioral control.

Memory alone is not enough.

If an agent only stores past records, it can remember what happened. It still cannot reliably:

form stable beliefs,
build concepts over time,
learn causal structure,
accumulate policies,
generate internal pressure,
anticipate future outcomes,
detect epistemic gaps,
or regulate its own mode of operation.

That is the gap we have been exploring in Aura.

The Core Thesis

AI systems need an external cognitive layer that lives outside model weights.

Not just a vector database.
Not just a chat history.
Not just a memory API.

A real cognitive layer should be able to:

preserve continuity across sessions,
accumulate knowledge in structured form,
survive model upgrades,
support domain specialization,
remain inspectable and governed,
and shape agent behavior over time.

This matters because current LLMs are powerful, but they are still weak at stable long-horizon cognition. They are excellent inference engines. They are not yet sufficient as complete cognitive architectures.

From Memory to Cognition

In Aura, the architecture has gradually moved beyond simple memory.

The working progression is:

Record
Belief
Concept
Causal
Policy

That already changes the role of memory.

The system is no longer just storing facts. It is organizing experience into a structured cognitive state.

And once that structure exists, new layers become possible.

The Next Four Cognitive Functions

The recent evolution of the system can be summarized in four steps:

1. Want

The system should not only react to prompts.

It should also detect internal tensions:

unresolved policy pressure,
contradictions,
unstable structure,
pending cognitive obligations.

Those tensions can flow into drives, goals, and imperative-like internal pressure.

That is the beginning of motivation.

2. Expect

A cognitive system should not only remember the past.

It should form expectations about what should happen next.

From stable causal structure, it can produce predictions.
From mismatches between expectation and observation, it can produce surprise.

That turns cognition from retrospective to anticipatory.

3. Wonder

A capable system should not only repair contradictions.

It should also notice what it does not know.

Epistemic gaps matter:

weakly grounded entities,
missing causal mechanisms,
underspecified policy dependencies,
repeated blind spots,
ambiguous concept boundaries.

That is the beginning of curiosity.

4. Regulate

A cognitive system should not always behave in exactly the same mode.

Under pressure, it may need to become more conservative.
Under stability, it may be able to explore.

This is not about emotional theater.
It is about regulation.

A global modulation layer can shape:

drive thresholds,
curiosity thresholds,
exploration budget,
and behavioral selectivity.

That is the beginning of self-regulation.

Why This Should Live Outside the Model

This is the most important architectural point.

If all cognition lives only inside model weights, you lose too much:

portability,
auditability,
versioning,
organization-level control,
inspectability,
and long-lived continuity across changing model generations.

An external cognitive layer can survive:

model upgrades,
shell changes,
deployment changes,
domain swaps,
and organizational adaptation.

That makes it more durable than any single model interface.

Why This Matters Commercially

This is not only a research direction.
It is also a product direction.

A governed external cognitive layer enables:

specialist cognitive bases,
organization-specific overlays,
persistent agent continuity,
safer multi-step behavior,
and explainable adaptation without retraining.

That creates a path beyond generic chat agents.

Instead of selling only an agent, you can sell:

a cognitive substrate,
a specialist module,
and an organization layer that persists over time.

Why This Matters Even If Model Architectures Change

A common objection is:

What if future models already include better internal cognition?

That does not remove the need for an external layer.

Even if models become far more capable, organizations will still need:

governance,
portability,
ownership,
rollback,
specialist control,
and cognition that survives vendor changes.

So the long-term bet is not:

"models will stay weak."

The better bet is:

"portable, governed cognition will still matter even when models get stronger."

The Direction

The future of agent systems is unlikely to be:

model only,
prompt only,
or memory only.

It will likely require a distinct cognitive layer that can:

accumulate structured knowledge,
generate internal motivational pressure,
anticipate,
explore,
regulate,
and remain externally governed.

That is the direction we think is worth building toward.

Not just better memory for AI.

A real cognitive layer beyond memory.

I am currently building and testing this cognitive architecture in a closed environment. If you are an AI architect, researcher, or founder hitting the limits of RAG and standard agent loops, my DMs are open. I’d love to compare notes on the future of autonomous cognition.

Pennsylvania State found why AI memory fails across models. AuraSDK doesn't have this problem.

Oleksander — Fri, 27 Mar 2026 16:52:05 +0000

Pennsylvania State University just published a paper that exposes a structural flaw in how most AI agent memory systems work.

The paper is called MemCollab: Cross-Agent Memory Collaboration via Contrastive Trajectory Distillation. The findings are uncomfortable if you're building agent memory the conventional way.

The flaw

Most agent memory systems work like this:

Model solves a problem
Memory stores the reasoning trace — what the model did, how it got there
Model retrieves that memory later and performs better

The assumption buried inside this design: the stored knowledge is about the task, not about the model that solved it.

Pennsylvania State tested whether that assumption holds.

They gave a 7B model's memory to a 32B model. MATH500 dropped from 63.8% to 50.6%. HumanEval dropped from 68.3% to 34.1%.

Then they gave the 32B model's memory to the 7B model. Performance dropped again. Both directions failed. Both fell below the zero-memory baseline.

Giving a model someone else's memory made it perform worse than having no memory at all.

Why this happens

A model's reasoning traces don't just capture what the correct answer required. They capture how that specific model thinks — its preferred solving strategies, its heuristic shortcuts, its stylistic patterns.

Memory distilled from those traces encodes the model's reasoning personality alongside the actual task knowledge. When a different model retrieves that memory, it gets handed instructions optimized for a completely different cognitive architecture. The guidance actively interferes.

What MemCollab does

MemCollab fixes this by making memory construction cross-model. Two agents — a smaller and a larger model — independently solve the same problem. One succeeds, one fails. The system contrasts the trajectories and extracts only the abstract invariants:

What reasoning principle was present in the success and violated in the failure?
What error pattern appeared in the failure that the success avoided?

The extracted memory stores only those rules — not the solution, not the reasoning style, not the model-specific heuristics.

Results:

Llama 3 8B: MATH500 from 27.4% → 42.4%
Qwen 7B: MATH500 from 52.2% → 67.0%, HumanEval from 42.7% → 74.4%
Reasoning turns cut from 3.3 → 1.5 on HumanEval (fewer dead ends)

The deeper insight

The efficiency finding is the one that gets overlooked. MemCollab doesn't just improve accuracy — it makes agents reach correct answers in fewer steps. The contrastive memory isn't adding more guidance. It's stripping out the noise that was making agents explore dead ends repeatedly.

By encoding what not to do as explicitly as what to do, the memory prunes the search space before the agent even starts.

Why AuraSDK doesn't have this problem

AuraSDK avoids the contamination problem structurally — by never storing reasoning traces at all.

When you store something in AuraSDK:

brain.store(
    "Staging deploy prevented 3 production incidents",
    semantic_type="fact",
    tags=["workflow", "deployment"]
)

You're storing a claim about the world, not a record of how a model reasoned about it. The cognitive layers — Belief, Concept, Causal, Policy — are derived from the content of what was observed, not from the model's processing of it.

Record → Belief → Concept → Causal → Policy

Each layer is built deterministically from the one below. Beliefs emerge from clusters of records. Causal patterns emerge from temporal co-occurrence and explicit links. Policy hints emerge from repeated causal patterns. None of this touches model internals.

The result: the cognitive layer is model-agnostic by design. Swap GPT-4o for Claude, swap Claude for Llama — the stored memory, the belief structure, the causal patterns, the policy hints all remain valid. There's nothing model-specific to contaminate.

Two different approaches to the same insight

MemCollab and AuraSDK arrive at the same conclusion from different directions:

Memory that encodes how a model thinks is fragile. Memory that encodes what happened is durable.

MemCollab fixes contamination after the fact — by contrasting two models' traces and extracting only what survived.

AuraSDK avoids contamination by construction — by never storing traces in the first place.

	MemCollab	AuraSDK
What's stored	Abstract reasoning invariants across models	Claims, facts, relationships
Requires LLM to build memory	Yes — two models per problem	No
Model-agnostic	Yes — by contrastive distillation	Yes — by design
Works offline	No	Fully
Recall latency	LLM-bound	0.076ms
Cognitive layers	None	Belief → Concept → Causal → Policy
Open source	Research paper	MIT, ships today

What this means for the field

The Pennsylvania State paper validates something important: the right unit of memory is not a reasoning trace. It's the abstract principle that holds regardless of which model does the reasoning.

AuraSDK takes this further: the right unit of memory is a structured observation about the world — a fact, a decision, a contradiction, a preference — that any model can retrieve and use without being handed someone else's cognitive fingerprint.

The field is converging on this. The implementations differ. But the core insight is the same.

pip install aura-memory

GitHub

Google's TurboQuant solves half the AI memory problem. Here's the other half.

Oleksander — Wed, 25 Mar 2026 16:49:10 +0000

This week Google Research published TurboQuant — a two-stage KV-cache quantization algorithm that achieves 6x memory reduction and 8x attention speedup with zero accuracy loss at 3 bits. No training required.

It's genuinely impressive engineering. But it's worth being precise about what problem it solves.

The two AI memory problems

Most people conflate two distinct problems:

Problem A: memory within a session
As context grows, the KV-cache grows. It becomes expensive in RAM and slow in attention computation. TurboQuant solves this — brilliantly.

Problem B: memory between sessions
When the session ends, the KV-cache is gone. The model starts from zero next time. No memory of past interactions, no accumulated patterns, no structured experience. TurboQuant doesn't touch this.

What TurboQuant actually does

TurboQuant is a two-stage pipeline:

PolarQuant — rotates vectors randomly, converts to polar coordinates, quantizes components without needing per-block normalization constants. This eliminates the 1–2 bit overhead that traditional quantization methods carry.
QJL (Quantized Johnson-Lindenstrauss) — encodes residual error with a single sign bit. Zero memory overhead.

Result: 3-bit KV-cache, 6x compression, 8x speedup, zero accuracy degradation on LongBench, Needle-in-a-Haystack, RULER, and ZeroSCROLLS benchmarks.

This makes long-context inference significantly cheaper and faster. Real value.

The gap it leaves open

The moment the session ends — the KV-cache is gone.

Week 1 with any model: average answers.
Week 4 with any model: still average answers. It forgot everything.

Fine-tuning costs thousands of dollars and weeks. RAG gives you retrieval, not cognition. Context windows bill per token and still reset.

What we built for Problem B

AuraSDK is a local cognitive substrate that sits outside model weights.

It accumulates structured experience across sessions through a 5-layer pipeline:

Record → Belief → Concept → Causal → Policy

Each layer is derived deterministically from the one below — no LLM, no embeddings. Policy hints like "deploy to staging first" aren't written by anyone. They emerge from repeated causal patterns in stored experience.

from aura import Aura

brain = Aura("./agent_memory")

brain.store("Staging deploy prevented 3 production incidents", tags=["workflow"])
brain.store("User always deploys to staging first", tags=["workflow"])

# after run_maintenance(), the cognitive stack derives:
hints = brain.get_surfaced_policy_hints()
# → [{"action": "Prefer", "domain": "workflow", "description": "deploy to staging first"}]

What v1.5.4 adds:

Autonomous cognitive plasticity — the substrate observes model output and updates itself. No fine-tuning. Full audit trail.
Salience weighting — what matters persists longer, decays slower
Contradiction governance — conflicting evidence surfaced explicitly, not averaged silently

Performance (1,000 records, Ryzen 7, v1.5.4):

Store: 0.91ms
Recall: 0.076ms (~2,600× faster than Mem0)
Recall (cached): 1.4µs
Maintenance cycle: 15ms median

No API keys. No cloud. No LLM dependency. ~3MB binary. Fully offline. MIT license.

The full picture

	TurboQuant	AuraSDK
Problem	KV-cache overhead within session	No memory between sessions
Approach	Quantization of attention keys/values	Persistent cognitive substrate
Scope	Single inference pass	Cross-session accumulation
Requires LLM	Yes (runs inside it)	No
Works offline	N/A	Fully
Open source	Research paper	MIT, ships today

These are complementary. TurboQuant makes inference cheaper in the moment. AuraSDK makes the model smarter over time.

The field needs both.

pip install aura-memory

GitHub ·

Your AI forgets everything — this layer fixes that without retraining

Oleksander — Tue, 24 Mar 2026 16:19:10 +0000

Your AI model forgets everything after every conversation.

Not because it’s bad — because it has no memory system.

RAG helps retrieve context.
Fine-tuning helps adjust behavior.

But neither actually gives your system memory.

This article shows a different approach:
a cognitive layer that sits outside the model
and gets smarter over time — while the model stays frozen.

What the cognitive layer actually does

AuraSDK builds a 5-layer structure from whatever the model and users store:

Record → Belief → Concept → Causal → Policy

Each layer is derived from the one below — without LLM, without embeddings, locally:

Record: raw stored fact with trust score, provenance, decay rate
Belief: competing hypotheses about the same claim, epistemically weighted
Concept: stable abstractions over repeated beliefs
Causal: learned cause→effect patterns from co-occurring evidence
Policy: advisory hints — Prefer, Avoid, Warn — that emerge from causal structure

Nothing in layers 2–5 is hand-authored. They emerge from what's stored and observed over time.

from aura import Aura, Level

brain = Aura("./memory")
brain.enable_full_cognitive_stack()

brain.store("Staging deploy prevented 3 production incidents", tags=["deploy"])
brain.store("Direct prod deploy caused outage in Q3", tags=["deploy"])

# After maintenance:
hints = brain.get_surfaced_policy_hints()
# → [{"action": "Prefer", "domain": "deploy", "description": "staging before production"}]

That policy hint was not written by anyone. The causal layer found the pattern. The policy layer surfaced it.

v1.5.4: the three things that were missing

1. The substrate now learns from the model's own output

Before v1.5.4, the cognitive layer only knew what you explicitly stored. Now it observes model responses and updates itself.

Claims are extracted. Confirmations strengthen existing beliefs. Contradictions raise volatility. The substrate evolves from inference — without retraining, without an external API.

capture = brain.capture_experience(
    prompt="How should we handle this deploy?",
    retrieved_context=context_ids,
    model_response="Always verify staging health checks before pushing to production.",
    source="model_inference",
)
brain.ingest_experience_batch([capture])
brain.run_maintenance()
# cognitive layer updated — next recall is different

Safety bounds (non-negotiable):

Generated claims capped at 0.70 confidence — cannot overwrite recorded facts
PlasticityMode::Off by default — nothing changes without explicit opt-in
Every mutation writes to an audit trail traceable to the prompt that caused it
purge_inference_records() — clean rollback when needed
freeze_namespace_plasticity("medical") — some domains must never adapt from inference

Recorded facts always win over model inference. Always.

2. The substrate now knows what matters

High-frequency recall and high-significance are not the same thing. A trivial fact mentioned 20 times should not outrank a critical decision mentioned once.

v1.5.4 adds salience weighting:

brain.mark_record_salience(record_id, salience=0.9)
# → this record resists decay, ranks higher, gets preserved longer

Maintenance now also produces bounded reflection summaries: recurring blockers, unresolved tensions, patterns that keep appearing. Not "feelings" — structured synthesis from what's actually stored.

3. Contradictions are now first-class, not silently averaged

Before: conflicting evidence was weighted and averaged. The conflict was invisible.

Now:

clusters = brain.get_contradiction_clusters()
queue = brain.get_contradiction_review_queue()

Recall explanations carry explicit markers: "this recommendation depends on unresolved evidence." The operator sees the friction. The user can be told honestly.

What else ships in v1.5.4

Concept persistence — concepts used to reset on every restart. Now they survive. The 5-layer stack is actually intact across sessions.

Belief reranking active by default — in v1.5.3, BeliefRerankMode::Off was the default. The cognitive stack was engineered but not running. Now it runs.

Production integrity — startup validation, persistence manifest, concept partition cap for large corpora.

Explainability is built in

Every recall decision is traceable:

explanation = brain.explain_recall("deployment decision")
# → which records matched, why, what belief groups they belong to,
#   what salience contributed, whether unresolved evidence is present

chain = brain.provenance_chain(record_id)
# → full trace from policy hint back to source records

This is not logging. It is structural explainability derived from the cognitive layer itself.

Performance

Benchmarked on 1,000 records, Windows 10 / Ryzen 7:

Operation	Latency	vs Mem0
Store	0.09 ms	~same
Recall	0.74 ms	~270× faster
Recall (cached)	0.48 µs	~400,000× faster
Maintenance	1.1 ms	no equivalent

Mem0 recall requires an embedding API call (~200ms+). AuraSDK recall is pure local computation. No embeddings required. No external service.

The positioning in one sentence

AuraSDK is not a vector database. Not a RAG wrapper. Not a fine-tuning platform. Not a generic agent framework.

It is a governable cognitive substrate for frozen AI models — the layer that makes them smarter, more consistent, and more explainable over time, without touching their weights.

Try it

pip install aura-memory

Try in browser (no install): Open in Colab

GitHub: teolex2020/AuraSDK — MIT license, patent pending (US 63/969,703)

Built in Kyiv, Ukraine 🇺🇦

What would you build with a model that actually accumulates structured experience over time?

I tested the same AI model against itself. Memory won 4/5.

Oleksander — Wed, 18 Mar 2026 13:23:16 +0000

The experiment

Same model. Same 5 questions. One difference: one side had persistent memory via AuraSDK, the other had none.

Both sides used Gemini 2.5 Flash-Lite — identical model, identical cost per token.

Result: 4/5 questions won by the side with memory. 48% fewer tokens used.

What the questions tested

Real Python dev scenarios — the kind where generic answers aren't enough:

"I'm writing a new async function to fetch user orders from the DB. What patterns should I follow?"
"We need background email sending when an order is completed. How should we implement it?"
"I'm writing tests for the new payment module. Walk me through the setup."
"Code review: results = list(db.query(Order).filter(...)) — what's wrong?"
"The reports endpoint is slow — 3 seconds for 200 users. How do I debug and fix this?"

These questions have correct generic answers. But they also have specific answers — if you know the team's stack.

What the model with memory knew

AuraSDK had loaded 15 records of accumulated team knowledge:

We use arq for task queues, not Celery — switched because Celery was too heavy
Production incident: missing await on async DB call silently returned a coroutine. 2 hours to debug.
SQLAlchemy lazy loading doesn't work with async sessions — always use selectinload() or joinedload()
Code review caught: someone did list(queryset) and loaded 50k rows into memory. Lint rule added.
N+1 queries found in the user reports endpoint — fixed with a single joined query
Test setup: pytest + pytest-asyncio, transactions that rollback after each test, coverage must stay above 85%

What happened question by question

Q2 — Background email sending:

With memory (1,307 tokens):

"Use arq — we switched from Celery because it was too heavy for our scale. Define an arq job decorated with @arq.func, enqueue it when order completes."

Without memory (3,203 tokens):

"Here are several approaches: FastAPI BackgroundTasks for simple cases, Celery for robust production use..."

Same model. One knew the decision. One gave a textbook overview.

Q4 — Code review:

With memory (829 tokens):

"This is a direct violation of our established practice. We had an incident where this loaded 50,000 rows into memory. A lint rule was added specifically to prevent this."

Without memory (1,604 tokens):

"This is generally considered an anti-pattern in SQLAlchemy. Here's a breakdown of what's wrong..."

How AuraSDK works

from aura import Aura, Level

brain = Aura("./agent_memory")
brain.enable_full_cognitive_stack()

# store team knowledge
brain.store("We use arq, not Celery — switched because Celery was too heavy",
            level=Level.Domain, tags=["python", "dev"])
brain.store("Production incident: list(queryset) loaded 50k rows into memory",
            level=Level.Decisions, tags=["python", "lesson-learned"])

# recall before answering — <1ms, no API call
context = brain.recall("background email sending", token_budget=1000)

# inject into prompt
system = f"TEAM CONTEXT:\n{context}\n\nAnswer using this context."

No embeddings. No vector database. No LLM calls during learning. Pure local Rust computation.

The cognitive pipeline

AuraSDK doesn't just store and retrieve text. Every record goes through 5 layers:

Record → Belief → Concept → Causal → Policy

Belief: groups related observations, resolves contradictions with confidence scores
Concept: discovers stable topic clusters across beliefs
Causal: finds cause-effect patterns from temporal and explicit links
Policy: derives behavioral hints (Prefer / Avoid / Warn) from causal patterns

After enough interactions, the system surfaces this automatically:

hints = brain.get_surfaced_policy_hints()
# [{"action": "Prefer", "domain": "dev", "description": "use arq over celery for task queues"}]

Nobody wrote that rule. The system derived it from the pattern of stored observations.

The token math

	With memory	Without memory
Q1	1,200 tokens	1,545 tokens
Q2	1,307 tokens	3,203 tokens
Q3	1,923 tokens	4,067 tokens
Q4	829 tokens	1,604 tokens
Q5	1,294 tokens	2,155 tokens
Total	6,553 tokens	12,574 tokens

48% fewer tokens. The memory layer doesn't add bloat — it gives the model exactly what it needs.

How it compares

	AuraSDK	Mem0	Zep	Letta
LLM required for learning	No	Yes	Yes	Yes
Works offline	Fully	Partial	No	With local LLM
Recall latency	<1ms	~200ms+	~200ms	LLM-bound
Self-derives behavioral policies	Yes	No	No	No
Binary size	~3MB	~50MB+	Cloud	Python pkg

Try it

pip install aura-memory
python examples/demo.py

Open source: github.com/teolex2020/AuraSDK
Patent pending: US 63/969,703
Built in Kyiv, Ukraine.

I built a cognitive layer for AI agents that learns without LLM calls

Oleksander — Tue, 17 Mar 2026 12:19:42 +0000

The problem

Every time your agent starts a conversation, it starts from zero.

Sure, you can stuff a summary into the system prompt. You can use RAG. You can call Mem0 or Zep.

But all of these have the same problem: they need LLM calls to learn. To extract facts, to build a user profile, to understand what matters — you're paying per token, adding latency, and depending on a cloud service.

What if the learning happened locally, automatically, without any LLM involvement?

What AuraSDK does differently

AuraSDK is a cognitive layer that runs alongside any LLM. It observes interactions and — without any LLM calls — builds up a structured understanding of patterns, causes, and behavioral rules.

from aura import Aura, Level

brain = Aura("./agent_memory")
brain.enable_full_cognitive_stack()

# store what happens
brain.store("User always deploys to staging first", level=Level.Domain, tags=["workflow"])
brain.store("Staging deploy prevented 3 production incidents", level=Level.Domain, tags=["workflow"])

# sub-millisecond recall — inject into any LLM prompt
context = brain.recall("deployment decision")

# after enough interactions, the system derives this on its own:
hints = brain.get_surfaced_policy_hints()
# [{"action": "Prefer", "domain": "workflow", "description": "deploy to staging first"}]

Nobody wrote that policy rule. The system derived it from the pattern of stored observations.

The cognitive pipeline

AuraSDK processes every stored record through 5 layers:

Record → Belief → Concept → Causal → Policy

Each layer is bounded and deterministic:

Belief: groups related observations, resolves contradictions
Concept: discovers stable topic clusters across beliefs
Causal: finds cause-effect patterns from temporal and explicit links
Policy: derives behavioral hints (Prefer / Avoid / Warn) from causal patterns

The entire pipeline runs in milliseconds. No LLM. No cloud. No embeddings required.

Try it in 60 seconds

pip install aura-memory
python examples/demo.py

Output:

Phase 4 - Recall in action

  Query: "deployment decision"  [0.29ms]
    1. Staging deploy prevented database migration failure
    2. Direct prod deploy skipped staging -- caused data loss

  Query: "code review"  [0.18ms]
    1. Code review caught SQL injection before merge
    2. Code review found performance regression early

5 learning cycles completed in 16ms. Recall at 0.29ms.

How it compares

	AuraSDK	Mem0	Zep	Letta
LLM required for learning	No	Yes	Yes	Yes
Works offline	Fully	Partial	No	With local LLM
Recall latency	<1ms	~200ms+	~200ms	LLM-bound
Self-derives behavioral policies	Yes	No	No	No
Binary size	~3MB	~50MB+	Cloud	Python pkg

What's new in v1.5.3

Full 5-layer cognitive pipeline active by default
enable_full_cognitive_stack() — one call to activate everything
Decay now driven by memory level, not manual type labels
Policy hints now work with explicit causal links (link_records())
demo.py — see it working in 60 seconds

Built in Rust, from Kyiv

Pure Rust core. No Python dependencies for the engine. Patent pending (US 63/969,703).

Open source: github.com/teolex2020/AuraSDK
Install: pip install aura-memory
Web: aurasdk.dev

If you're building AI agents and want deterministic, explainable, offline-capable memory — give it a try and tell me what you think.

10x Faster Recall + Memory That Evolves: Aura v1.3 for AI Agents

Oleksander — Thu, 05 Mar 2026 09:42:48 +0000

The Problem

Every AI agent framework has the same weakness: memory is an afterthought. Most solutions dump everything into a vector database and hope cosine similarity finds the right context. This works until it doesn't — when your agent needs to know when it learned something, what changed since last week, or which memories are actually useful.

What Aura Does Differently

Aura is a pure-Rust cognitive memory engine. Instead of embeddings + vector search, it uses:

SDR Encoding (Sparse Distributed Representations) — biologically-inspired, noise-tolerant
RRF Fusion — 4 parallel ranking signals (SDR similarity, MinHash, Tag Jaccard, optional embeddings)
Temporal Decay — memories naturally fade unless reinforced
Graph Connections — associative, causal, and co-activation links between memories

The result: sub-millisecond recall, ~3MB binary, zero external dependencies.

10x Recall Speedup (v1.3.1)

Every recall_structured call was cloning ALL records into a new HashMap to filter by namespace. At 10K records, that's 94ms of pure waste.

Fix: pass the original HashMap through the pipeline. Each signal collector filters by namespace inline with a cheap contains() check. Plus a new StructuredRecallCache for repeated queries.

Records	Before	After	Speedup
1K	15 ms	2.6 ms	5.8x
5K	58 ms	5.1 ms	11.4x
10K	94 ms	8.6 ms	10.9x

Warm recall (cache hit): ~0.07 ms — constant time regardless of record count.

What's New in v1.3.0

1. Temporal Queries

from aura import Aura
import time

brain = Aura("./memory")
brain.store("User prefers dark mode", level="Domain")

# ... days pass, user changes preference ...
brain.supersede(old_id, "User prefers light mode")

# What did we know last week?
old_memories = brain.recall_at("user preferences", last_week_timestamp)

recall_at(query, timestamp) filters records by creation time. history(record_id) shows the full access/strength timeline. This is how you debug agent behavior — "why did it do X on Tuesday?"

2. LangChain Drop-In

from aura import Aura
from aura.langchain import AuraMemory

brain = Aura("./memory")
memory = AuraMemory(brain)

# Works with any LangChain chain
chain = ConversationChain(llm=llm, memory=memory)

AuraChatMessageHistory implements the full BaseChatMessageHistory interface. AuraMemory is duck-type compatible with ConversationBufferMemory. No changes to your existing code.

3. Adaptive Recall

# After recall, tell Aura what was useful
results = brain.recall_structured("deployment steps", top_k=5)
for score, record in results:
    if was_helpful(record):
        brain.feedback(record.id, useful=True)   # +0.1 strength
    else:
        brain.feedback(record.id, useful=False)  # -0.15 strength

Over time, noise naturally decays while valuable memories get reinforced. No other memory SDK has this built-in.

4. Memory Versioning

# Save state before experiment
brain.snapshot("before_refactor")

# ... agent does things ...

# Something went wrong? Roll back
brain.rollback("before_refactor")

# Or compare states
diff = brain.diff("before_refactor", "after_refactor")
print(f"Added: {diff['added']}, Removed: {diff['removed']}")

5. Agent-to-Agent Sharing

# Agent A exports relevant context
fragment = agent_a.export_context("user preferences", top_k=5)

# Agent B imports it (strength halved, tagged "shared")
agent_b.import_context(fragment)

The protocol envelope includes version and provenance metadata. Imported records arrive with reduced trust — they need to prove themselves.

6. C FFI — Aura as a Platform

#include "aura.h"

AuraHandle* h = aura_open("./memory");
aura_store(h, "Remember this", NULL, NULL);

char* result = aura_recall(h, "what to remember", 5);
printf("%s\n", result);
aura_free_string(result);
aura_close(h);

Working examples in Go and C#. Any language with C FFI can use Aura.

7. OpenTelemetry

[features]
telemetry = ["opentelemetry", "opentelemetry_sdk", "opentelemetry-otlp", "tracing-opentelemetry"]

17 key functions instrumented with #[instrument] spans. OTLP export to any collector. Grafana dashboard template included.

The Bug That Took 8 Hours

Fun story: our CI was timing out at 6+ hours. We tried increasing timeouts, switching to release builds, reducing the test matrix. Nothing worked.

Turns out: Aura struct didn't have a Drop implementation. When tests ended without calling close(), internal file handles wouldn't release. Each test hung for 5 minutes waiting for a timeout that never came. 28 tests x 5 min = CI death.

Fix: 9 lines of code.

impl Drop for Aura {
    fn drop(&mut self) {
        self.stop_background();
        let _ = self.flush();
        let _ = self.storage.flush();
        let _ = self.index.save();
    }
}

Now 503 tests pass in 7 minutes. Sometimes the hardest bugs are the simplest ones.

Try It

pip install aura-memory

from aura import Aura

brain = Aura("./my_agent_memory")
brain.store("User prefers concise answers", level="Identity")

context = brain.recall("how should I respond?")
# Returns formatted context for your LLM's system prompt

Star the repo if this is useful. PRs and issues welcome.