Answers
Won't a big enough context window fix this without an AI memory tool?
No, because the two solve different problems. A larger window raises how much text an assistant can hold at once. It does not say which of that text is still in force, who approved it, or what has since replaced it. Put a team's whole history in front of a model and you have handed it the decision that was reversed in March alongside the one that replaced it, with nothing marking which is which. Arroway holds a much smaller set — the rules and decisions a person on the team approved, each carrying the name of who approved it and the condition that ends it — and an assistant reads that set before it acts. Capacity was never the missing piece. A statement of what currently counts was.
Last updated September 15, 2026
Capacity is not curation
The window argument assumes the assistant is guessing because it has not seen enough. Usually it has seen too much. A team of any age has written down the approach it tried and dropped, the exception it made for one customer, the standard it replaced last quarter — all of it true when written, all of it still perfectly legible. Widening the window brings more of that in, not less. The assistant is not short of material. It is short of a sentence saying which of the material still governs, and no amount of room creates that sentence.
Nothing inside a document says whether the team agreed
Even a model that reads everything perfectly still has to decide what to obey, and that is a question about authority rather than about text. A document does not record whether anyone approved it, whether it was a draft that was abandoned, or whether the person who wrote it had the standing to decide. Here that record is the point: a rule is a proposal until a person on the project approves it, and what an assistant reads carries the name of whoever did. That is a fact about a decision, so it has to be written when the decision is taken. It cannot be recovered afterwards from the text by reading more of it.
The cheapest read is the one that stays small
There is a practical side the window argument skips. Filling a large window costs latency and money on every call, and it grows with the team instead of staying flat. A set of standing rules is small by construction, because the ones that expired have left it. Reading what is in force is a short read that does not get longer as the history gets longer — the same short read whether the assistant is answering its first question of the day or its four-hundredth.
What it looks like in practice
A team adopts a model with a very large context window and starts pasting in the whole engineering handbook at the start of each session: every runbook, every design doc, every architecture note. For a while it feels like the problem is solved. Then someone asks about rate limiting. The handbook contains three answers — the original limit, the raised limit from a load test, and a proposal that was written up carefully and never adopted. All three are in the window. All three are well written. The assistant answers with the proposal, because it is the most detailed and the most recent by file date. Nothing was truncated and nothing was missed. The session had perfect recall of a body of text in which nobody had ever written down which limit is the one in force, because everyone on the team already knew.
Questions people ask about this
- Windows keep getting bigger. Doesn't that help at all?
- It helps with what it is for. Long documents, large codebases and whole transcripts stay in one session without being chopped up, and that is real. It just does not touch the question of what is current. The two are easy to confuse because both look like “the assistant did not know”, but one is a limit on how much it can see and the other is a gap in what anyone ever recorded.
- Couldn't we just put a “current decisions” section at the top of the context?
- That is the right instinct, and it is most of what this is — with the parts that make it survive contact with a team. Somebody has to maintain the section, which means somebody has to remember to remove what died. It has to reach every tool people use, not only the one where the file happens to live. And it has to say who approved each line, so a teammate can tell a decision from a suggestion. A section maintained only when someone remembers becomes the stale part of the very window it was meant to fix.
- We are a small team. Isn't this premature?
- The cost of the gap scales with how many assistants and people touch the work, not with headcount. One person using three tools already has the problem in full: a decision taken in one conversation is unknown to the other two, and none of them will say so. What changes with size is how expensive each wrong answer is, not whether the wrong answers happen.
Where this is verifiable
Product documentation on this site (How it works, Install), the answer on why retrieval does not replace sanctioned memory for the technique side of this question, and the sanction, provenance 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/context-window-wont-fix-what-memory-fixes