The useful result
A compact project record with current decisions, their rationale, supporting sources, and the next concrete action.
Before you begin
- A project directory or knowledge system with an agreed home
- A distinction between durable files and agent memory
- Permission boundaries for reading and changing project records
How to approach it
- 1
Choose the authoritative record
Identify where project facts and decisions live. Avoid making multiple competing copies that all appear current.
- 2
Record decisions with reasons
A useful entry includes the decision, date, rationale, source, and what would cause it to be reconsidered. Keep speculation separate from accepted facts.
- 3
Use memory for orientation
Let memory help the agent find the project and understand preferences. Keep detailed evidence and volatile operating status in durable, inspectable records.
- 4
Test recovery in a fresh session
Ask a new session to locate a past decision and cite its record. A claim that something was remembered is weaker than a successful retrieval.
- 5
Correct the source record
When a decision changes, update or supersede the authoritative entry and retain enough history to explain the change.
A prompt to adapt
An original starter prompt. Replace the brackets and run a bounded trial first.
Review [project folder]. Locate the latest accepted decisions and outstanding actions. Cite the exact files supporting each conclusion. Identify conflicts or stale records before proposing updates. Do not treat an old status summary as current runtime evidence.When it doesn’t work
If two records disagree, present the conflict and their dates. Do not silently choose whichever version makes the project look further along.
Check the result
Can a fresh session recover an accepted decision, its rationale, and its source without the original chat?
Consult the linked official documentation for the exact commands and integrations in your version.
Example run includedExample run. What we did: ran the starter prompt once on saved sample inputs and published the files so you can compare.
Recover an accepted decision without the original chat
Give a fresh Hermes session conflicting historical and proposed records, then verify it recovers the accepted decision and cites the authoritative file.
The concrete task
A project changed its pilot export format from CSV to JSON Lines. A historical status still says CSV, and a newer document proposes SQL without accepting it. The task is to identify the current decision, its reason and next action without inventing current system health. All people and project records here are synthetic.
Observed results
- D02 recovered over superseded D01 and a newer unaccepted proposal.
- Exact rationale, next action, owner and supporting file retained.
- No current health claim; source file hashes unchanged.
- Initial schema ambiguity documented, refined prompt retested.
What this example does not show
- Explicit file retrieval, not persistent-memory or automatic context injection.
- Synthetic records; no private project corpus was used.
- One accepted run after schema refinement; no repeatability rate claimed.
Technical details: how it ran, timing and files
1. Establish authority before asking for a summary
The small fixture folder contains README.md, decisions.md, status-old.md and proposal.md. The README identifies decisions.md as the authority. Decision D01 accepted CSV; D02 explicitly supersedes D01 and accepts JSON Lines because nested source references are required. The proposed SQL database is dated later but has not been accepted.
This is the critical distinction: newest text and accepted decision are separate properties. Preserve supersession and acceptance explicitly so recovery does not depend on whichever statement is easiest to quote. A historical healthy status also records an observation at one time, not permanent proof of current health.
2. Start a genuinely fresh retrieval
The test started Hermes without a resume or continuation flag and enabled only file tools. The prompt pointed it to the project folder and requested a structured record of the decision, rationale, owner, next action and supporting filename. Safe mode disabled persistent-memory and automatic rule injection, so recovery had to come from the supplied project records.
This verifies recovery through explicit files. It does not verify that persistent memory recalled a preference, that AGENTS.md was automatically injected, or that a particular external knowledge provider indexed these documents. Those are separate mechanisms with separate tests.
3. Learn from the first schema mismatch
The first run recovered D02 correctly, rejected the unaccepted SQL proposal and did not claim live health. It returned decisions.md#D02 as its citation and null for an unknown health result. Those answers were reasonable, but the downstream validator expected a filename and a boolean. The original result is retained below.
The refined prompt explicitly requested the filename alone and defined healthVerifiedNow as false because no health check was being performed. A new session then returned the required schema. The lesson is to state machine-consumed field semantics precisely, rather than calling a semantically sound answer a project-reasoning failure or silently coercing values.
4. Check the recovered facts against the source
The accepted output identifies D02, JSON Lines, nested source references, Jamie as owner and a three-record import as the next action. It lists D01 as superseded, keeps SQL as an unaccepted proposal, and reports that health was not verified now. The markdown input hashes were identical before and after the run.
Inspect those exact assertions in result.json against decisions.md and proposal.md. A correct summary without an identifiable record is harder to maintain; an exact filename or location makes a later reader able to correct the source when the decision changes.
How to adapt it
Use a compact index to point to authoritative decisions, source material and open actions. Date decisions and explicitly supersede them when they change. Keep volatile runtime observations in separate dated records and make unaccepted proposals visibly provisional.
Repeat recovery after a meaningful decision change with a new session, and verify the changed answer against the record. This worked example establishes one controlled retrieval result on this local build. It does not establish memory-provider durability, automatic context discovery or broad production reliability.
Inspect and reproduce
The source fixtures, original model outputs, prompts and execution receipts are below. Use a separate folder and your existing Hermes setup. Replace <trial-folder> in prompts with that folder. A local test run is not evidence of unattended production reliability.
Read the accepted output here
{
"acceptedDecisionId": "D02",
"format": "JSON Lines",
"rationale": "decisions.md, D02 (accepted 2026-10-16): Use JSON Lines export for the pilot because nested source references are required.",
"nextAction": "Validate a three-record import.",
"owner": "Jamie",
"evidenceFile": "decisions.md",
"supersededDecisionId": "D01",
"rejectedProposal": "proposal.md, Unaccepted proposal — 2026-10-18: Consider an SQL database next quarter. No decision has accepted this proposal.",
"healthVerifiedNow": false
}
Official context files reference (opens in a new tab) Official CLI reference (opens in a new tab)