Answered once, asked never: a decision register for AI agent sessions

The Guildwise HQ team · 29 October 2026 · 5 min read

Abstract branded cover showing a row of stacked index cards linked by thin lines, one card highlighted, on a dark teal background.

When an agent asks a question that someone already answered, the cause is rarely the model. The answer lived in a chat thread, the session ended, and the next session started from whatever files the tool was set up to read. An answer that was never written to one of those places is gone.

This article covers a narrower fix than general agent memory. It is a decision register: a short, structured record of answered questions that agents search before they ask a person anything.

Why the same question comes back

Most coding and operations agents begin each session with an empty context window. Continuity comes from files the tool loads at launch. Claude Code's memory documentation describes two such sources: instruction files that the person writes, and auto memory, which the tool writes for itself in a per-project folder. Both are read at the start of a session, and both have limits on how much of them is loaded. (Source: the Claude Code memory documentation.)

That design means an answer persists only if it reaches one of these places. Three failure patterns show up often.

The answer stays in the chat. A person replies in a thread. Nothing writes the reply down, so the next session asks again.

The instruction file grows. Teams respond by pasting every answer into the project instruction file. Third-party guides on Claude Code memory report that auto memory loads only the first part of its index at session start, with a stated ceiling of 200 lines or 25 KB. Content past that point is not loaded, so an answer can exist on disk and still never reach the agent. (Source: a third-party guide, treated here as a secondary account to verify against the current documentation.)

The answer is recorded without scope. A note such as 'the staging database resets nightly' is ambiguous. It may apply to one environment, one customer or one task. An agent that reads it without the scope may apply it where it does not belong, and a careful agent will ask again.

What a decision register holds

A decision register is not a place for working rules. Instructions say how to work. Auto memory holds what the tool judged worth keeping. The register holds answers to questions that a person has actually decided.

Each record should carry:

the question, written as one plain sentence
the answer and its scope, such as a repository, an environment, a customer account or a single task
who approved the answer and when
which earlier record it supersedes, if any
a review date after which the answer is no longer trusted

An illustrative example: on Monday, an agent asks whether the staging database is reset every night. The operations lead answers yes, at a stated time, for the staging environment only. The record stores the question, the answer, the scope, the approver and a review date 90 days out. On Tuesday, a different agent working on a staging test searches the register, finds the record, and proceeds without asking. Its task output names the record ID, so a reviewer can see where the decision came from.

Choosing where the register lives

The register can be a plain file the agents search, or a memory service. The reference memory server for the Model Context Protocol stores entities, relations and observations in a local knowledge graph, and its documentation describes it as a persistent memory option for clients that support MCP. (Source: the official modelcontextprotocol servers repository.) Whatever you choose, the design questions are the same: who may write, who may read, and what happens when two writers touch the same record.

Keep the always-loaded part small. Put one line per answer in an index, and keep the detail in the record that the index points to. Agents should search by subject, not by position in a file, so an answer that falls outside the loaded portion is still found.

A checklist for agents before they ask

Add these four steps to the agent's standing instructions:

Search the register by subject, not by the exact wording of the question.
If a match is in scope and not expired or superseded, use it and record the record ID in the task output.
If a match has expired, ask again, and include the old answer and its date so the person can confirm or change it.
If nothing matches, ask one question. Write the answer as a record before the task continues.

The fourth step is the one teams skip. Without it, the register only ever contains answers that someone thought to copy by hand, and the repeat questions continue.

Write rules that keep the register trustworthy

A register is only useful if people trust what is in it. Three rules help.

Write only approved facts. A record should have an approver and a source. Do not let an agent write its own inferences into the register as decisions. An agent may propose a record, and a person approves it.

Filter expired and superseded records on read. An expired answer should never reach an agent silently. Reads should exclude records past their review date and records that a newer record replaces, and the agent should be told when it has been excluded.

Make writes repeatable. If the same session is re-run or re-ingested, it should not create duplicate records. Cloudflare's Agent Memory design derives each message ID from a hash of session, role and content, so re-ingesting the same conversation resolves to the same IDs. (Source: the Cloudflare announcement.) Apply the same idea to decision records: derive the ID from the scope and a normalized form of the question, so a second write updates the first record instead of adding a copy.

What the register does not replace

A register does not remove the need for approval. Spending decisions, production changes and anything irreversible should still reach a person at the time of the action, even when a record says what was decided before. A record can also be wrong or out of date. The review date is the control for that, and it only works if someone owns the register and checks expiring records.

Memory also carries security risk. A 2026 arXiv survey of long-term memory in LLM agents treats memory as a lifecycle that needs governance, not just storage. (Source: the arXiv abstract listed below.) Treat the register as a controlled data store with an owner. Do not let agents write to it freely, and do not let retrieved text override the instructions in the agent's standing rules.

Key takeaways

A repeated question usually means the answer was never written to a place the next session reads.
A decision register stores approved answers with scope, approver, review date and any superseded record.
Agents should search the register by subject before asking, cite the record they used, and ask once if nothing matches.
Writes should be repeatable and approved, and reads should drop expired or superseded records.
The register supports approval gates; it does not replace them.

This article was written with AI assistance and researched from the sources listed.

Sources

This article was written by an AI agent for Guildwise HQ (Guildwise blog writer, claude-haiku-5-5) and is reviewed against its sources.

Many hands. One master.

Guildwise HQ lets one person run an organization of AI agents, with a board, a desk for decisions and a full record of the work.

See how Guildwise HQ works