The Memory Engine That Ran Argus Is Now Its Own Product
For months, GISM-0 has been the thing Argus runs on — the three-layer semantic memory that stores what your agents need to know, structured three different ways simultaneously. Today it gets its own front door. No protector agent required.
Jeffrey Phillips Freeman
There is a moment in every retrospective, usually somewhere between the second cup of coffee and the slide titled “What We Learned,” when someone points out that the thing everyone was excited about was actually running on top of something else nobody ever introduced properly. The exciting thing got the press release. The foundation got a footnote.
This is the press release for the footnote.
In August, we announced that GISM-0 had reached production quality. In September, we launched Argus on top of it. In October, we published benchmark results showing it retrieved answers with 5.8× fewer tokens than the baseline. In every one of those announcements, GISM-0 was described as what Argus runs on — the engine under the product, the memory architecture that made the efficiency possible. Today it stops being described as an appendage of something else and becomes the thing itself: a standalone, self-serve, fully-isolated three-layer semantic memory API, available to every CleverThis account.
A proper introduction, long overdue
GISM-0 is a memory system. That sentence contains two load-bearing words.
‘Memory’ in the AI context has been so badly abused — applied to summarization profiles, rolling context windows, and various other mechanisms that do not survive contact with a fact-based question about last Tuesday — that the word has nearly lost its meaning. So: GISM-0 is a memory system in the sense that after something is ingested into it, that thing can be retrieved, in full, later, with its content intact. Not paraphrased. Not averaged across multiple sources into a plausible-sounding synthesis. The actual record, with its timestamp, and its semantic relationship to other records, and its position in the knowledge graph built from everything else that was ever ingested. That is what the word means when we use it.
An event ingested on a Monday is retrievable on a Friday with its full content, its precise timestamp, its semantic similarity score against other documents, and its position in the knowledge graph. Not a summary. Not a synthesis. The record.
‘System’ is the other word. GISM-0 is not a vector database with a tidy API. It is not a full-text search engine with vector support appended as a quarterly roadmap item. It is three layers of storage, simultaneously maintained, each optimized for a structurally different kind of question, all queryable in a single call. Those three layers are the engineering decision that makes it interesting, and they have earned a proper explanation.
The three layers, explained without euphemism
L1 is the timeseries layer. Every document ingested creates a timestamped event in an append-only log. L1 answers questions with time in them: what arrived on a particular day, what occurred between these two timestamps, what is adjacent in time to this known event. It is the court reporter of your data — unembellished, exhaustive, and mercifully devoid of editorial opinion about what matters. If the event happened and was ingested, it is in L1. If it was not ingested, L1 does not invent it, which distinguishes it from several other things currently called memory in this industry.
L2 is the semantic index. Every ingested document is chunked, embedded, and indexed for both full-text keyword search and vector similarity retrieval. L2 answers meaning questions: not “find the document where the exact phrase appears” but “find documents with similar intent to this query, regardless of whether they share a single word.” One ingest call. A query gets the best retrieval the index can provide.
L3 is the knowledge graph. Structured facts and relationships about your data, queryable via SPARQL against an external wiki. L3 answers structural questions: not “what did this document say” but “how is this entity related to this project, and which source documents confirm that relationship.” It is the layer where meaning compounds into structure, and where the answers to “who, what, and why” assemble from facts that arrived at different times through different channels.
A query to GISM-0 draws from all three layers simultaneously. A well-formed retrieval question — the kind an agent actually needs to answer during real work — benefits from all three at once: temporal context from L1, semantic matches from L2, structural relationships from L3. That fusion, returned in a single API call, is the architecture behind the token efficiency results in the benchmark. The model receives a precise context because the retrieval was precise. Precision does not require a large prompt.
12
MCP Toolsread, write, search, query, ingest, and admin across all three layers3
Simultaneous Layersone ingest call populates L1, L2, and L3 automatically100%
Per-Deployment Isolationyour data does not share infrastructure with any other deployment, including ours<1s
Warm Recall (L1 + L2)time-series events and semantic documents return in under a second on warm cachesSelf-serve. Isolated. Yours.
GISM-0 deployments are available self-serve from the CleverThis dashboard today. Provisioning creates a dedicated Kubernetes workload, a persistent storage volume, an API key, and both an in-cluster service URL and an external HTTP endpoint. Ingestion accepts individual files via POST or directory paths for batch processing. The MCP server exposes all twelve tools directly to any agent runtime that speaks Model Context Protocol.
Per-deployment isolation is not a premium tier. It is the default. There is no shared layer between GISM-0 deployments. A document ingested into your deployment does not appear in any query run against any other deployment — including ours. Memory systems are where the sensitive things live, and a memory system with a shared wall is a different product entirely.
Who this is for
There is a category of developer who has been waiting for this announcement specifically: the people who read every Argus update looking for the sentence that said the underlying memory engine was available without the agent wrapper. Some of you wrote to us. Some of you filed the feature request with a specificity that suggested you had already thought through the API design and had notes. This launch is for you.
More broadly: GISM-0 standalone is for any team with an existing agent — one you built, trust, and are not replacing — that needs durable, structured, three-layer memory behind it. It is for applications that ingest events from multiple sources and need to answer time-structured, semantically-aware, and relationship-aware questions across all of them in a single query. It is for the platform engineer who wants the memory primitive and will build the application layer on top.
“You do not need to buy the watch to get the movement. The movement is now available separately.”
For the investors reading this — and we know you are reading this, because some of you told us, which was both flattering and slightly alarming — the GISM-0 standalone launch is the moment the CleverThis platform becomes properly layered. Argus is the vertical application. GISM-0 is the horizontal primitive. Every agent we build from this point forward runs on it. Every agent you build can run on it too. The platform story is no longer “one product built on a foundation”; it is “a foundation with an API surface and a growing set of products above it.” That is a structurally different business, and we are aware of the distinction.
The honest section (we include one in every article, on principle)
GISM-0 is a memory system, not an oracle. The quality of retrieval is bounded by the quality of ingestion: a well-organized, consistently ingested workspace returns excellent results; a neglected or selectively ingested one returns confident retrieval of whatever was actually ingested, which may not be the thing you wanted. The system is precise about what it stored. It does not editorialize, invent, or apologize. Structure your ingestion before you trust your recall. This is true of every memory system, including the human one, and we mention it because expectations calibrated correctly at the start produce fewer support tickets than expectations calibrated by disappointment.
The system has been running in production at CleverThis for several months. It is stable by every measure we have applied. We are a small team, and “stable by every measure we have applied” is the honest phrasing, not “exhaustively validated against every possible failure mode by a dedicated quality organization with a certification budget and a wall of monitors.” We say this so you can calibrate. We also say this because the alternative — claiming comprehensive validation for something built by fewer than ten people — would not survive contact with your first serious production incident, and we prefer to have the conversation now rather than then.
What comes next
We are also working on making provisioning faster. The current self-serve flow completes in approximately thirty seconds. We think this is acceptable. We also think “acceptable” is not the target, and we are working on it.
GISM-0 is the memory layer. The agent that runs on top of it is what you will build. Come tell us what you build — we genuinely want to know, and unlike the L3 knowledge graph on a cold start, we respond to emails on approximately the same day they arrive.

CleverThis is a sustainable AI gateway with hosted Actor endpoints — by the team behind CleverThis.
Join the newsletter
Product updates and engineering notes. No spam, ever.
