Chapter 10: Cross-Model Universality

Positioning: The previous two chapters derived AAAK’s design constraints and specific grammar, respectively. This chapter addresses a deeper question: why can AAAK be understood by any text model? This is not an accidental side effect but a necessary result explainable from a linguistic perspective. And what product implications does this technical property carry – the decoupling of the memory system from model vendors.

An Unexpected Discovery

In early 2026, when MemPalace’s benchmark results were published, the tech community’s first reaction focused on the scores themselves – a perfect score on LongMemEval, 96.6% with zero API calls. But a question that subsequently emerged may deserve more attention: are these results tied to Claude? If you switched to GPT-4, Gemini, or a completely offline Llama model, would AAAK still work?

MemPalace’s README gave an answer so concise it bordered on provocative:

Works with: Claude, ChatGPT, Gemini, Llama, Mistral – any model that reads text.

“Any model that reads text.” This is not marketing hyperbole but a technical assertion that can be rigorously argued from design principles. Understanding why it holds requires returning to the fundamental level of linguistics.

The Linguistic Explanation: Omission Rather Than Invention

AAAK’s fundamental difference from other AI-specific formats is that it invents nothing new.

Consider some formats that require specific models or specific training to understand:

• Vector embeddings: A 768-dimensional vector generated by Model A is a meaningless sequence of numbers to Model B. Because embedding spaces are products of model training, there is no correspondence between different models’ embedding spaces.
• Special tokens: Some systems use custom tokens (such as <memory> or [FACT]) to mark information types. These tokens are only effective in models trained to recognize them.
• Function call formats: OpenAI’s function call syntax (JSON-structured function_call) can only be correctly processed by models trained to support this format.

The common thread among these formats is that they add a new layer of convention on top of natural language. The receiver must “know” this convention in advance to correctly interpret the content.

AAAK takes the opposite direction. It does not add new rules on top of English but removes redundancy from English. Let us analyze this process through a concrete example:

First layer of removal – function words:

Original:    Priya manages the Driftwood team
First layer: Priya manages Driftwood team
Removed:     the

The article “the” functions here to mark “Driftwood team” as definite. But when “Driftwood” is itself a proper noun, this marker is entirely redundant – there is no “other Driftwood team” to distinguish.

Second layer of removal – verb morphology:

First layer: Priya manages Driftwood team
Second layer: Priya lead Driftwood
Removed:     manages (replaced with role label lead), team (inferable from context)

The verb “manages” tells us Priya holds a leadership role. Directly substituting the role label lead preserves the information with fewer tokens. “Team” can be inferred from AAAK’s TEAM: prefix.

Third layer of removal – full names:

Second layer: Priya lead Driftwood
Third layer: PRI(lead) DRIFTWOOD
Removed:     riya (the trailing characters of the name)

The first three letters “PRI” of “Priya” are sufficient to uniquely identify this person in the given context. The subsequent “ya” carries no additional distinguishing information.

Every layer removes components of English that “help humans process but carry no independent information.” Not a single step involves inventing new grammar rules or symbol systems. The final result PRI(lead) DRIFTWOOD is still – from a linguistic standpoint – English. An extremely condensed, grammatically stripped-down English, but English nonetheless.

This is the fundamental reason for AAAK’s cross-model universality: any model that can read English can read AAAK, because AAAK is English.

Linguistic Boundaries of Omission

Of course, not all omissions are safe. Linguistics draws a critical distinction: recoverable ellipsis and unrecoverable ellipsis.

Recoverable ellipsis means the receiver can reconstruct the omitted component from context. “Who’s coming?” “Me.” – here “am coming” is omitted from “I am coming,” but the listener can recover it without difficulty.

Unrecoverable ellipsis means the omitted information cannot be inferred from context. If the original text is “Kai has been working with Priya for three years on backend systems, and he recommended Clerk because of its superior developer experience and competitive pricing,” compressing it to “KAI rec Clerk” is unrecoverable ellipsis – the three-year working relationship and the specific reasons for the recommendation are lost.

AAAK’s grammar design strictly limits itself to the domain of recoverable ellipsis. KAI(backend,3yr) omits “is a,” “developer,” “with,” and “of experience” from “Kai is a backend developer with 3 years of experience,” but all these words can be automatically recovered by the model from the structure of (backend,3yr). KAI.rec:clerk>auth0(pricing+dx) omits substantial vocabulary from “Kai recommended Clerk over Auth0 based on pricing and developer experience,” but every omitted component can be inferred from the preserved structure: .rec = recommended, : = object separator, > = over/preferred to, (pricing+dx) = based on pricing and developer experience.

And unrecoverable information – such as Kai and Priya having worked together for three years – is not omitted; it is preserved in the form of 3yr.

This principle of “only performing recoverable ellipsis” corresponds directly to Chapter 8’s Constraint 2: factual completeness as a design ideal. Stated in linguistic terms, that means omissions are acceptable only when they remain recoverable from structure.

Guaranteeing Recoverability: Who Does the Recovering?

Recoverable ellipsis has a critical prerequisite: there must be a “recoverer” with sufficient knowledge to reconstruct the omitted components. In human conversation, this recoverer is the listener, relying on shared linguistic and world knowledge. In AAAK’s scenario, this recoverer is the large language model.

The question then becomes: do different models possess the same recovery ability?

The answer is: for the types of omission AAAK uses – yes.

The recovery abilities AAAK depends on can be divided into three categories:

Grammatical recovery – recovering “Kai is a backend developer” from KAI(backend). This requires the model to understand the pattern “name followed by parentheses indicates attributes.” All major large language models have seen extensive instances of this pattern in training data (function calls in programming languages, parameter descriptions in technical documentation, attribute listings in encyclopedia entries), making this a universal text comprehension capability.

Lexical recovery – recovering “recommended” from rec, “3 years” from 3yr. This requires the model to understand common English abbreviation patterns. Again, all models have seen extensive abbreviations in training data (msg = message, yr = year, info = information), making this a fundamental language capability.

Structural recovery – recovering “there is a team, PRI is the lead, KAI does backend” from TEAM: PRI(lead) | KAI(backend). This requires the model to understand pipe delimiting and hierarchical structure. As discussed earlier, pipe delimiting appears extensively in command-line output, Markdown tables, and similar formats, and all models possess this understanding.

These three categories of recovery ability share a common characteristic: they do not depend on any specific model’s proprietary training. They are universal capabilities learned from general text corpora. Any model trained on Common Crawl, Wikipedia, GitHub, and other standard corpora – that is, any mainstream large language model – possesses these capabilities.

This is why MemPalace can confidently claim AAAK “works with any model that reads text.” Not because compatibility testing was performed on every model, but because the capabilities it depends on represent the greatest common denominator of all models.

Product Implications: Decoupling

Technical properties do not create value in themselves – value comes from the product possibilities that technical properties enable. The most important possibility enabled by AAAK’s cross-model universality is: complete decoupling of the memory system from model vendors.

What Decoupling Means

In the current AI application ecosystem, memory is typically deeply bound to the model. Using OpenAI’s memory feature means your memories are stored on OpenAI’s servers, accessible only through OpenAI’s API. Switching to Claude means starting from zero – your history, your preferences, the context you accumulated over six months, all reset.

This binding is a form of implicit lock-in. You might want to switch models because a competitor is cheaper, faster, or better at a particular task, but the switching cost is too high – not the technical cost, but the knowledge cost. Everything your AI assistant “knows” about you is locked inside one vendor’s walled garden.

AAAK breaks this binding. Because AAAK text can be understood by any model, your memories become a portable asset. Use Claude today, GPT-4 tomorrow, a local Llama the day after – as long as you provide the same AAAK text to the new model, it can recover the same compact representation of your context. The README uses roughly 120 tokens to describe that compressed context size; that is AAAK’s target advantage as a format, not the measured default output of today’s wake-up path.

This is not merely a theoretical possibility. MemPalace’s architecture already supports the underlying portability claim: ChromaDB is stored locally, AAAK itself is plain text, and MCP tools plus CLI search are not bound to any specific model. More precisely, the current repository has already proven “AAAK as portable cross-model text,” while the default wake-up entry point still mainly emits raw-text L0 + L1; once AAAK is fully wired into the wake-up path, switching friction falls even further.

A Fully Offline Memory Stack

AAAK’s cross-model universality, combined with MemPalace’s local architecture, produces an even more radical possibility: once local dependencies and default embedding assets are prepared, the entire memory stack can run completely offline.

Consider this tech stack:

• Storage: ChromaDB, running on the local machine, no network required
• Model: Llama 3 or Mistral, running locally via llama.cpp or Ollama
• Compression: AAAK, pure Python implementation, zero external dependencies
• Search: ChromaDB’s built-in vector search, local embedding model

More precisely: once local dependencies and default embedding assets are already in place, ingestion, storage, search, and context loading no longer require internet connectivity. No required API calls, no required cloud services, no mandatory data leaving your machine.

This property holds extremely high value for specific user groups. Enterprises handling sensitive data (legal, medical, financial) cannot send memory data to third-party servers. Security researchers do not want their work records appearing in anyone’s training data. Developers working in environments with unreliable networks need a memory system that does not depend on network connectivity.

For these scenarios, “offline” is not a degraded option – it is a hard requirement. AAAK makes satisfying this requirement possible – not by sacrificing functionality, but through an architecture that by design needs no online components.

No Vendor Lock-in

Combining the previous two points, AAAK achieves genuinely vendor lock-in-free operation:

No lock-in at the data layer. Memories are stored in local ChromaDB; you have complete control over the data. Export is a simple file copy operation.

No lock-in at the format layer. AAAK is a plain text format that depends on no proprietary encoding or decoding tools. You can open AAAK files with any text editor; while not ideally suited for human reading, they are fully readable.

No lock-in at the model layer. AAAK text can be understood by any model. Switching from Claude to GPT requires no data conversion or format migration.

No lock-in at the runtime layer. The MCP server is a standard JSON-RPC interface. CLI tools are standalone command-line programs. The Python API is an open-source library. You can run the entire stack in any Python-capable environment.

This full-stack absence of lock-in is uncommon. Most AI memory products have binding at least at one level – Mem0 is bound to its cloud service, Zep is bound to Neo4j and its API, OpenAI Memory is bound to OpenAI’s ecosystem. MemPalace is replaceable at every level, making it a true infrastructure component rather than a service with lock-in.

Boundaries of Universality

In the interest of honesty, AAAK’s cross-model universality has its boundaries.

Capability floor. AAAK relies on models possessing basic English comprehension and abbreviation recovery abilities. An extremely small language model (e.g., one with fewer than 1 billion parameters) may not be able to reliably perform these inferences. In practice, models with 7B parameters or more can typically understand AAAK reliably, but smaller models may experience degradation.

Cultural assumptions. AAAK’s abbreviation rules are primarily based on English. While structures like PRI(lead) are understandable to any model that has seen English text, if the original content is in Chinese or Japanese, three-letter entity encoding (based on the first three characters of English names) does not apply well. MemPalace mitigates this through configurable entity mappings (Dialect.from_config), but AAAK’s core syntax assumptions remain English-first.

Compression granularity. AAAK’s automatic compression is based on keyword detection and word frequency analysis – heuristic methods that perform less well on certain text types. Highly technical text (filled with code snippets and mathematical formulas) or highly emotional text (more metaphors and allusions than direct statements) may not be suitable for automatic compression and may require manual adjustment or selective original text preservation.

These boundaries are real, but they do not change the core argument: for mainstream large language models and English-dominant use cases, AAAK’s cross-model universality is a reliable technical property supported by linguistic theory.

A Broader Insight

This chapter’s analysis reveals an insight that extends beyond MemPalace itself: data format design for AI should leverage models’ existing capabilities rather than require models to acquire new capabilities.

This principle sounds obvious, but it is frequently violated in practice. Every time a system designer invents a new markup syntax, customizes a set of token protocols, or requires a model to output in a specific format, they are asking the model to do something it may not have been trained to do. Some models can learn it, some cannot. Some versions handle it; upgrades may not.

AAAK’s strategy is the opposite: demand nothing new from the model; simply present information in a form the model already knows how to process. This gives AAAK natural robustness against model upgrades, switches, and version differences – because it depends not on a model’s specific behavior but on its general capabilities.

This design principle can be generalized: if you are designing a system that needs to interact with multiple LLMs, your format choice should favor “a subset of natural language” over “a superset of natural language.” Omission is safer than addition. Abbreviation is more reliable than invention. Leverage the model’s existing knowledge rather than test its learning limits.

MemPalace demonstrated this principle with AAAK: a “language” that invented no new grammar became the most universally compatible AI memory format. Not because it was complex enough to cover all needs, but because it was simple enough to be understood by all models.

This simplicity is not the starting point of the design but the endpoint of constraint satisfaction. Chapter 8’s four constraints filtered out all complex approaches like a funnel, and what remained was this – an extremely abbreviated English, understandable by any model that reads text, requiring no decoder, no training, no special anything.

Sometimes, the best design is what remains after removing everything unnecessary.