Selecting Earlier Task Records for Coding Agents

In brief

An earlier task may contain information a later coding agent needs. But remembering every task can bury that information in unrelated history. I studied two decisions: should an earlier record be kept before the later task is known? And should a particular later agent see it?

We tried this on ten real coding tasks. The system often filtered out an earlier issue that was related to the new task, so the coding agent never saw it. Giving agents past issue summaries did not lead to more completed fixes in these runs. But that does not mean memory is useless: these summaries were not proven solutions, and this small experiment cannot tell us what better memories would do.

1. The Problem

Imagine two coding agents working on the same software project months apart. Agent A investigates an unexpected database behavior. Agent B encounters another issue involving the same part of the codebase. Agent B starts fresh: it can read the repository, but it does not automatically know what Agent A encountered.

A memory system might preserve some history for Agent B. That raises two different questions. At the end of Agent A's work, what deserves to be retained? Later, when Agent B's task is known, what part of that retained history should enter its prompt? The first decision cannot legitimately depend on future tasks; the second can.

The aim here was not to invent a memory database. It was to put these decisions in a setting where the downstream outcome could be checked by running software tests.

2. A Simple Example

The running example is from Django, the Python web framework. Its ORM lets a program fetch database objects without writing raw SQL. Two methods are relevant: select_related() follows relationships and fetches related objects in the same query; only() restricts which fields are loaded initially.

In the later task (django__django-35356), a model refers to another instance of itself using a one-to-one relationship. The issue report gives this query, here abbreviated to its relevant lines:

class Example(models.Model):
    name = models.CharField(max_length=32)
    source = models.OneToOneField(
        "self", related_name="destination",
        on_delete=models.CASCADE
    )

Example.objects.select_related(
    "source", "destination"
).only(
    "name", "source__name", "destination__name"
)

What goes wrong? Instead of returning the requested data, Django reports a FieldError: Example.source cannot be both deferred (not loaded immediately) and traversed using select_related(). According to the issue, fetching either relationship separately works; combining them triggers the problem.

Now look backward. About ten months earlier, task django__django-16910 described a different problem involving only(), select_related(), and a reverse one-to-one relationship: Django fetched more fields than expected. Its reference change touched django/db/models/sql/query.py.

These are related ORM problems, not identical bugs. The earlier record names a plausible area to investigate, but it does not tell Agent B how to fix the later error.

Would showing the earlier record help a coding agent? That is the question the experiment can test; the fact that the benchmark labels the pair related is not itself proof of usefulness.

3. The Dataset

I used SWE-ContextBench Lite, a benchmark of software issues with earlier experience tasks, later target tasks, and known relations between some pairs. The release contains 300 earlier experience tasks and 99 related targets.

A simple setup would give the agent the one earlier record already annotated as related to its target. But that gives away much of the retrieval problem. Instead, this study assembled a history of every strictly earlier task in the same repository. The published relation was kept out of the selectors' inputs and used only for offline analysis.

Each of the eleven clean targets had 13–114 earlier candidates. One Matplotlib target was excluded from primary analysis because the evaluator's no-change control already satisfied its failing test. The remaining ten tasks span Django, SymPy, and scikit-learn, with eight distinct resolving pull requests underlying the ten target IDs.

The eleven histories contained 603 target–record entries, deduplicating to 211 distinct source records. The primary ten histories used 188 distinct sources; source-time decisions were frozen across the 211-record universe. Issue creation timestamps established ordering, although they do not prove when the corresponding repairs became available.

4. What Counts as a Memory?

The word memory needs care here. The completed pilot did not store insights extracted from a successful earlier coding agent's actions. It stored a short excerpt of an earlier issue together with file paths from its reference change. The source agent's outcome was unknown.

This is the actual record associated with our earlier Django task, rendered more readably but retaining its stored text:

The stored claim was prefixed with “Earlier task experience concerned” and suffixed with the reference-change path. It also warned the worker to inspect current code and tests rather than treat the record as an instruction. It did not contain the earlier fix as an executable recipe or evidence that an agent learned from that task.

5. The Experiment

A custom selector made a single SHARE or DO_NOT_SHARE decision for each source record before receiving any later target. For a new task, the system chose the three most recent history slots. Only retained records in those slots could reach the worker; filtered-out slots were not backfilled by older memories. A second selector could then choose EXPOSE or WITHHOLD for that specific target.

Six conditions were completed, using the same ten targets. They represent different ways to control which history reaches the agent:

The custom decisions used the Jev System-One API (jev-1.13.0) with binary prompts. They did not implement the published Jev-Mem architecture. The coding worker was GPT-6 Luna with the SWE-Edit scaffold and xhigh reasoning; its changes were graded with the canonical SWE-ContextBench tests through an Apptainer adapter. The full B–E core produced forty graded runs, ten per condition.

Jev does not write the fix. It makes two small choices about whether the earlier Django record can reach the coding agent:

The coding agent is different: it can edit and test code. The arrows below show how it receives instructions, uses tools, gets feedback, and produces a patch that is graded afterward.

6. What Happened?

First, consider what happened to the earlier records that the benchmark had annotated as related to their later tasks.

Across all source records, the selector admitted 123/211. On the ten primary tasks, fifteen admitted records entered read decisions, and only one was exposed. Six target-level source rejections in the related-record trace came from just two distinct SymPy source decisions reused across several targets—not six independent decisions.

How often did Jev keep or show a related record?

There is no verified answer key for which memories would actually help a repair. But the benchmark tells us which earlier issue it marked as related to each later issue. We can compare Jev's choices against those annotations.

These are annotation-based confusion matrices, not correctness scores. “Not marked related” means the benchmark did not label that source–target pair as related; it does not prove the record was useless. A related record is not necessarily a helpful repair instruction either. So the 13 kept-but-unannotated records cannot be called false acceptances, nor the nine dropped records correct rejections. There is no defensible true-positive/false-positive accuracy, precision, or specificity for actual memory usefulness.

Did the memory conditions solve more tasks?

No memory condition improved full-task resolution in these recorded runs. Partial test progress was more mixed:

* The No-Memory 2/10 includes one success obtained only after a separate sanitized regrade of its saved patch. The original patch on sympy-21203 did not apply. F is a relation-based diagnostic, not a genuine upper bound. F2P/P2P totals count tests grouped inside tasks, not independent experimental trials.

D fixed more designated failing tests overall (13/48), but still solved just one task. The 120 passing-test regressions in B–F were concentrated on sympy-21309. That contrast cannot automatically be attributed to memory because worker runs differed even when their prompts were identical.

7. Why Did It Happen?

There is no single established explanation for these outcomes. The evidence does, however, show where information was removed and why attributing the final scores to the selector would be premature.

The earlier record was thin

Our Django record said that a previous issue involved only(), select_related(), and django/db/models/sql/query.py. That might point a human or agent toward relevant code. But it did not include a verified repair strategy, a successful agent trajectory, or proof that applying the earlier fix would solve the later FieldError. The same limitation applies to most of the stored history.

One early decision affected several later tasks

Six of the eight retrieved related-record cases were dropped before read filtering; those six target-level losses came from only two shared SymPy source decisions. The selector's saved rationales were empty. We can observe the exclusions, but cannot truthfully explain each rejection as an identified reasoning failure, nor assume it was incorrect.

The read filter almost eliminated memory exposure

E showed zero historical records on nine tasks. That makes E a poor test of whether using memory helps: its sole resolved task was among the nine receiving none. The Django case was the exception—its source record was shown—but exposure did not produce a resolved repair.

The worker and comparison were not stable enough for causal claims

On nine E targets, the archived worker prompts were byte-identical to No Memory, yet independently executed workers sometimes produced different patches or grades, notably on sympy-21203 and sympy-21309. The A/F runs also used a distinct regrading path. Meanwhile the memory conditions exposed unequal amounts of context: B/C/D/E used 30/20/15/1 records across the ten targets. Random admission matched the selector's global retained count, not per-target exposure.

8. What We Learned

The strongest finding is about the measurement problem. A study of memory admission needs to establish that useful information exists in the records being admitted. Otherwise dropping an annotated “related” issue is not necessarily a mistake. A study of memory exposure also needs evidence that the worker actually saw and could use that information.

The Django case makes the distinction concrete. A related record made it through every filter, and the later repair still failed. This says what happened to one historical issue summary; it does not refute the value of a detailed, validated memory. Conversely, when a record was dropped earlier, we could not know whether its absence caused a downstream failure.

So the correct conclusion is limited: in this exploratory pilot, the tested historical-record selection policies did not demonstrate improved task resolution. The selection trace is real, and the experimental confounds are real. There is no established causal benefit—or universal harm—from memory governance here.

9. What I'd Test Next

The next experiment should make the Django-style transfer question answerable before comparing elaborate policies:

1. Record a successful earlier agent. Save the actual inspected files, attempted fixes, tests, outcome, and a narrow lesson—not only issue prose and reference paths.
2. Prove the lesson can help. For the later ORM issue, compare repeated runs with no memory against runs given the verified earlier lesson directly. If it does not improve the worker, a retention policy cannot recover that benefit.
3. Then test admission. Put the useful record among many plausible earlier Django records, freeze a source-only keep/drop decision, and check whether that information remains available.
4. Isolate exposure and match budgets. Add the missing Share-All + Read condition and compare against equally sized random and relevance-selected context on each target.
5. Repeat with one grading pipeline. Use the same patch collection and evaluator for all arms, multiple worker runs, and distinct underlying pull requests before drawing a causal conclusion.

10. Related Work / Where This Fits

Explore the FrontierMemory research lineage → Updated October 25, 2026: an interactive, source-audited map of FrontierMemory 1.0, the public benchmark families it adapts, its historical-trajectory inputs, the recall evaluations it contrasts, and the earlier Letta research program. Solid connections indicate directly named or linked sources; dashed ones are thematic background, not claimed citations. The page also maps 20 potential 2027 publication tracks (from our GitHub venue list and MSR Data & Tool Showcase), with deadlines and explicit caveats. The original broader 33-paper citation graph remains archived here.

This project sits between prior coding-context benchmarks and memory-management methods. The surrounding literature already establishes that agent memory and governance are active research areas; the novelty here is not the existence of a “keep” button.

The most defensible contribution is a transparent, executable pilot that traces when benchmark-related context disappears between source-only admission and later exposure—and shows why stronger controls are needed before judging the benefit of memory selection.

References & Reproducibility

The complete experiment, protocol amendments, frozen pool definitions, implementation, recorded treatment outcomes, reviewer critiques, and paper revisions are available in the experiment repository, primarily on handoff/aamas-2027-evidence.

• Actual Django source–target candidate pool
• Final exploratory manuscript draft (Round 3)
• Claim-to-evidence ledger
• Independent scientific critique
• Experiment evidence handoff, including v15 archive