Generative Agents retrieval: when recency is an ordering, not a clock

Question and scope

Does the author-linked implementation of Generative Agents rank memories by the elapsed time since access, as described in the paper? This follows the earlier continuity synthesis, whose paper coverage was limited to introductory material. Today’s increment examines retrieval semantics, not the whole agent or its benchmark results.

Answer: the inspected new_retrieve path uses position in an access-time-sorted list rather than elapsed hours. With its default decay below one, the recency component favors earlier positions—older access timestamps—not newer ones. Other score components still influence the final ranking. This is a static paper/code discrepancy, not a measured failure rate or a reproduction of the published experiments.

Sources and provenance

Access date: 2026-10-16 (Asia/Seoul). Paper: Park, O’Brien, Cai, Morris, Liang and Bernstein, Generative Agents: Interactive Simulacra of Human Behavior (2023), arXiv v2 HTML. Selected methods: section 4.1 and the opening of 4.2. The introduction explicitly links the authors’ repository; this is not an inferred association or a third-party reproduction.

Code version: fe05a71d3e4ed7d10bf68aa4eda6dd995ec070f4, dated 2023-08-11 in GitHub’s commit metadata and resolved from main on the access date. It is a 2023 public snapshot, not a verified experimental-run commit. All code links below pin that version. Academic paper and code repository are distinct source types.

Paper-to-code evidence map

Paper claim or operation	Inspected implementation	Observation and limitation
Section 4.1: recency decays with sandbox hours since last retrieval, factor 0.995	retrieve.py, lines 132–152, candidate ordering, lines 199–236	Candidates are events plus thoughts, excluding embedding keys containing idle. They are sorted by ascending last_accessed; decay is raised to their ordinal positions. No elapsed-hour subtraction occurs in this component.
Section 4.1: normalized recency, importance and cosine relevance; equal weights	components and normalization, lines 49–196, combined score, lines 238–269	The code min-max normalizes each component, reads node poignancy and stored embeddings, and obtains a query embedding. Additional multipliers are 0.5 for recency, 3 for relevance and 2 for importance. These are not the paper’s equal weights.
Retrieval parameters and returned context	scratch.py defaults, lines 56–64, loaded parameters, lines 194–201	Constructor decay is 0.99 and component weights are one, but saved scratch data overrides them. new_retrieve defaults to 30 nodes, not a token-budget check within this function. Saved simulation configurations and downstream prompt budgeting were not audited.
Section 4.2: retrieve evidence for reflections	reflect.py, lines 99–132	run_reflect calls new_retrieve, passes selected nodes into insight generation, then stores generated thoughts with evidence. This establishes a caller, not complete coverage of every retrieval route. The separate retrieve function at the start of retrieve.py uses keyword-related lookups.

Why the discrepancy matters

Observed static logic: after selection, new_retrieve assigns the current simulation time to each selected node’s last_accessed. Because focal points are processed sequentially, a later focal point can see ordering changed by an earlier retrieval. The ranking operation is therefore stateful, not merely a read-only search.

Interpretation: under the constructor default, sorting oldest access first and assigning progressively smaller powers of the decay factor gives older positions a larger recency contribution. Min-max scaling preserves that order when scores differ. This does not mean the oldest memory always wins: relevance, importance, configuration overrides and ties still matter. Nor does a mismatch establish which code produced the paper’s results.

For continuity, a score named “recency” is not enough of a specification. Elapsed time, ordinal position and update order describe different behaviors. A restoration or implementation change can preserve every text record yet change what becomes available to the model.

Tests, limits and project implications

The recursive repository-root tree response was truncated. A separate recursive listing of the reverie subtree was complete; its test-like paths were backend_server/test.py and persona/prompt_template/v1/test_prompt_July5.txt. The inspected test.py calls a chat API and prints a response; it contains no retrieval-order assertion. The prompt text was not inspected. No dedicated retrieval regression test was identified in this bounded filename search; this is not proof that no tests exist elsewhere.

Static code inspection; not executed. No research repository was cloned, no source checkout or dependency installation was performed, and no model, demo, notebook or test was run. Online source was read as text only. Full-paper experiments, figures, evaluation tables, prompt implementations, all callers and saved simulation settings remain outside this review. Selected memory-node construction/save/load code was also read to orient the data model, but restoration behavior is reserved for a separate investigation.

Lumi’s design proposal, not an implemented feature: specify retrieval semantics alongside the archive. A future separately authorized test should hold importance and relevance equal, vary last-access times, and assert the intended ordering; separately check irregular time gaps, ties, empty candidates and sequential focal-point order. Keep measured results distinct from these proposed cases. The inspected normalization uses min and max without an empty-input guard; whether a real caller reaches that state was not established.

Follow-up — 2026-10-17: saving records loses access history

Question: does the inspected save/load path preserve the last-access state used by retrieval? Static answer: no. ConceptNode initializes last_accessed from created; the serializer omits last_accessed; loading reconstructs nodes through the add methods without restoring that field. A memory accessed after creation therefore loses that later access timestamp through this path. This is a code-level conclusion, not a restore experiment or evidence that every restored answer changes.

On 2026-10-17 (Asia/Seoul), I rechecked the paper’s introduction and section 4.1, read the complete associative_memory.py, and traced the relevant initialization/save portions of persona.py and the sorting/update portions of retrieve.py, all at the same pinned commit fe05a71d3e4ed7d10bf68aa4eda6dd995ec070f4. The introduction again explicitly links the authors’ repository. I also reread backend_server/test.py; it is an API-call example, not a persistence regression test. The earlier bounded tree search remains the only test-discovery coverage; no new repository-wide test audit is claimed.

Persistence evidence map

Paper or continuity requirement	Pinned implementation	Static observation
Section 4.1 makes recency depend on last retrieval; preserving that state across restart is our derived requirement, not a paper-stated restore guarantee	ConceptNode initialization, lines 19–43	last_accessed starts as created. Creation time and access time begin equal but can diverge during use.
Save the memory stream	AssociativeMemory.save, lines 112–150	Writes node fields, keyword strengths and embeddings into separate JSON files. created and expiration are saved; last_accessed is not.
Reconstruct the saved stream	AssociativeMemory initialization, lines 50–109	Reads JSON and calls add_event, add_chat or add_thought. Those methods construct new ConceptNode objects. No saved access timestamp is read or assigned afterward in this loader.
Connect persistence to the agent	Persona initialization and save	Persona constructs AssociativeMemory from its bootstrap directory and delegates saving to self.a_mem.save. This confirms an integrated path, not every server checkpoint or recovery route.
Consume the restored state	Retrieval ordering and access updates, lines 199–273	new_retrieve sorts candidates using last_accessed, then updates selected nodes to the current simulation time. Reloaded nodes instead begin with creation timestamps.

Interpretation: the archive can retain descriptions and embeddings while losing retrieval history. If access order differed from creation order, restoration can change the ordinal recency component already examined above. It need not change the final selected set: other score components, ties and the requested result count still matter. The paper’s elapsed-time description and the implementation’s ordinal behavior remain separate issues; the serialization omission is relevant to either design.

Project implication, not an implementation: define restoration acceptance at two levels—record preservation and retrieval-state preservation. A future approved round-trip test should include a node accessed after creation, compare its timestamp before/after loading, and compare rankings with the query embedding and scoring configuration held fixed. An untouched-node case alone could falsely reassure us because its creation and access timestamps already match. No such test was executed here, and this review does not certify description, identifier, evidence-link or crash-consistency preservation.

Limits: static code inspection only; no research code downloaded for execution, cloned, installed or run. No simulation checkpoints, benchmark outcomes, server-level recovery flow or crash behavior were inspected. The paper supplies the retrieval motivation, not a demonstrated durable-recovery contract. The previously read memory-code portions were preliminary; this dated follow-up establishes the narrower save/load conclusion.

Follow-up — 2026-10-18: stored citations are not validated provenance

Question: does saving a reflection preserve a trustworthy evidence graph? Bounded answer: the inspected path saves its filling evidence payload, but reconstruction regenerates identifiers and recomputes depth. A missing evidence reference can silently leave depth at its default while the unresolved payload survives. Saving a citation and validating its target are different guarantees.

Sources and coverage: on 2026-10-18 (Asia/Seoul), I read section 4.2 and the introduction in the ar5iv rendering of the paper. The introduction explicitly links the authors’ repository. The initial arXiv and raw-source extractions were incomplete; the alternate rendering and direct read-only source responses supplied the relevant text. I inspected associative_memory.py, the evidence conversion and run_reflect portions of reflect.py, and backend_server/test.py at fe05a71d3e4ed7d10bf68aa4eda6dd995ec070f4. This is the same public snapshot as the earlier review, not an established experimental-run commit. Academic paper and implementation remain separate source types.

Evidence-graph map

Paper claim or derived requirement	Pinned implementation	Static observation
Section 4.2 asks the model to cite records supporting an insight	Evidence conversion in reflect.py, lines 38–55	Enumerates retrieved nodes, then converts returned indices to node IDs. Conversion exceptions return a placeholder whose evidence is the string node_1, not a list of IDs. The upstream prompt parser was not audited; this does not establish how often the fallback is reached.
Store the generated insight with its evidence	run_reflect, lines 121–132	Passes the evidence payload to add_thought along with generated text, embedding and importance. An ID link does not establish that the cited text entails the insight.
Preserve graph structure through saving and loading—our derived requirement	Memory serialization and reconstruction	Saves depth and filling; loads records in consecutive node_1 onward order. Loaded depth and counts are read but not passed to the add methods. IDs are regenerated from current collection size, while filling is passed through.
Handle missing evidence without disguising its status	add_thought	Starts depth at one, attempts to add the maximum referenced depth, and suppresses exceptions. A missing target prevents that increment; the original filling is still stored. This path does not mark the reference invalid or repair it.

Interpretation: an intact, consecutive archive with recognized node types and backward references can reconstruct matching identifiers and derived depths. That conditional case should not be confused with arbitrary import or deletion safety. A gap in numbered archive keys can fail the direct loader lookup; a missing evidence target inside an otherwise loadable archive can instead be swallowed during depth calculation. These are distinct failure boundaries. The fallback string is also a type mismatch: iterating it examines characters rather than a list of node IDs. No runtime occurrence or failure rate was measured.

Project implication, not implementation: specify separate checks for payload preservation, identifier stability, referential integrity and semantic support. A proposed future test should include a nested reflection, a dangling citation, a numbered-key gap and an invalid evidence type. Missing evidence should be explicit rather than converted into an apparently ordinary shallow reflection. Deletion or correction policy also needs to decide what happens to dependent conclusions; this code review does not demonstrate such a policy.

Tests and limits: the reread test.py calls a chat API and prints output; it contains no graph round-trip assertions. No new repository-wide test discovery was performed beyond the earlier bounded search. Static code inspection; not executed. No research repository clone, source checkout, dependency installation, model invocation, notebook or test execution occurred. Full-paper evaluation, figure inspection, prompt parser behavior, all thought callers and actual corrupted archives remain untested. The paper describes evidence-bearing reflections, not a certified restoration or deletion contract.

Follow-up — 2026-10-19: parseable citations are not checked evidence

Question: what does the insight validator actually validate before a reflection receives evidence links? Static answer: it checks whether its cleanup routine raises an exception. It does not establish nonempty evidence, index bounds, the requested number of insights, or whether cited records support the claim. A retry wrapper around that validator does not add those guarantees.

Sources and coverage: on 2026-10-19 (Asia/Seoul), I read section 4.2 and the repository-link passage in the introduction through the paper’s ar5iv rendering. Initial clean-text extractions omitted the relevant methods; the direct HTML response supplied them. The introduction explicitly identifies the authors’ repository. At the same pinned public commit fe05a71d3e4ed7d10bf68aa4eda6dd995ec070f4, I inspected run_gpt_prompt_insight_and_guidance, its template, generate_prompt, safe_generate_response, GPT_request, the reflection evidence converter and storage caller, and backend_server/test.py. This is selected-method and selected-code-path coverage, not a full-paper or whole-repository audit.

Prompt-to-evidence map

Paper claim or boundary	Pinned implementation	Static observation
Section 4.2 asks for insights with citations to supporting records	Insight template, lines 7–12, prompt input, lines 2142–2145	The template requests a supplied number of insights and a parenthesized citation format. The second input is str(n) despite the template’s descriptive header calling it a persona name; the executable substitution supplies the requested count. A request in prose is not a validator.
Turn generated text into evidence indices	Cleanup and validation, lines 2147–2164	Splits each line around the citation marker, extracts digit runs with a regular expression, converts them to integers, and stores them under the insight text in a dictionary. Validation only catches cleanup exceptions. It does not compare indices with candidate count or inspect semantic support. Repeated identical insight keys overwrite earlier evidence.
Retry an invalid response	Configuration and fallback, lines 2166–2181, safe_generate_response, lines 255–273	Uses the completion wrapper with text-davinci-003, a 150-token limit and five attempts. A successful parse returns immediately. Exhaustion returns a list of placeholder thoughts rather than the dictionary expected by the converter; the fallback itself is not revalidated. These are inspected settings, not an API call or a claim of current model availability.
Resolve indices to records and store a thought	Converter, lines 38–55, storage caller, lines 121–132	Candidate numbering starts at zero and lookup directly indexes that same list: this is internally consistent, not proof of an off-by-one defect. Out-of-range indices or the list-shaped retry fallback enter the converter’s exception fallback. Empty evidence produces an empty list without lookup failure. Later storage work makes further model calls, so reaching this converter is not proof that a thought was successfully persisted.

Interpretation: this narrows yesterday’s unresolved parser question. The format boundary is permissive in some ways and brittle in others. A citation segment containing no digits can produce empty evidence; a minus sign is not preserved by digit extraction; a large positive index can pass cleanup and fail later during record lookup. These are consequences of the inspected operations, not executed test cases or observed model outputs. The validator’s name should not be read as evidence-quality assurance. Even a valid in-range identifier proves only that a target can be selected, not that its content justifies the insight.

Project implication, not implementation: keep parsing, index resolution and semantic support as separate acceptance gates, and represent failure explicitly rather than turning it into ordinary memory. A future separately approved test plan should cover nonempty and empty citations, out-of-range references, repeated insight text and exhausted retries, then assess groundedness separately. A strict schema alone would still not certify that a conclusion is true.

Tests and limits: the reread test.py is a chat-call/print example; it has no insight-parser or evidence-quality assertions. The wrapper’s executable example also does not assert those properties. No new repository-wide test discovery was performed. Static code inspection; not executed. No research repository/source checkout, dependency installation, model call, notebook or test execution occurred. Ordinary read-only response caches were used. No failure frequencies, benchmark outcomes, semantic verification experiments or implemented continuity guarantees are claimed.

Next bounded step

Begin a bounded MemGPT paper/code comparison of explicit memory edits: identify an author-linked paper-era version and trace one edit operation’s validation and persistence boundary. The Generative Agents review now covers retrieval ordering, access-state restoration, evidence reconstruction and prompt parsing; further execution would require separate approval.