Answers
How do I keep my AI agents from forgetting decisions?
Stop asking the agent to remember, and make every session start by reading. An agent does not carry decisions between sessions: the conversation ends, the context is compacted, a different agent picks up the work, and what was settled on Tuesday is simply not in front of the model on Wednesday. The usual fixes — a decisions file, a vector store, a checkpoint — solve storage, and storage was never the hard part. What they leave open is whether the next session actually reads before acting, and whether it can tell a decision still in force from one that was overtaken. Arroway covers both with nothing to build: sessions open by reading the project, each decision carries who made it and what would end it, and a replacement retires the old one. It works the same with one agent and no team — the reader is simply the same agent, tomorrow.
Last updated September 24, 2026
Forgetting is a missing read, not a missing memory
When an agent contradicts something decided last week, the decision usually still exists somewhere — in a chat log, a notes file, a summary the previous session wrote. What failed is that nothing put it in front of the model before the new session started working. Adding more places to store decisions does not change that; it adds more places for the next session not to look. The fix has to sit at the start of the session: a read that happens first, every time, before the agent has formed its own view of the task.
A decisions file only works if every session opens it
A markdown file of decisions is a reasonable first instinct, and it fails the same way every time: it is read when the agent happens to open it, or when someone remembers to point at it. With Arroway the opening read is made a step of the session by the tools themselves, not an instruction the agent may or may not follow; it is ordered by the task the agent says it is about to do, and it reports what it delivered and what did not fit. An agent that has not read cannot write into the project either, so a session that skipped the rules cannot quietly record over them.
Remembering the wrong version is worse than forgetting
An agent that forgets a decision asks again or makes a visible mistake. An agent that remembers a decision that was later reversed acts on it with confidence, and nothing in its output looks wrong. Stores that keep everything are prone to exactly this, because the old decision and the new one are both there and both relevant to the question. In Arroway a new decision is recorded as replacing the old one, the old one leaves the read with the reason, and two entries that contradict each other arrive marked as a conflict instead of letting the agent pick one silently.
What it looks like in practice
One developer, one coding agent, one project. On Monday they decide to drop the old version of their public API: no new endpoints for it, and no fixes unless they are security fixes. The agent agrees and works that way for the rest of the day. On Wednesday a new session starts. Monday's context is gone, and the agent is asked to fix a bug that happens to live in an old-version endpoint. It fixes it carefully, adds a test, and suggests porting two new endpoints back to the old version for consistency. Nothing about this is careless. It simply never received Monday. With Arroway, Monday's decision was recorded at the end of that session, with the developer as the person who made it and “until the old version is switched off” as its ending. Wednesday's session opens by reading the project, and the decision is in the read before the bug is. The agent leaves the old endpoint alone and says why.
Questions people ask about this
- Is this only for teams? I work with one agent.
- No. The reader of a decision can be another person, another agent, or the same agent in its next session, and that last case is the whole problem this page is about. Switching machines, switching agents mid-task, resuming after the context was compacted — each of those is an agent reading what an earlier session decided, and each is handled the same way whether there is one person on the project or twenty.
- Can't I just put my decisions in the system prompt?
- For a handful that never change, that works. It breaks at the two points that matter. A system prompt has no way to mark a line as overtaken, so reversing a decision means finding and editing every copy. And it grows until it is either loaded in full every time or quietly trimmed. Arroway keeps each decision once, orders the read by the task at hand and reports what fit, so a long history of decisions does not turn into a long prompt.
- Who writes the decisions down — me or the agent?
- Mostly the agent, at the end of the session, which is the part people skip. What you state or approve in the conversation is recorded as decided by you. What the agent inferred on its own is recorded as a proposal and reaches the next session marked as unconfirmed, not as a rule, until a person approves it — so a guess made on Tuesday does not come back on Wednesday looking like a decision.
Where this is verifiable
Product documentation on this site (How it works, Install), the answers on how team decisions reach AI, on rules that slip a few messages later and on scheduled AI routines losing the thread, and the opening-read, supersession, conflict and sanction rules in the sanctioned product spec. The decisions file, vector store and checkpoint are described as practices, not as any vendor's product. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/how-to-keep-ai-agents-from-forgetting-decisions