Questions, answered directly.

AI memory is persistent storage of what an AI system has learned, decided, and been corrected on, held outside the model and made available to the model on every future interaction.

This matters because large language models do not remember anything on their own. A model processes what is in front of it and then it is done. The next conversation starts from zero. Everything that felt like memory in your last session was context handed to the model at the start of that session and thrown away at the end of it.

So AI memory is not a model feature. It is infrastructure that sits next to the model. Which model is answering can change; the memory does not. That separation is the entire point.

Organizational memory is the institutional version of the above: the decisions your company made, the outcomes those decisions produced, the corrections people issued along the way, the processes that actually get followed rather than the ones in the handbook, and the relationships between all of it.

Every company already has this. It lives in people, in scattered documents, in threads nobody can find, and in the heads of the four employees everyone asks. It is real, it is valuable, and almost none of it is available to your AI.

Organizational AI memory means capturing that institutional history in a structured, permissioned, queryable layer so that any AI operating inside your company arrives already knowing it. The business stops being a stranger to the AI.

Retrieval-augmented generation fetches documents. Memory accumulates understanding. They are not competitors, and they are not the same layer.

RAG answers the question "what does our documentation say about this." It searches a corpus, pulls the closest matching passages, and hands them to the model. The corpus is largely static. Nothing about the interaction changes what the corpus knows.

Memory answers a different question: "what has this organization decided, tried, corrected, and learned about this." It is written to continuously, it is structured by significance rather than similarity, it holds relationships between entities and decisions over time, and it gets better the longer it runs.

A retrieval system that never learns from being used is a search index with a language model in front of it. Useful. Not memory.

No, and this is the most expensive misunderstanding in enterprise AI right now.

A context window is working memory for a single session. Making it larger means the model can hold more in front of it at once. It does not mean anything survives the session. When the window closes, the contents are gone, and you are paying to re-establish them next time.

There is also a quieter problem. Context you stuff into a window is undifferentiated: the model gets no signal about what matters more, what was superseded, who has authority to override what, or which of three conflicting statements is current. Memory carries that structure. A window does not.

Longer context makes a single conversation better. Memory makes the organization better. Those are different purchases.

Context engineering is the discipline of deciding what an AI system should be told, at what moment, with what priority, and with what authority attached.

It replaced prompt engineering as the real problem the moment models got good enough that the bottleneck stopped being how you phrase the request. Now the bottleneck is what the model knows when it receives the request.

Memory infrastructure is what makes context engineering possible at an institutional scale. You cannot hand-curate context per interaction across thousands of employees. The context has to be assembled automatically from a store that knows what is significant, what is current, and who is allowed to see it.

Model Context Protocol is an open standard for how AI systems connect to external tools and data. An MCP server is a service that exposes capabilities in that standard form so any compliant AI client can use them.

MemoryStack exposes an MCP server. That is the mechanism by which the memory layer becomes available to whatever model or assistant is operating: reading context in, writing significant events back out, invoking memory operations directly.

The practical consequence is that memory is not welded to one application. Anything that speaks the protocol can use it. That is what keeps the memory portable and the model layer replaceable.

Agent memory is persistent state for autonomous or semi-autonomous AI processes: what the agent has already tried, what it concluded, what it was told to stop doing, and what the last run produced.

It changes substantially with multiple agents, and this is where most agent projects quietly fall apart. Agents that each keep private state repeat each other’s work, contradict each other’s conclusions, and re-litigate decisions that were settled two runs ago. Nobody is wrong individually. The system has no shared institutional understanding.

A shared, permissioned memory layer fixes the class of problem rather than the instance. Agents write into common memory, read from it, and inherit the organization’s history instead of rebuilding a private version of it. Coordination stops being a prompt-engineering exercise.

The term is used loosely, so here is the useful definition: an AI operating system is the layer that manages state, identity, permissions, and shared resources for every AI process running inside an organization — the way an operating system does for applications on a machine.

The load-bearing part of that is state. An operating system without persistent storage is a demo. Applications would launch, do work, and lose everything on close.

That is the current condition of most enterprise AI. MemoryStack is the persistent state layer underneath it — the reason we describe it as the cognitive operating system beneath your AI rather than another application sitting on top.

By default, no. A model has no storage. Between one request and the next it retains nothing.

When a product appears to remember you, something outside the model saved information and re-supplied it. That something is a memory layer, and the quality of the experience is determined almost entirely by how good it is.

This is worth being precise about internally, because it reframes the buying decision. Choosing a model is choosing a capability you rent. Building memory is building an asset you keep.

Persistent organizational memory infrastructure, licensed as source code. If you need to file it against an existing category on a vendor form, the closest honest labels are AI memory infrastructure, enterprise AI context layer, or cognitive infrastructure.

It is deliberately not filed under knowledge management, enterprise search, chatbot platform, or model gateway. Those categories describe products that sit at a different layer and solve a different problem, and buying MemoryStack expecting one of them would be a mismatch.

The nearest analogy is the database. Nobody buys a database to solve a business problem. They buy it because every application above it needs somewhere durable to put state.

Fine-tuning changes the model. Memory changes what the model is told. They solve different problems and they fail in different ways.

Fine-tuning is appropriate when you want to change behavior, format, tone, or domain fluency. It bakes patterns into weights. It is expensive, slow to iterate, difficult to audit, and impossible to correct precisely. If a fine-tuned model learned something wrong, you cannot delete that fact. You retrain.

Memory is appropriate when you want the model to know things. It is written in seconds, corrected in seconds, permissioned per user, attributable to a source, and portable to the next model you adopt. When a decision is reversed, you record the reversal and the system reasons from the current state.

The practical rule: fine-tune for how it should behave, use memory for what it should know. Facts placed in weights become sunk cost. Facts placed in memory become an asset.

Stateless means the model retains nothing between calls. Each request is processed against the text supplied with it and nothing else. There is no residue, no accumulation, no awareness that a previous request ever happened.

The continuity you experience inside a chat session is an illusion produced by the application, which resends the prior conversation with every new message. That is why long sessions get slower and more expensive, and why the coherence collapses the moment the transcript exceeds what fits.

Statelessness is not a defect to be patched. It is the correct design for the model layer, because it makes models interchangeable. The mistake is assuming somebody else has already built the state layer that belongs next to it. In almost every enterprise, nobody has.

Institutional amnesia is the recurring cost of an organization not knowing what it already knew. The analysis performed twice because the first one is unfindable. The vendor re-evaluated because nobody recorded why it was rejected. The strategy relitigated because the people who settled it left.

It is measurable, though almost nobody measures it, because the cost is distributed rather than line-itemed. The usable proxies are rework rate, time-to-competence for new hires, duplicated analysis across teams, and the number of decisions that route through a small set of long-tenured employees because only they hold the history.

AI makes this worse before it makes it better. Deploy assistants with no memory layer and you have industrialized the amnesia: thousands of interactions per day, every one starting from zero, none of it accruing.

A memory layer is the tier that holds durable state between the models above it and the data below it. Models reason. Data stores hold records. The memory layer holds what the organization has concluded, decided, corrected, and learned, structured so it can be retrieved by significance and authority rather than by keyword or similarity alone.

In a mature stack it is a distinct architectural tier with its own storage, its own permission model, and its own lifecycle. In most enterprises today it does not exist, and its absence is disguised by a collection of retrieval add-ons that each remember a fragment and none of which talk to each other.

If you can swap the model without losing anything, you have a memory layer. If swapping the model resets the organization, you do not.

MemoryStack is persistent, hierarchical, permissioned memory infrastructure for organizational AI. It captures what happens across your AI interactions, decides what is significant, stores it in a tiered architecture on databases your IT organization controls, enriches it over time, and supplies it back to whatever model is operating.

It is licensed as source code under a one-time perpetual license. You hold the source. It runs on infrastructure you control.

The shortest version: it is the reason your AI stops being a stranger to your business.

No, and this is the sharpest question a good architect asks, so it deserves a direct answer.

The routing belongs to the compute being called. Abacus selects the model best suited to each task. MemoryStack does not do that and does not claim to.

What you are buying is the persistent, hierarchical, permissioned memory that makes every model the router selects operate as though it has worked at your company for years — four storage tiers with different retention and retrieval characteristics, significance-based write routing, entity and relationship modeling, role-scoped read and write permissions, and enrichment that runs continuously in the background.

Abacus is the engine. MemoryStack is what makes the engine yours.

No. It uses one, as one tier of four.

Semantic similarity search over embeddings is genuinely useful and it is how the third tier works. But similarity is one retrieval strategy, not an architecture. It cannot tell you what was decided versus merely discussed, which statement supersedes which, who had the authority to make the call, or how three entities relate to each other across eighteen months.

That is why the architecture also uses in-memory storage for live session state, a relational store for session records and extractions, and a graph store for persistent institutional knowledge and entity relationships. Different questions need different structures.

None of the three. MemoryStack has no model of its own and is not an interface your employees log into to chat.

It is the layer underneath. The assistants, agents, and applications your organization runs are the things people interact with; MemoryStack is what they read from and write to.

Without memory, your AI is just an enterprise-priced chatbot. MemoryStack is the correction to that, not another instance of it.

A wiki stores what someone chose to write down, when they had time, in the form they felt like using. It is a human-authored artifact and it decays the moment the authoring stops.

Memory is captured as a by-product of work actually happening. Nobody has to remember to document a decision for the decision to be retained. Significance is scored automatically, relationships are extracted, and the store improves as a function of use rather than of discipline.

There is also a consumer of the data difference. A wiki is written for people to read. Memory is structured for models to operate on, with the permissioning and authority signals a model needs in order to be trusted with it.

Consumer assistant memory is personal, shallow, single-vendor, and single-user. It remembers that you prefer bullet points. It does not know that your company killed a product line in 2024 and why.

Organizational memory is hierarchical and permissioned by design: what an individual can see, what a team shares, and what carries institutional authority are different layers with different rules. It spans every AI process in the company rather than one person’s chat history. And it lives on your databases, which means it survives any decision you later make about vendors.

The model is rented. The memory persists. Consumer memory features are a property of the thing you rent.

No. You are not renting access to a service we operate. You receive the source code under a one-time perpetual license, it is transferred into an account you control, and it runs on infrastructure you hold — your Abacus account for the intelligence layer, your databases for the memory.

That distinction has consequences you should weigh honestly. There is no vendor to call when a server falls over, because it is your server. In exchange, there is no renewal negotiation, no seat-count escalation, no roadmap you do not control, and no scenario in which your institutional memory sits inside somebody else’s multi-tenant system.

No. It does not schedule work, chain steps, or decide which agent runs next. Those are orchestration concerns and there are competent tools for them.

MemoryStack is the state layer those agents read from and write to. An orchestration platform without a memory layer coordinates a team of amnesiacs efficiently. The coordination is real; the accumulation is not.

If you already run an agent framework, this sits underneath it rather than replacing it.

Generally not, and you should be suspicious of anyone who says otherwise. Assistants, copilots, coding tools, and departmental AI applications keep doing what they do.

What changes is what they operate on. MemoryStack exposes an MCP server, which is the emerging standard interface for supplying context to AI clients. Tools that speak it can read organizational memory instead of guessing from whatever the user pasted.

The replacement conversation only comes up later, and it comes from your side rather than ours: once memory is in place, some of the point tools you bought to compensate for its absence stop justifying their renewal.

It is the best version of the wrong layer, and it is the single most common pattern we encounter. Restricting authorship to experts is a real quality control, and it is why this design gets funded when uncontrolled retrieval projects get killed. Most retrieval efforts fail because they index everything indiscriminately and the model dutifully cites the intern deck from 2022. Limiting contribution to people who actually know the material fixes that, and the instinct behind it — that not all content carries equal authority — is exactly right.

What it cannot do is accumulate. Six specific limits, and they arrive in roughly this order.

• Capture depends on volunteer effort from your scarcest people. The subject matter expert is, by definition, the person with the least discretionary time. Contribution competes directly with the work that made them the expert. It is the first commitment to slip, and because there is no alarm on it, the slip is usually two quarters old before anyone notices.
• It only captures what experts know they know. The valuable material is tacit: the correction issued in a thread, the decision reversed after a bad outcome, the exception that quietly became the rule, the reason the obvious approach was rejected. Nobody sits down to author those. They are observable in the work and they are almost never written.
• A curated document is a snapshot, not a ledger. It states what is true now. It does not hold what was tried, what failed, or why the current answer replaced the previous one. So when the AI gets a question the document does not cover, it has no history to reason from and it improvises.
• Nothing learns from use. After ten thousand queries the corpus is byte-identical to the day it was published. Which questions had no good answer, which retrieved passages the user ignored, which answers got corrected in the next message — all of that is high-grade signal, and none of it is written back. Improvement requires another round of expert volunteering.
• The single point of failure is the expert. When they leave, the corpus freezes at their last contribution, and the judgment that made it usable leaves with them. That is precisely the risk institutional memory exists to eliminate, faithfully reproduced in software.
• There is authority but no decay model. A superseded document and a current one retrieve equally well, because similarity scoring has no opinion about time or precedence. The system will cite a retired policy with total confidence.

In a better position than most organizations, and it is worth saying that plainly rather than treating an approved initiative as an obstacle. Leadership has already conceded the premise that matters: institutional knowledge is an asset worth engineering against, and authority over content is a governance question rather than a technical one. That argument usually takes a year to win. It is won.

The gap is layer, not intent. Expert curation produces a governed corpus. Memory infrastructure produces a growing ledger. You can hold both positions without reversing anyone, because the second one consumes the first: the curated library becomes the seeded authoritative tier, and the experts move from sole authors to reviewers of what the system captures on its own.

The reframe that lands with a CTO is a maintenance argument, not a capability argument. An expert-authored corpus has a permanent human tax attached to it, paid in the time of the people you can least afford to tax, and the quality of the system degrades silently the moment that tax goes unpaid. A memory layer captures automatically and asks experts to adjudicate rather than to author. Same governance, same authority weighting, a fraction of the ongoing burden.

The honest prediction: the initiative will show early wins on well-documented, frequently asked questions, then plateau. Usage will drift back to asking the four people everyone asks, because those four hold the history the documents do not. That plateau is the moment to have this conversation, and knowing it is coming is worth more than being right about it later.

Both accept that some sources outrank others. They differ on who does the writing.

Expert-only curation puts authority at the point of authorship: nothing enters unless an authorized person composed it. That yields a clean corpus and a hard ceiling on volume, because volume is bounded by expert hours.

Authority-weighted memory puts authority at the point of scoring and retrieval: anything the organization does can be captured, and what it is worth is determined by who said it, what role they hold, what outcome followed, how often it has been reinforced, and whether something newer supersedes it. Volume is bounded by activity rather than by anyone’s calendar.

The second model requires more machinery, which is the honest tradeoff. What it buys is a system where an expert correcting one answer improves every future answer that depends on it, rather than an expert writing one more document.

Yes, and it is the ideal starting condition. An expert-curated library is exactly what the seeding phase of setup wants: vetted, authority-attributed content that can be loaded into the upper memory tiers on day one instead of accumulating over months.

The work is not conversion, it is attribution. Each item needs an author, an authority level, an effective date, and a supersession relationship where one exists. Most curated libraries already carry the first two informally and can be enriched quickly.

Retrieval over those documents continues to work as it does today. The difference is that from that point forward the corpus stops being the whole system and starts being its foundation.

No, and the two are not in conflict. Copilot is a consumption surface — where people do work. Memory is the state layer underneath it. Deploying the surface without the layer is what produces the familiar outcome: enthusiastic pilots, real individual productivity, and no institutional accumulation whatsoever.

Teams keep the tools they already know. What changes is that those tools can read organizational memory over the MCP interface rather than depending on whatever each user remembers to paste in.

Not necessarily, and the gap between those two things is worth checking before you build anything on the assumption.

A pattern we see often: leadership is told the organization is getting access to a well-known model, everyone reasonably pictures that vendor’s own product and workflow tooling, and what actually arrives is that model exposed inside a different vendor’s assistant. Both statements are technically true. They are not the same purchase. The workflow surface is different, the retention and context behavior is different, what integrates is different, and what you can build on top of it is different.

What makes this worth naming is that the people announcing it frequently cannot articulate the distinction either — not from carelessness, but because the stack has three separable layers (the model, the platform that serves it, the surface people work in) and the industry uses one set of brand names for all three. If the layers are indistinct internally, nobody can evaluate them, and nobody notices that the memory layer was never part of the conversation.

Three questions settle it: which model, served by which platform, inside which surface. Ask them separately and expect three different answers.

Because your leverage lives at different layers, and so does your lock-in.

The surface determines what your people experience and how much of the work is capturable. The platform determines whether you get one model or the right model per task, what the data handling terms are, and what you can build. The model determines raw capability, and it is the layer that changes fastest and matters least to your long-term position — precisely because it is interchangeable.

Conflate them and you make a five-year architectural commitment while believing you are choosing a model for this year. The most consequential version of that mistake is assuming the memory layer came included somewhere in the bundle. It almost never does, and none of the three layers will tell you it is missing.

The model is rented. The memory persists. Knowing which layer you are actually buying at is how you keep that true.

Because those systems store documents that people wrote deliberately, and the organization’s actual operating knowledge is mostly not in that form.

A wiki records the process as designed. Memory records the process as performed, including the three exceptions everyone honors and none of which are documented. A wiki holds the current policy. Memory holds the current policy, the two it replaced, and the incident that caused the change.

There is also a maintenance reality worth stating: the freshness of a wiki is a function of somebody’s discipline, and that discipline is unevenly distributed and never audited. Memory accrues from the work itself, which is the only capture mechanism that survives a busy quarter.

Check what persists after the run completes, and where. Most agent platforms offer session state, a scratchpad, or a per-thread history. That is working memory for a task, not organizational memory.

The specific questions to put to the vendor: does anything written during one run inform an unrelated run next month, is it permissioned by organizational role, does it hold relationships between entities over time, and can you take it with you if you leave the platform. If the honest answers are no, you have orchestration without state.

They will solve it inside their own products, because that is where the commercial incentive points. Every one of them has a structural reason to make memory a property of the model you rent rather than an asset you hold, and a reason to make it difficult to move.

You should expect model-native memory to keep improving, and you should expect it to remain per-vendor, per-product, and non-portable. Which means the waiting strategy is a bet that you will be content to have your institutional history live inside a single vendor’s platform, on their retention terms, at whatever their renewal price becomes.

The model is rented. The memory persists. Choosing where it persists is the decision.

Memory moves upward through a hierarchy of tiers, each with different storage technology, latency, and retention characteristics. The baseline ships with four tiers, but the hierarchy itself is customizable — some organizations need three, others six. Tiers can be added, removed, or restructured to match how the business actually works. Display names are yours to rename; internal identifiers stay stable so nothing breaks when you do.

• Tier 1 — Live (default): in-memory store holding active session context. Sub-millisecond. Ephemeral by design.
• Tier 2 — Today’s Conversations (default): relational store holding session records, transcripts, and entity extractions. Rolling thirty-day default.
• Tier 3 — Recent Memory (default): vector store holding semantic embeddings for similarity search across weeks and months.
• Tier 4 — Deep Memory (default): graph store, with an optional document store, holding persistent institutional knowledge, entity relationships, and strategic decisions. No decay.
• These are the defaults. Your hierarchy may have more tiers, fewer, or differently scoped ones. The architecture adapts to the organization, not the other way around.

Three layers, in order, so that automation handles the volume and humans keep the authority.

First, an automated scorer rates every candidate memory from 0 to 100 on a weighted composite: how recently it occurred, how often it is referenced, how novel it is, how dense it is with entities, the role weight of who produced it, whether someone explicitly signalled it mattered, and whether it carries a decision or goal.

Second, a rule engine your administrators configure applies overrides. If anything from the legal review process must land in deep memory regardless of score, that is a rule, not a negotiation with a model.

Third, manual override. An administrator, or an AI holding the permission, can promote or demote a specific memory directly.

Thresholds and weights ship with sensible defaults and are yours to tune. Time decay is exponential, with a seven-day half-life at Tier 2 and ninety days at Tier 3. Deep memory does not decay.

Automatic fine-tuning of the scoring model is on by default and administrators can switch it off entirely.

When it is on, the system proposes adjustments with a stated rationale rather than silently changing behavior. Every change is non-destructive and reversible, and a reset restores factory defaults.

We default it on because untuned scoring is worse than tuned scoring, and we make it reversible because you should never have to trust that claim.

Almost never — but yes, when you require it. Memory has three dispositions, and the default is the gentlest one.

Deactivate is the normal path. Memory stops influencing operation while remaining fully reviewable, and its identity is preserved. This is deliberate: deleted history cannot be audited, and an organization that cannot reconstruct why its AI behaved a certain way eighteen months ago has an accountability problem it will eventually be asked about. Most of what looks like a deletion need is actually this.

Supersede is the second path. Prior state is preserved but no longer served as current, so the system reasons from what is true now while the record of what changed, and when, stays intact.

Purge is the third, and it exists because deactivation is not always enough. Privacy erasure requests, retention schedules, litigation policy, and employee and customer data obligations can require that specific content actually be destroyed, not merely retired. Purge is a privileged, auditable operation that removes the content itself while preserving an audit record that a purge occurred — what identity, under what authority, on what date, against which obligation — without preserving the prohibited content. You satisfy the legal requirement and still keep a defensible trail that you did.

The default is always the least destructive disposition that satisfies the requirement. You do not lose institutional memory to routine housekeeping, and you are not architecturally trapped when the law requires deletion.

On databases your IT organization selects, provisions, and controls. MemoryStack connects to them. It does not host them and does not hold your memory in our custody.

That is a structural choice rather than a policy one. A vendor that stores your institutional memory can change its terms, its pricing, or its ownership. A vendor that connects to your databases cannot.

The enterprise product never stores customer memory. The consumer edition, MemoryStack Personal, does manage the storage for the individual user — different product, different expectations.

No standing access. The vendor is never in the data path. You receive the source code, deploy and control MemoryStack, select and control the databases, and hold the credentials and permissions. There is no point at which your memory passes through us.

This is materially different from normal enterprise SaaS, where the vendor possesses your data and promises contractual and technical controls around who on their side can see it. Here there is nothing to promise about, because there is nothing on our side to control. For us to see your memory, you would have to deliberately grant us access — and we would not request it.

This is not a privacy policy promising we will not access your memory. It is an architecture built so that we do not have access to it.

One store per tier in your hierarchy. The baseline four-tier configuration uses an in-memory cache, a relational database, a vector database, and a graph database, with an optional document store. If your hierarchy has more tiers, you provision the additional stores to match.

The number of stores is not fixed, and neither is where each one lives. Every store can sit on a different provider, service, and region — a relational store on AWS, a graph store on Azure, a store scoped to the C-suite in its own isolated location under separate access control. You decide the topology; MemoryStack connects to whatever you point it at.

The setup wizard walks through connecting and testing each one before anything goes live. If your organization already standardizes on particular engines within those categories, that is generally what you should use — the point of controlling the storage layer is that it looks like the rest of your estate.

Read and write scope is bound to role, hierarchy, and explicit permissions. Memory can roll upward through organizational authority, but higher authority does not override an explicit access restriction. A lower role cannot write into a level above its authority, and every retrieval remains subject to the permissions governing that memory.

• Admin AI: full read and write across all tiers.
• Oracle AI: reads all tiers, writes to Tiers 3 and 4. A Tier 4 write carries organizational authority.
• One-on-one AI: reads the user’s Tier 2 and 3 plus relevant Tier 4; writes only to Tiers 1 and 2.
• Standard user: flags content for review and views their own Tier 2 according to policy.

A guided seven-phase wizard: platform identity, tier naming, database connection and testing, scoring model configuration, organizational memory seeding, AI role and permission configuration, and a go-live readiness confirmation that writes the first record into deep memory.

The phase that determines your outcome is the fifth. Seeding deep memory with your mission, current goals, key entities, and operating values is what makes the system useful on day one rather than in month four. It is the part worth spending real time on.

Timeline depends almost entirely on how quickly your organization can get the databases provisioned and approved. The software configuration is short. Procurement is usually the long pole.

It ships with baseline schemas already built — the tier hierarchy, the entity and relationship models, the significance scoring model, the lexicon, and the role and permission framework. You do not start from an empty database and a design document.

But the baseline is a starting point by necessity, not a finished product, and anyone who tells you otherwise is selling you something that will not fit. Organizational memory is organization-specific. What counts as a significant decision at an underwriter is not what counts at a fabricator. The entities that matter in professional services are not the entities that matter in distribution. Some organizations need four tiers; others need six. A schema that fit every company equally would be too generic to be useful in any of them.

So the schemas are fully editable and you can create new ones. The tier hierarchy itself is customizable — tiers can be added, removed, or restructured. The lexicon is customizable — every label, tier name, and display term can be changed to match how your organization talks about its own knowledge. Fields, entity types, relationship types, scoring weights and thresholds, tier routing rules, retention behavior — all of it is yours to change, before go-live and continuously afterward. That flexibility is not a convenience feature. It is the difference between memory infrastructure and a rigid product you end up working around.

This is also the practical argument for licensing source rather than renting access. You cannot deeply customize a schema inside somebody else’s multi-tenant system, because their schema has to serve every other tenant too.

All three, and the third is the one that matters most.

Humans edit directly. An administrator who knows the business can add an entity type, reweight the scoring model, or change what routes to which tier at any point.

The system proposes. Auto-tuning is on by default and can be switched off entirely by an administrator. It observes what actually gets retrieved, reinforced, ignored, and corrected, then proposes adjustments to weights and thresholds with the reasoning attached. Proposals are non-destructive and reversible, and there is a reset that restores the shipped baseline.

The combination is where it gets good. A person contributes judgment the system cannot infer — that a particular category of decision carries more institutional weight than its usage suggests. The system contributes observation no person has time to perform — that a scoring weight has been mistuned for four months across ten thousand interactions. Neither alone produces a schema that fits the organization. Together they do, and they keep doing it as the organization changes.

The intended trajectory is that the schema you run in year three is materially better than the one you configured at go-live, and that the improvement did not require a release from us. A tool depreciates. Infrastructure compounds.

The bulk of it happens once, during the guided setup wizard, and the phase that determines your outcome is the seeding phase rather than any of the technical ones. Connecting databases is mechanical. Deciding what your organization considers significant, who holds authority over what, and what institutional context the system starts with is judgment work, and it is worth real time from people who know the business.

After go-live, configuration becomes ongoing but light — adjusting what the first quarter of real usage reveals, and adjudicating what auto-tuning proposes. This is administration rather than a project.

The honest expectation to set internally: the system is useful on day one because of what you seeded, and noticeably better in month six because of what has been tuned. Organizations that treat setup as a checkbox get the day-one version and conclude the category does not work.

Conflict is treated as a first-class state rather than an error to be silently resolved. When two records disagree, the system ranks them on authority of source, recency, reinforcement count, and whether an explicit supersession relationship exists between them.

If the ranking is decisive, the higher-ranked record is served and the other is retained as prior state. If it is not decisive, the conflict itself is surfaced, because an AI that confidently picks one side of an unresolved organizational disagreement is more dangerous than one that reports the disagreement.

This is the behavior similarity-based retrieval cannot produce. Two contradictory documents that are both topically relevant will both be retrieved, with no signal about which one governs.

Through supersession and decay rather than deletion. When newer memory contradicts or replaces older memory, the relationship is recorded, the older record stops being served as current, and it remains available as history.

Separately, records that are never reinforced, retrieved, or referenced lose weight over time. Something asserted once in 2025 and never touched again should not compete with something reinforced weekly.

The distinction matters for audit. You can always answer what the organization believed at a point in time, which is a question compliance functions ask and document stores cannot answer.

Three routes, and the mix shifts over the first quarter.

• Seeding during setup. Mission, current goals, key entities, operating values, and any existing curated documentation. This is what makes the system useful on day one.
• Automatic capture from AI interactions. Work performed through connected AI clients is evaluated for significance and written to the appropriate tier without anyone deciding to document it.
• Explicit contribution and correction. People can assert something directly, and correcting a wrong answer writes the correction back as memory rather than fixing one response.

The memory stays. Their access ends; what they contributed remains, attributed, at the authority level it was captured with.

This is the closest thing to a plain statement of what the system is for. Today, when a long-tenured person leaves, the organization loses the history that lived only in their head and the successor spends a year rediscovering it. With a memory layer, the reasoning they contributed over years is still queryable by the person who replaces them.

Departure handling is a configuration decision rather than a deletion event: contributions can be reweighted, reattributed to a role, or flagged for review, but the institutional record is not erased because someone changed jobs.

The tiered design exists mostly to answer this question. Not all memory needs the same access characteristics, so it is not stored the same way. Frequently accessed, high-significance memory sits in fast storage sized for latency. Deep institutional memory sits in storage sized for durability and volume, queried less often and tolerating more latency when it is.

The consequence is that retrieval cost tracks the size of the working set rather than the size of total memory. A system with five years of history does not pay a five-year penalty on a routine query.

Because the databases are yours, scaling headroom is also yours to size. That is a real responsibility rather than a marketing point, and it is one of the things the assessment estimates for you.

Yes, with no conditions attached. It sits on your databases, in a format you can move, and you can take it anywhere at any time without asking us.

We state it that flatly because the qualifiers are where this normally goes wrong. There is no export request process, no proprietary format, no portion of the data that stays behind, and no fee attached to leaving.

Own your memory. Own your future.

Because standardizing on a single model from a single company is a bet, and we are not willing to build memory infrastructure on top of a bet.

Abacus — a US company, founded in 2019 — provides access to more than 100 top LLM models and selects the one best suited to each task, goal, or interaction. The choice of model is not made once at purchase and lived with for five years. It is made per task, and it moves as the frontier moves.

So the dependency is not in tension with model independence. It is the mechanism that delivers it. An organization standardizing on one vendor’s model has made a bet. An organization running on routed intelligence has not.

It is a dependency, and we would rather argue with you about it now than have your architects discover it during diligence. So here is the whole picture, including the part that does not favor us.

Your memory is portable with nothing attached. The compute is opinionated. You hold the source code and you can re-architect the applications onto your own models if you decide to — your license explicitly permits exactly that.

But you would be giving up the multi-model routing that is the reason the system performs the way it does, and it is real engineering work rather than a configuration change. We recommend against it. We also recommend knowing that before you sign rather than after.

The distinction that matters: lock-in is when leaving costs you your asset. Here, leaving costs you a capability you can choose to rebuild. The asset comes with you.

Yes. Nobody has to be pulled out of the tools they already know.

MemoryStack can connect to third-party assistants. If your people work in Microsoft Copilot or another assistant today, those front ends can connect to the same memory and keep going. The intelligence underneath is still Abacus and the routing still happens there — what changes is that the tools your teams already open every morning stop being amnesiac.

We treat this as a secondary point rather than the headline, because the headline is that the right model gets selected for each task without anyone managing it. But adoption is real, and forcing a company to abandon working habits to get infrastructure benefits is a bad trade.

You keep operating. That is the specific reason this is licensed as source code rather than sold as a subscription.

You hold the source. The system runs on infrastructure you control. Your memory is on your databases. None of those three things require us to exist.

A subscription that goes away takes your capability with it. A perpetual source license does not. It is a less convenient business model for us and a materially safer one for you, and that asymmetry is the point.

Yes. You hold it, and organizations with real engineering capacity should expect to extend it — additional memory skills, integrations specific to your estate, adjustments to the scoring model beyond what configuration exposes.

The practical caution is the ordinary one for any licensed source: the further you diverge from the shipped architecture, the more of the maintenance burden moves to you. Extend at the documented boundaries and that stays manageable.

The complete application source, transferred into an Abacus account you open and control, plus the perpetual license to it, the setup wizard, the documentation, and the schema for the memory tiers.

From the moment of transfer you hold the code, the account, and the data. There is no escrow arrangement to invoke and no dependency on us continuing to exist, which is the point of licensing source rather than access.

Yes, and we will tell you the tradeoff before you buy rather than after. It is your license and your code, so the applications can be exported and re-architected onto models you host or contract for directly.

What you would be trading away is the multi-model routing that makes the system perform — the ability to send each task to whichever of a hundred-plus models handles it best, without you maintaining that judgment yourself. In our assessment that routing is a material part of the output quality, and replacing it with a single model is a downgrade you should undertake deliberately.

Your memory is unaffected either way. It lives on your databases in a portable format and moves with you regardless of what you decide about the intelligence layer.

You do. Memory skills, integrations to your estate, scoring adjustments, interface work — what your engineers write is yours, with no grant-back and no obligation to share it.

The one piece of engineering advice attached to that: extend at the documented boundaries. Divergence from the shipped architecture is permitted and sometimes correct, and it moves maintenance burden onto your team in proportion.

Two things are being certified and they are frequently conflated, so we separate them.

The Abacus platform holds SOC 2 Type II, ISO/IEC 27001, HIPAA, and GDPR plus CCPA alignment, with AES-256 at rest, TLS 1.2 and above in transit, key management through AWS KMS, and SAML 2.0 single sign-on with multi-factor authentication and role-based access control. Verify it directly at abacus.ai/security rather than taking our summary for it.

The MemoryStack application is a separate question. The source ships verified against OWASP ASVS Level 2, with coverage of the OWASP Top 10 and API Security Top 10, static analysis, software composition analysis, secrets scanning, STRIDE threat modeling, and dynamic testing.

Your corporate IT function will ask about both. Bring both.

No. Your memory exists to condition responses for your organization, not to improve a model for anyone else.

The architecture makes this straightforward rather than a matter of trust: your memory sits in your databases under your control, and it is supplied as context at inference time. Verify the specific data handling terms of the underlying platform during diligence, as you should for any AI vendor — but the storage layer is not ours to use.

Permissioning is a first-class property of the memory itself rather than a filter applied on the way out.

Every memory carries the authority and scope under which it was written. Read and write access is bound to role across the tier hierarchy, memory flows only upward, and writes into deep memory carry organizational authority and are restricted accordingly.

The practical consequence is that a one-on-one AI cannot surface something a user has no right to see, because it was never in that AI’s read scope. Access control is not a post-processing step you have to trust.

The architecture is built for it, and the reason is where the data sits. Your memory never enters our custody, which removes an entire category of third-party data-residency and processor questions before they are asked.

Add to that: the default disposition is deactivation rather than deletion, so the audit trail of what your AI knew and when stays intact — and when a regulation requires actual erasure, purge does it while preserving an auditable record that it happened. Access is permissioned at the memory level, and the underlying platform carries HIPAA and the certifications listed above.

We are not going to tell you it is pre-cleared for your specific regulator. Bring your compliance function in early, use the assessment to frame the scope, and we will answer the specific questions directly.

Expect the review to cover four areas, and expect it to be substantive rather than a checkbox exercise.

• The Abacus platform certifications and the data handling terms attached to them.
• The application assurance evidence — ASVS Level 2 verification, scanning coverage, and threat model.
• Your own database configuration, since the storage layer is yours and its hardening is yours.
• The role and permission model, mapped against your actual organizational authority structure.

The controlling fact is that the memory tiers are your databases, inside your boundary, under whatever handling regime you already apply to systems of record. You are not shipping regulated data to a vendor and asking about their controls.

At the application layer, the levers are the significance model and the role permissions: what categories of content are eligible for capture, which tier they may be written to, and which roles may retrieve them. Sensitive categories can be excluded from capture entirely or confined to a tier with restricted retrieval.

What we will not do is claim the application relieves you of your obligations. It gives you the placement and the controls; the classification decisions are yours, and your privacy function should make them during setup rather than after.

In transit, yes, throughout. At rest, encryption is a property of the database you provision, which means it is configured to your standard rather than to ours — an advantage, since your standard is what your auditors already accepted.

This is a recurring theme in security review and worth stating directly: because the storage layer is yours, several controls your team would normally have to accept on faith from a vendor are instead ones they configure and verify themselves.

Yes, and this is one of the more consequential differences from stuffing context into a prompt. Retrieval is a recorded event: which records were served, at what tier, under which role, and at what point in time.

That gives you two things a context window cannot. You can reconstruct why the system answered as it did, and you can answer the compliance question of what the organization knew and when. Prompt-based context leaves no durable trace of either.

A one-time perpetual license to the source code. You buy it once and you hold it.

This is infrastructure, and infrastructure that stops working when you stop paying is not infrastructure — it is a tool you are renting. A tool depreciates. Infrastructure compounds.

It varies by organization, so there is no price list on this site and putting one there would be dishonest.

The license scales with the size of the deployment rather than with a seat count you will fight about later. The Readiness and Value Assessment produces an actual figure for your organization, alongside what your current position is costing you and what ownership looks like year over year.

If a number is what you need before a conversation, run the assessment. It is not gated and it does not require talking to anyone.

The model does not include a recurring license fee or an annual support percentage. That is the difference between owning infrastructure and renting a tool, and charging a yearly toll on top of a perpetual license would undermine the thing we are selling.

Support and engagement terms are settled at contract rather than assumed here. Ask directly and you will get a direct answer.

Two, and both are yours rather than ours.

First, Abacus compute for the intelligence layer, which scales with actual usage. Second, hosting and operating your databases, which is ordinary infrastructure spend inside your existing estate.

The assessment models both across a five-year horizon so you are comparing total cost of ownership rather than a license figure against a subscription figure.

Scope is a commercial term, not something MemoryStack polices from inside your systems. There is no telemetry, no seat counter phoning home, and no monitoring of how you actually use your instance — that would contradict the ownership promise and put us in a data path we deliberately stay out of. Instead, the license names a defined scope — a department, a business unit, or the whole enterprise — and the contract sets the pre-negotiated price to step up from one scope to the next.

So if a department or business-unit licensee later deploys more widely than they bought, they are not caught by software — they simply owe the agreed difference to bring their license up to the scope they are actually running. It is a one-time step-up payment settled at terms already written into the contract, not a recurring fee, a growth tax, or a subscription escalator. You pay the difference once and you own the wider scope in perpetuity, exactly as with the original purchase.

Enterprise is the top of the ladder. An enterprise license already covers the whole organization, so there is no wider scope to step up into and nothing above it to buy. If the business grows, acquires, or multiplies in size after purchase, the license is not re-priced — it is a one-time perpetual purchase and it stays one. There is no such thing as charging an enterprise customer more for getting bigger.

For department and business-unit licenses there is a lightweight annual scope certification: once a year you confirm, in writing, that the scope you are running still matches the scope you licensed. It is a good-faith attestation, not an inspection — we are not looking inside your deployment. If nothing has changed, the certification just confirms the status quo. If the deployed scope has grown, that is when the one-time step-up to the next tier is settled, at the price already negotiated into the contract.

The audit right is a rarely-used contractual backstop, not a routine event. It is a records-based right — deployment attestation and documentation, requested on reasonable notice — and it exists only for the case where a certification is refused, lapses, or is plainly inconsistent with what is publicly known. For a customer acting in good faith it should essentially never be invoked.

None of this applies to enterprise customers in any meaningful way. An enterprise license already covers the entire organization, so there is no larger scope to certify against and nothing for an audit to test — the whole certify-and-step-up mechanism only exists to handle a department or business unit that expands beyond what it bought. Enterprise is terminal: bought once, owned forever, never re-certified for scope and never re-charged.

Early 2027.

We are stating that plainly rather than implying availability today. What is available now is the architecture, the specification, and a serious conversation about fit — which for infrastructure of this kind is the part that takes the longest anyway.

Organizations that engage before ship have influence over the roadmap and a considerable head start on the procurement and security review work that will otherwise happen after.

Deployment can be fast. Go-live in as little as 90 days is achievable, and nothing about the architecture requires longer. But the timeline is owned and controlled by you, not by us, so we do not commit to a date and cannot be held to one we do not control.

The pace is set by things on your side: how quickly you provision and approve the databases, integrate your existing tools, seed the institutional content, and drive real adoption. Procurement of the databases is usually the longest single item. Where those move quickly, deployment moves quickly; where they stall, it stalls — and neither is something MemoryStack can accelerate on your behalf.

The same applies to the phases beyond go-live. The native MemoryStack apps that accelerate later-stage automation follow the product roadmap, and you can always develop your own. Any timeline you see in the assessment or elsewhere is illustrative of what is possible, not a commitment.

Engagement models before general availability are handled case by case, and we would rather discuss what makes sense for your organization than publish a program that fits nobody.

The qualification survey is the entry point. It tells us where you stand and what you need, and it is what makes the first conversation substantive instead of a discovery call.

The application source, the perpetual right to run and modify it, the guided setup wizard, the documented schema and extension boundaries, and the transfer of the code into your own account.

Not included, and deliberately so: your Abacus account consumption, your database hosting, and your internal implementation effort. Those are costs you hold directly with the providers rather than marked up through us, which is also why they stay visible and controllable.

Less engineering than people expect and more decision-making authority than they plan for.

On the technical side: someone who can provision and administer the databases to your standard, and an engineer to own the deployment and any extensions. This is not a team-of-ten project.

On the organizational side, which is where projects actually stall: someone with authority to define the role and permission model, someone who can commit the institutional content for the seeding phase, and a sponsor who can decide without routing every question through a review committee. Procurement of the databases is usually the longest single item in the timeline.

Organizations above roughly $20 million in revenue that have enough institutional complexity for memory loss to be genuinely expensive, and enough engineering maturity to operate infrastructure they control.

The pattern we see repeatedly: AI is deployed, people use it, and it never gets better at the company. Every conversation re-establishes basics. Nobody can explain why the output is generic. The tooling is fine and the results are flat.

That is a memory problem, and it does not resolve by upgrading the model.

Small organizations where the institutional history genuinely does fit in a few people’s heads. The infrastructure would cost more than the problem.

Organizations looking for a chatbot, a search tool, or a productivity feature. This is a layer beneath those, and buying it expecting one of them would be a mismatch we would rather catch early.

Organizations with no appetite for operating their own databases. The storage layer being yours is the whole basis of the ownership claim — if that is unwelcome, the value proposition does not hold.

You could, and a few organizations genuinely should. But be honest about the traditional path. Most companies that would build this are not building with AI, so it runs on the old model — eighteen months to two years to a first working version, then a permanent obligation to maintain, update, and support it with your own people.

And be clear about what you would be building. Not a vector store with retrieval, but a tiered architecture with different storage technologies per tier, a customizable hierarchy, significance-based write routing with a tunable scoring model, entity and relationship extraction, a role-bound permission model that holds across the hierarchy, background enrichment, protocol-level exposure to any compliant AI client, and the operational tooling to administer all of it. The storage is the easy part; the judgment layer is where the two years go.

MemoryStack was built with Abacus, and running on Abacus means new features, integrations, and additional apps are quick to build and deploy. We are not pretending there is no work to set up and run it — the burden of ownership is real, it is just a fraction of the traditional one. So the honest comparison is not build versus buy. It is build versus buy the source and extend it, which is what a perpetual source license makes available. The assessment models that comparison directly.

Possibly the opposite. The organizations with the hardest path are the ones that deployed AI broadly with no memory layer and now have habits, integrations, and expectations built around systems that forget.

Starting with the state layer in place means the first thing you build accumulates instead of resetting. That said, if you have no AI usage at all and no near-term plan, the value is theoretical for now — and the assessment will tell you that rather than sell around it.

Two paths, and neither requires a sales conversation to start.

The Readiness and Value Assessment gives you a readiness score, the time and cost your current position is losing, what ownership costs year over year, and a timeline to governed autonomy. It is not gated and the report downloads immediately.

The qualification survey on the contact page is four short steps and is the fastest route to a real conversation with us. Use it if you already know you want to talk.

Pick the place where the organization repeatedly loses the same information, not the place with the most enthusiasm. Those are rarely the same department.

The pattern that works: a function with high decision volume, real consequences for getting it wrong, and a known dependency on two or three people who hold the history. Sales engineering, technical support escalation, underwriting, and product decision-making all tend to qualify.

The pattern that disappoints is starting with a broad horizontal rollout to demonstrate reach. Memory compounds within a domain first. Give it one domain deep enough to show accumulation, then widen.

Measure accumulation, not usage. Usage is easy to generate and tells you nothing about whether the organization is retaining anything.

The signals that actually indicate a working memory layer: the same question being asked and correctly answered without a human intervening the second time, corrections that do not need to be reissued, time-to-competence for new hires in the seeded domain, and a fall in the volume of decisions escalated to the two or three people who hold the history.

The assessment produces a baseline on the cost side before you start, which is what makes the comparison later meaningful rather than anecdotal.

Someone who owns an outcome, not someone who owns a technology budget. This is the single strongest predictor of whether an implementation ships.

It works when the sponsor is accountable for something memory demonstrably improves — a revenue number, a service level, a risk position — and has the authority to decide the permission model without convening a committee. It stalls when it is owned by an innovation function with a mandate to evaluate and no mandate to commit.

A committee cannot pool a skill its members lack. The same is true of conviction.