Add documentation for cross-run memory problem - #770
Conversation
Document the cross-run memory problem and proposed solutions for agents learning from prior outcomes. Outline the mechanisms for recording, storing, and injecting memory while maintaining sandbox constraints.
|
fullsend review is working on this — view logs |
Site previewPreview: https://b7e61e2b-site.fullsend-ai.workers.dev Commit: |
Review: #770Head SHA: 5de594f SummaryThis PR adds a new problem document ( FindingsInfo
FooterOutcome: approve Previous runReview: #770Head SHA: 7b3635d SummaryThis PR adds a well-structured problem document for cross-run memory and links it from the README. The document follows established conventions for problem docs in this repo: it opens with a framing question, explores the problem space with multiple perspectives and trade-offs (rather than prescribing a single solution), identifies security implications (memory as an attack surface for prompt injection), and closes with substantive open questions. All cross-references to other docs (architecture.md, security-threat-model.md, codebase-context.md, testing-agents.md, operational-observability.md, agent-architecture.md) were verified and resolve correctly. The README entry is placed consistently with existing entries. No code changes, no security concerns, no injection patterns detected. FindingsInfo
FooterOutcome: approve Previous run (2)Review: #770Head SHA: 16a1e54 SummaryThis PR adds a well-structured problem document exploring cross-run memory for agents, following the established pattern of other docs in FindingsMedium / Low / Info
FooterOutcome: comment-only Previous run (3)Review: #770Head SHA: 80bd95b SummaryThis PR adds a well-structured problem document for cross-run memory that follows the existing problem doc pattern and aligns with the project's design exploration approach. The document correctly identifies the problem, references existing mechanisms, proposes a harness-mediated solution that respects the ephemeral sandbox invariant, and includes open questions as required. Two minor issues were found: the README.md is not updated to link the new problem area (required by CLAUDE.md), and there is a typo in the operational observability section. FindingsMedium
Low
FooterOutcome: comment-only Previous run (4)Review: #770Head SHA: 6de7c1c SummaryThis PR adds a well-structured problem document for cross-run memory that follows the existing problem document conventions, presents multiple options with trade-offs, and includes an open questions section. The document is sound in content and correctly preserves sandbox security invariants in its proposed design. One convention gap: the repo's CLAUDE.md requires new problem documents to be linked from README.md, which this PR does not do. FindingsMedium
Info
FooterOutcome: comment-only |
|
fullsend review is working on this — view logs |
|
fullsend review is working on this — view logs |
|
fullsend review is working on this — view logs |
|
fullsend review is working on this — view logs |
![fullsend-ai-review[bot]](https://avatars.githubusercontent.com/in/3478501?s=60&v=4){kind=small}
ralphbean
left a comment
ralphbean
left a comment
There was a problem hiding this comment.
Good problem document — well-structured, stays in problem-space, and the memory-poisoning threat analysis is substantive. Two small link issues to fix before merge.
|
|
||
| ## The memory problem | ||
|
|
||
| Agents are stateless by default. Each run starts with no working knowledge of prior attempts on the same repository. The sandbox is ephemeral by design: "Created per-run, destroyed after extraction. No state carries between runs" ([architecture.md](../architecture.md#key-invariants-visible-in-this-layout)). This is a sound security and isolation decision, but it has a compounding cost: agents rediscover the same lessons on every run. |
There was a problem hiding this comment.
[moderate] The fragment #key-invariants-visible-in-this-layout targets bold inline text in architecture.md (line 485: **Key invariants visible in this layout:**), not a markdown heading. GitHub only generates anchor IDs for headings, so this link will land at the top of architecture.md instead of the intended section.
Suggestion: drop the fragment and link to ../architecture.md plain, or link to the nearest actual heading (e.g. ../architecture.md#abstract-model).
There was a problem hiding this comment.
Thanks, fixed by dropping the fragment and linking to ../architecture.md directly. The target text was not a heading, so the plain doc link is cleaner here.
| - How should future agents distinguish system-derived facts from agent-authored interpretations? | ||
| - Can non-review-gated memory be made safe enough, or should all durable memory promotion go through reviewed repo instructions or skills? | ||
| - How should memory interact with separate agent roles? Should triage memory ever influence review behavior directly? | ||
| - What retention model prevents stale memory from dominating: time-based, count-based, outcome-based, or explicit supersession? |
There was a problem hiding this comment.
[nit] Other docs in the repo hyperlink ADR references (e.g. [ADR 0023](../ADRs/0023-user-documentation-structure.md)). This one is plain text. Consider: [ADR 0022](../ADRs/0022-harness-level-output-schema-enforcement.md).
There was a problem hiding this comment.
I ended up removing the ADR-specific reference.
|
fullsend review is working on this — view logs |
|
fullsend review is working on this — view logs |
ralphbean
left a comment
ralphbean
left a comment
There was a problem hiding this comment.
Review: #770
Head SHA: 5de594f
Timestamp: 2026-05-08T20:00:00Z
Outcome: approve
Summary
Solid problem document that stays firmly in problem space, integrates well with the existing document set, and adds substantive analysis — particularly the memory-poisoning threat scenario and the three-way categorization of memory types. All internal links verified correct. Prior review feedback has been addressed. One minor cross-reference suggestion noted inline but not blocking.
Findings
Info
- [cross-reference]
docs/problems/cross-run-memory.md:72— The Constraints section mentions org-level memory scoping but doesn't link to the multi-org deployment model in architecture.md. A cross-reference would strengthen the connection but is not required.
Footer
Outcome: approve
This review applies to SHA 5de594f9774b0ff66491b2682fb3f18bc8d7fea3. Any push to the PR head clears this review and requires a new evaluation.
| - **Memory must be scoped.** Lessons from one repository should not silently leak into another repository, and lessons from one organization should not leak into another organization. | ||
| - **Memory must be attributable.** Future agents and human reviewers should be able to see where a remembered fact came from: which run, which role, which issue or PR, and whether it was system-derived or agent-authored. | ||
| - **Memory must decay.** Some lessons become wrong. A useful memory system needs a way to expire, supersede, or promote entries. | ||
|
|
There was a problem hiding this comment.
[nit] The constraint about org-level memory scoping is well stated. Consider adding a cross-reference to the multi-org deployment model section in architecture.md — it would strengthen the connection to existing architectural vocabulary. Not blocking.
|
Thanks @dhshah13 ! |
Add lychee as a pre-commit hook and standalone `make lint-md-links` target to catch broken in-repo links and anchors in markdown files. Fix all existing broken links: - Wrong anchor fragment in ADR 0002 (heading was renamed) - Missing "repo-" in ADR 0013 filename (2 references) - Dangling self-improvement-flywheel.md links → point to closed PR #43 - Dangling experiments/guardrails-eval links → point to fullsend-ai/experiments repo - Wrong relative paths for ADR 0019 from web/ and web/admin/ - Wrong relative path for ADR 0023 from skills/writing-user-docs/ - Dangling design doc link in a plan checklist Noticed the need for this in PR #770. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2 participants
Document the cross-run memory problem and proposed solutions for agents learning from prior outcomes. Outline the mechanisms for recording, storing, and injecting memory while maintaining sandbox constraints.