That is the shortest path to knowing whether FerriteMem fits your work. Not a demo on our data — a pilot on yours, scored on completeness. Write to sales@ferritemem.com and we will reply with a shape and a number, not a discovery process.
Try the pilot test. Ten questions, each with a known answer. Tap a question to mark whether everything relevant came back.
One question is missing a record. A search scored on “found something” would still report a perfect ten.
An illustration. In a pilot you score your own ten.
Connect FerriteMem as a memory tool to any agent speaking the open Model Context Protocol. The retrieval verbs are exposed; the write verbs are not registered on that surface, so it is read-only by construction rather than by policy.
Good for: agents that should consult memory but never change it.
Call it from your own application — store a record, ask a question, receive cited evidence. JSON in, JSON out, key-authenticated, language-agnostic. A write returns only once the record is persisted and searchable.
Good for: your own application, in any language.
Every capability is callable from a shell, a scheduled job or a pipeline — for bulk ingestion and anything that belongs in your existing automation rather than in an application.
Good for: bulk loads, scheduled jobs and pipelines.
Point it at a directory and it indexes incrementally. It also reads each file’s permissions and carries them into the record, so who may retrieve a document is inherited from who may read the file rather than configured a second time and allowed to drift.
Good for: shared drives where file permissions already say who may see what.
A read-only interface for asking questions and inspecting what came back: the records, their citations, and the confidence assigned. It is how a non-engineer sees the same evidence an auditor would.
Good for: reviewers, auditors and anyone who is not an engineer.
FerriteMem supplies no model and does not care which you run — yours, your customer’s, or whichever you move to next year. It answers on demand, when your agent asks, and stays silent otherwise: nothing is pushed into a context window on the chance it might be needed. Swap the model and the memory is unchanged.
Good for: keeping your memory when you change models.
The engine and its database ship as a single image with one data volume. On-premise, in your own cloud, or on an isolated host. Every third-party component ships under a permissive licence permitting redistribution, attributed in a notice file inside the image.
Good for: air-gapped hosts and teams that want one thing to deploy.
All of them address the same engine and the same records. There is no “API edition” behaving differently from the appliance — a result you see in the panel is the result your agent receives.
Sovereignty is not a feature we added; it is a consequence of having no generative model on the write path or the read path. There is nothing to call out to.
On-premise, in your own cloud tenancy, or on an isolated host. There is no hosted service you depend on us to keep alive.
No outbound route is required at query time. It runs on segmented and air-gapped networks.
No telemetry, no licence check, no usage reporting. If the machine has no route out, nothing degrades.
We have no access path to a deployment — not a support tunnel, not an update service that reads your data.
The engine’s matching and ranking models are fixed and never updated from your data, and there is no generative model to fine-tune — so this is a property of the architecture rather than a policy that could change.
The deployment does not depend on our continued existence. Source escrow terms are available for a signed engagement.
Corpora are isolated, so a retention obligation is a single operation rather than a project.
Is any of these a hard requirement for you today?
If it is, we are not the right choice today. We would rather you learn that here than three meetings in. Tick what applies.
Nothing ticked. Tick anything that is a hard requirement for you today.
Still want to talk? Draft your emailBefore any of the four stages below, there is a shorter conversation worth having. We show you three things on our own machine, with a corpus you can see is synthetic. Each is something you cannot check by reading a specification, and each takes a few minutes.
We ask for every record of a kind and count what comes back, against a corpus where the right answer is known. Then we show you the one a relevance-ranked search leaves out — and why it left it out. This is the difference between the chatbot question and the audit question, and it is checkable in ten minutes.
Drawing of the demo, not a measured result.
We ask a question, ask it again, and compare the two results line by line. Nothing differs, because there is no sampling and no model whose version can drift underneath a result. Most systems fail this quietly, and most people have never thought to test it.
Drawing of the demo, not a measured result.
Two credentials with different permissions, the same question, different answers — and the restricted record absent entirely rather than ranked lower. The check runs here every day against eight queries that must return nothing and four that must return something.
The squares show the daily check’s eight and four.
You bring nothing and install nothing. If what you see is worth pursuing, the next step is the pilot described below — on your records, your hardware, and your questions. If it is not, you have spent half an hour and we have both learned something.
Tell us the corpus, the shape of the questions and the constraints you are under. We reply with whether this fits, how it would be deployed and what it would cost — in writing, early. If it does not fit, we will say so.
You leave with: a fit, a shape and a price, in writing.
One corpus, your hardware, ten questions where you already know the answers and where a miss would matter. Scored on completeness: for each question, did everything relevant come back? That number settles more than any benchmark on this site.
You leave with: a completeness score on your own ten questions.
One container, one data volume, on your infrastructure, connected through whichever interface suits your stack. Retrieval settings are measured on your corpus and recorded with the measurement that justified them.
You leave with: FerriteMem running on your infrastructure.
With the people who built the engine, on the terms described above. Source escrow terms are available for a signed engagement.
You leave with: a direct line to the engineers.
sales@ferritemem.com
To make the first reply more useful, include the corpus you have in mind, roughly how large it is, and one real question you would want answered from it. Fill in the three boxes and the email writes itself.
Where the records live and whether they can leave that place. What a missed record costs you. Whether “is that all of it?” is a question anyone actually asks in your work — because if it is not, you may not need this, and we would rather tell you early.