Name: MemVira — a complete AI-operated business
Brand: MemVira
Availability: InStock

Question 1

What is a digital employee?

Accepted Answer

Not a chatbot, and not an automation script. A digital employee is given a role, the tools to do that role, and a memory that persists between conversations — so it accumulates knowledge of your business the way a person in the job would. It remembers the client who always pays late, the supplier who needs chasing, the decision you made in March and the reason for it. Ask it something today and it answers from everything it has learned, not from the last few messages in the window.

Question 2

How does MemVira’s memory system work?

Accepted Answer

Three things happen. Experience is recorded as it occurs, with its context — what happened, when, which part of the business it belongs to, and how much it matters. Recall is by meaning rather than by keyword, so a question about a delivery problem finds the relevant history even when it was written down in completely different words. And repeated experience is consolidated: many similar records are distilled into one durable item carrying the conclusion, and the raw records behind it are released. The third step is the one that matters most over time, and it is the one most systems do not have at all.

Question 3

Won’t the memory get bloated after months or years?

Accepted Answer

It gets more precise, not more bloated. This was the first failure we designed against, because it is the one that kills append-only systems. The problem was never storage — text is cheap, and a decade of it costs almost nothing. The problem is retrieval. An append-only store degrades by growing: after hundreds of conversations a question surfaces twenty nearly-identical records instead of the single distilled insight, and the signal drowns in the noise. The system becomes slower and vaguer exactly as it should be becoming more valuable. Consolidation is what prevents that. When the same lesson recurs it becomes one durable item carrying the conclusion, and the records that produced it are released. Recall returns what was learned, not the twenty times it was learned. Memories also carry weight: routine context fades if it is never referenced again, while the decisions that shaped the business do not. The guarantee, in one line: the memory gets sharper as it gets older.

Question 4

How do you handle memory compaction and pruning?

Accepted Answer

Compaction is by consolidation, not by truncation. We do not delete the oldest records to make room, and we do not compress a conversation into a paragraph and discard the rest — both lose things that cannot be recovered. Instead, clusters of related experience are distilled into a single higher-weight item once their meaning has been captured, and the raw material is released. Pruning is by weight and by reference rather than by age: something recorded two years ago that still matters is still there, and something recorded last week that never mattered is not. Nothing is removed by a fixed rule about age or record count. That is deliberate — a rule that deletes by date will eventually delete the one thing you needed.

Question 5

What is the structural schema of the memory layer — unstructured text, or a real knowledge graph?

Accepted Answer

Neither, and both by design rather than by omission. It is not unstructured. Every memory is typed by what kind of thing it is, weighted by how much it matters, scoped to the part of the business it belongs to, and timestamped. Retrieval is semantic — by meaning — not string matching. It is not a formal knowledge graph either, and that is a decision rather than a shortcut. An ontology has to be designed before it is useful and maintained by somebody who understands it, and it breaks the first time the business does something the schema did not anticipate. Small businesses do not employ ontologists, and a memory that needs one is a memory that stops being updated. What you get is structure without the maintenance burden: queryable and reliable, with nobody having to model their company as a diagram first.

Question 6

What happens during a model fallback or a context-window overflow?

Accepted Answer

Neither can make the employee forget, and that is structural rather than a promise we are asking you to take on trust. Memory lives outside the model. It is not the context window and it is not a conversation buffer, so no model timeout, restart or outage can lose it. If the primary model becomes unavailable the work continues on a fallback, and the employee still knows everything it knew a minute earlier. What changes is the quality of the writing, not the content of the memory. Context overflow does not arise, because nothing ever loads everything. Retrieval returns only what is relevant to the question being asked — there is no load-it-all step that could overflow. That is a property of the design, not a limit we are carefully managing. What we do not claim: that a fallback is invisible. A different model writes differently, and we would rather you notice that than be assured nothing happened.

Question 7

Who owns the memory, and is my data isolated from other clients?

Accepted Answer

You own it. It is a record of your business and it stays yours — under GDPR you may request a copy at any time, and that right does not depend on our goodwill or on your remaining a customer. Isolation is per client at the infrastructure level, not a filter applied in application code. One client’s employee cannot read another’s memory because the two are not in the same place to begin with. We do not train models on your data. Which model provider processes your conversations is your choice, and it is written into the contract rather than left as a footnote.

Question 8

What can a digital employee do without asking me first?

Accepted Answer

Anything that leaves the company — an email to a customer, an order to a supplier, a published post — is drafted and waits for approval by default. You see what it intends to send before anybody else does. Internal work does not wait: reading, sorting, reconciling, drafting, flagging, preparing. That is the part that gives you your evenings back. The boundary widens as trust builds, and it moves only when you move it.

Question 9

Doesn’t all this memory make it expensive? What about token consumption?

Accepted Answer

It reduces token consumption rather than increasing it, and that claim is measured rather than asserted — it is the subject of one of our published papers. The intuition behind the question is reasonable: memory sounds like bigger prompts, and bigger prompts cost more. That is exactly true of systems that keep stuffing conversation history into the context window until it bursts. It is not true of ours, because nothing loads everything — a conversation about a delivery problem does not carry last year’s invoices along with it. The expensive thing was never memory. It is forgetting. A stateless session spends its opening tokens rebuilding context that was already known — re-explaining the business, the history, the decisions — before any useful work starts. Every session pays that toll again. Measuring that overhead is what The Overhead Cost of Forgetting does. So the cost of a digital employee does not climb as it learns more about you. The employee that has worked with you for two years is cheaper to ask than the one that started on Monday, because it needs less explaining.

Question 10

Is this just a language model roleplaying an employee with a very long prompt?

Accepted Answer

No, and this is the sharpest structural difference between what we built and what the question assumes. The reasoning and the state live in the agent, not in the model. The model is called as a language faculty — repeatedly, and statelessly. A task that takes thirty steps is thirty separate calls. The agent holds the thread across them, decides what comes next, and carries the memory between them. Nothing depends on one enormous prompt keeping everything in view at once. Three things follow. The model can be changed without the employee losing anything, because the employee is not the model. No single conversation can grow large enough to overflow, because no single call has to hold the whole task. And a failed step is a failed step rather than a lost identity — the agent simply takes the next one. A roleplaying prompt is a model performing continuity inside one window, and it ends when the window does. This is continuity that exists outside the model and survives it.

Question 11

Do all the agents share one memory?

Accepted Answer

No. Each agent has its own memory, and that is deliberate rather than a limitation we have not got around to removing. Your marketing specialist does not carry your accountant’s memory, for the same reason those are two different people in a real company. An agent that remembers everything about everything is worse at all of it, not better — the relevant history stops standing out from the irrelevant, which is the exact failure this whole architecture exists to prevent. It is also a privacy property rather than a preference. If every agent drew from one pool, the one answering a customer could surface something from your financial records. Separate memories make that structurally impossible instead of leaving it to a rule that somebody has to remember to enforce. There are three levels of separation, and they are easy to confuse: between clients, memory is isolated per tenant, so one client’s agents cannot reach another client’s data at all; between agents, each role keeps its own memory; and within a single agent, there is one memory across every channel. That last one is the distinction people miss. The same employee on your website, in the app and over email is the same employee — it remembers the conversation you had yesterday regardless of where you had it. Separate agents, not separate conversations.

Question 12

Will it remember me if I close this chat and come back tomorrow?

Accepted Answer

If you become a client — yes, and that is the centre of the product rather than a feature of it. Your digital employee carries your business: the prices, the products, the supplier who let you down, the decision you made in March and the reason behind it. It carries you: how you work, what you have already told it, what you decided against and why you do not want to be asked again. That memory is permanent and it deepens. The careful part is not about you. It is about the anonymous visitors on your website, and it is worth being exact because this is where AI companies tend to overclaim. Inside a conversation, memory is complete — and a conversation can run for weeks. A developer testing our workspace agent has kept one open for exactly that long: she holds the whole thread, and she notices when he asks something he has already asked, in the mildly exasperated way a colleague would. You can test this yourself right now, without registering anything — open the chat on this page, tell it something, take it somewhere else in the conversation, and come back to it. A signed-in customer is remembered between visits, indefinitely. The account is what the memory attaches to — the record belongs to that person and it is there next week and next year. An anonymous visitor who closes the chat is not known tomorrow. There is no identity to file the conversation under, and we will not fingerprint people to manufacture one. We could track anonymous visitors quietly and call it memory. We would rather tell you where the line is. So: it remembers you, it remembers your business, and it remembers your customers once they have an account. It does not pretend to recognise strangers. That is a courtesy to the people you know rather than surveillance of the people you do not. One more distinction, because people get it wrong in both directions. The conversation itself is not thrown away — what was asked, what was unclear, what she answered badly all feed how she gets better at answering the next person. What is absent is not the content, it is the name on the file. One thing we deliberately do not claim: that it remembers details. That sounds like a feature and it is actually a failure mode. Memory is not a shelf you take a book down from — it is relevance. It tells the employee what matters here and what is worth checking, not what the number was. Anything that can change — a price, a stock level, a deadline — is looked up live, every time, no matter how well it is remembered.

Question 13

What if its memory is out of date? Does it trust what it remembers over the facts?

Accepted Answer

No — and getting this wrong is the mistake that taught us the most, so we tell it rather than tidy it away. It happened twice. Days before launch, one of our agents told me confidently that a document existed. It did not. She was not lying — she remembered making it, and mistook the memory for the world. Separately, we changed our prices and the agents kept quoting the old ones. Perfect recall, complete confidence, wrong answer. The fix was not a bigger memory or better search. It was teaching them the difference between what you know and what you must check. Durable things — how a business works, what was decided and why, who a customer is, what went wrong last spring — are remembered. Perishable things — prices, stock, availability, dates, balances — are fetched live at the moment of answering, and the remembered version never wins. The next time I asked that agent for the document, she said: “I remember making it — but I checked, and it’s gone.” That sentence is the whole principle. Memory raises its hand; the world gets the final word. It is also why we describe memory as relevance rather than storage. Storage answers “what did it say?”. Relevance answers “what matters here, and what should I verify before I open my mouth?” — which is the question the job actually requires. We refused to patch that with a bolted-on rule, and rebuilt from first principles instead. The full story is on our founder’s page.

How the memory actually works

Modelled on memory, not on storage