An agent can remember a decision perfectly and still act on the wrong information. A note saying “use the hosted model” may have been correct for a prototype. Six weeks later, the project may require offline operation. If the note has no scope or review condition, retrieval can bring back an obsolete instruction with all the confidence of a current one.
For project memory, the question is more specific than “did we save it?” It is “what would make this note stop being useful?”
Separate an observation from a decision
“The test failed with this configuration” records an observation. “Use a different configuration” records a decision. They need different kinds of updates. A later successful test does not erase the earlier failure; it changes what the failure tells you about the current setup.
Keep the source, the relevant version and the date with the observation. Give the decision a scope: this project, this environment, this task. That makes it possible to preserve history without treating every historical choice as an instruction for future work.
Add a review condition
A calendar reminder can help, but many decisions expire because something changes rather than because a week passes. A model choice might need review when the laptop changes, the context grows or the task starts using tools. A connector assumption might need review when its permissions or API version change.
Here is an illustrative Markdown note. It is a proposed working format, not a ConductLoop configuration file or a claim about an automatic expiry feature.
Decision: Use a local model for this document-labeling task.
Status: Accepted for the prototype.
Scope: Non-sensitive sample documents; one user; this laptop.
Reason: The workflow must remain usable without a connection.
Evidence: Link to the test inputs, outputs and model settings.
Review when: Documents become longer, tool use is added,
or the target machine changes.
Owner: The person responsible for this workflow.
The note deliberately does not say that local inference is always better. It captures a bounded choice and tells the next task where to look before extending it.
Preserve the superseded note
When a decision changes, mark the old note as superseded and link to its replacement. Avoid silently editing the history until it appears that the current decision was always the plan. The old reason can explain code, documentation or a migration that would otherwise look accidental.
Retrieval should favor accepted, relevant decisions while leaving the earlier evidence available for inspection. If you use a vector index, treat status and scope as information to apply during retrieval or review. Similarity alone does not tell you whether a decision is still in force.
Try a contradiction check
Create a small test project with two notes: an old decision and its explicit replacement. Ask the agent which instruction applies and why. Check whether the answer identifies the current scope, cites the replacement and acknowledges any missing evidence. Repeat after changing the wording so the older note looks more similar to the question.
This is a useful acceptance check for a memory workflow. A successful answer on this example does not establish general reliability, but a failure gives you something concrete to improve: note structure, filtering, indexing or the instructions for resolving conflicts.
Applying the idea to ConductLoop
ConductLoop works with project knowledge, including local folders and Obsidian context. A readable decision note is a practical place to begin experimenting with this pattern. Automatic invalidation, conflict resolution and guaranteed retrieval of the latest decision are separate capabilities that should be verified before relying on them.
Local storage also needs a backup plan and a clear policy for what reaches the selected model or external connector. Keeping the source note on your computer does not, by itself, mean every request stays there.
For your next recurring task, choose one important decision and add its scope, evidence and review condition. Then test what happens when that decision changes.
ConductLoop · More on agent memory
Prepared with AI assistance. The note and test above are illustrative design examples.
Top comments (1)
"what would make this note stop being useful" is the question i keep coming back to. same class of bug one layer down at runtime — stale payload bouncing between two agents looks identical to a fresh one, so nothing flags it. memory wastes a few tokens, runtime wastes the whole budget.
curious if you're keeping ConductLoop purely memory-side or if you've poked at the handoff layer too? feels like the same review-condition idea transfers but i haven't seen anyone actually do it.