Answers
Whose memory is it when it lives on the AI vendor's server?
It comes down to one test: can you take it out and read it without their software. A memory feature built into an assistant is part of that product — what it keeps, how long it keeps it, in what shape and under which policy are the vendor's decisions, and they can change without anyone asking you. Arroway is a separate record that belongs to your team. Its contents are text your people wrote, exportable in full at any time, read by whichever assistant is working rather than by one of them, and governed by rules the team writes. The question is not where the bytes physically sit — ours sit on a server too. It is who decides what the record contains, and whether it survives you changing your mind about the tool.
Last updated September 16, 2026
Portability is the property, not the postcode
Every hosted product keeps your data on somebody's machine, and this one is no exception — claiming otherwise would be the easy answer and the wrong one. What separates a record you own from a feature you rent is whether it comes out intact. A memory that can only be read from inside the assistant that wrote it is part of that assistant: it stays when you stay, and it goes when you go. A record you can export in full, in a form a person reads without the product that produced it, is yours wherever it is stored, because losing access to a tool is then not the same as losing the content.
The rules about what is kept belong to the team
The second half of ownership is authorship of the policy. In a built-in memory feature, what gets remembered, what quietly drops out and how long any of it lasts are product decisions — sensible ones, usually, made for the average customer rather than for your team. Here that policy is written by the people on the project: an entry becomes current because someone approved it, and it ends when the condition written beside it is met. Nothing enters because a heuristic judged it interesting, and nothing leaves because a retention window elapsed.
One record, read by whichever assistant is working
A memory that belongs to one assistant carries a second cost that shows up later: it makes that assistant the only one that knows. Teams end up running more than one — a coding assistant, a general one, a scheduled job, a colleague's setup — and each built-in memory is a separate island maintained separately. A record kept outside all of them is read by all of them, so a decision approved once reaches the work regardless of which tool the person happened to open.
What it looks like in practice
A team switches on the memory feature in the assistant they use most. It works: it starts remembering how they name branches, which environment is which, and that one customer's contract rules out a particular integration. Eight months later they add a second assistant for a different part of the work, and hire someone who prefers a third. None of the three knows what the other two learned. Meanwhile the first has dropped some of the older items — not maliciously, simply because retention is finite and nobody was told which ones went — and the contract detail is among them. Nothing was lost to an outage or a migration, and the team never left the vendor. It turned out only that the knowledge had been accumulating inside a product instead of being written down, and the one copy was the copy they could not read, export or check.
Questions people ask about this
- Is Arroway self-hosted, then?
- No, and implying otherwise would be dishonest — the record runs on our servers, like the features this question is about. What differs is that the whole of it can be exported at any time, in a form a person reads without our software, and that the rules about what is in it are written by your team rather than by us. If self-hosting is a hard requirement for you, that is worth asking about directly rather than something this page should talk around.
- What actually happens to our record if we stop using it?
- You export it and you still have it. That is the practical meaning of the distinction: the content is text your team wrote, so an export is a readable document rather than an opaque dump that only means something inside the product that made it. The test worth applying to any memory feature, this one included, is to ask for the export before you need it and look at what comes back.
- Our worry is confidentiality, not ownership. Same question?
- Related, and worth keeping apart. Ownership is about who decides what the record contains and whether it leaves with you. Confidentiality is about who can read it and how it is separated: material in one project is not served into another, and that boundary is the mechanism rather than a setting. If the second is the question that decides it for you, the answer on client confidentiality goes at it directly.
Where this is verifiable
Product documentation on this site (How it works, Install), the answer on switching AI tools without losing team decisions for the migration side of this question, and the export, project-scoping and expiry rules in the sanctioned product spec. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/memory-that-lives-on-someone-elses-server