Skip to content

Build1 publisher3 min readPublished

Graft gates coding-agent recall behind a STRONG, WEAK or MISS verdict

An Apache-2.0 memory layer for coding agents returns a candidate only when several signals agree, and it labels every answer STRONG, WEAK or MISS so the calling agent has to branch on confidence before reusing an old fix.

The Engineer · Build desk

Illustration accompanying Graft gates coding-agent recall behind a STRONG, WEAK or MISS verdict

What happened

  • A dev.to post on coding-agent memory argues that the expensive part is not finding a nearby document chunk but deciding whether a past conclusion is safe enough to reuse in the current session.
  • It lists how the top vector hit misleads: the match may apply to a different framework version, describe an abandoned approach, hold only under an unstated deployment constraint, or have been superseded.
  • A third operation, graph exploration, walks what else connects to a failure, such as a prior ingress decision or a known local-development exception, and keeps the relationship visible instead of scoring it.
  • The author says he is building the design into Graft, an Apache-2.0 local memory layer for coding agents whose core is a C11 daemon backed by SQLite, FTS5, sqlite-vec and llama.cpp.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • decision A recall call that returns a confidence label forces whoever writes the agent to implement a WEAK branch. Against a plain top-k endpoint there is nowhere to put one, so rank 1 becomes the answer by default.
  • constraint No safe default ships with this design. Each team has to pick its own false-positive rate, and the memory layer cannot make that call on their behalf.
  • exposure Superseded architectural decisions are the entries most likely to look semantically perfect. Whether the store links them forward decides whether a code-change agent gets handed a plan that was abandoned.
  • cost Adopters pay for their own evaluation set. The post supplies the failure categories to test and leaves the scoring to whoever runs it.

Verified recall gates the answer. It hands back one candidate only when multiple signals support the match, and the field the caller branches on is a label: STRONG, WEAK, or MISS [5]. Each label carries a prescribed action. A STRONG hit is evidence, and the agent is expected to read the returned context and decide whether it fits [6]. WEAK should send the agent to investigate, and MISS tells it to solve the problem normally [7]. A caller writes three paths where a top-k endpoint lets it write one [22].

Underneath, two rankings run and then get merged. Dense embeddings catch paraphrase, while BM25 keeps the exact anchors that carry disproportionate meaning in engineering work, among them a configuration key, an exception type, a table name and a package version [8]. The post proposes reciprocal-rank fusion for the merge, on the grounds that it blends independent rankings without pretending either is universally correct [9]. Ask for help with a Docker healthcheck and similarity alone may return memories about container startup or service discovery, which the post treats as leads [3].

The store has to be the right shape for any of this to work. A codebase index is built to answer which documents might match a query; agent memory has to answer what the agent learned that would be expensive to rediscover [11]. The entries the post asks for are compact and explicit: a root cause with its fix, an architectural choice with the reason behind it, a constraint that rules out an appealing approach [12].

When a decision changes, the old entry stays in the store. Deleting it loses context and leaving it untreated risks a stale answer, so the post marks the old learning superseded and links it to the newer one. History stays inspectable, and retrieval favours what is current [13].

Then there is the threshold. The costs of being wrong are asymmetric. For an agent that proposes code changes, "a plausible but stale memory can send work down the wrong path", the author wrote [15]. For an agent doing background research, a false negative is cheaper, because it can simply search more broadly [16]. The post's rule follows from that: confidence should be exposed as part of the contract [17].

The evaluation loop is built out of failures: paraphrases of the same historical problem, near misses on a different version or environment, contradictions and superseded decisions, exact-identifier queries that vectors may dilute, and small noisy stores where every result appears relevant [18]. "It is to learn when the system should stay silent," the author wrote of the goal [19]. The post lists those categories without reporting how Graft scores on any of them [23].

For the gate to be worth the wiring in someone else's stack, two things have to hold. The store needs entries with enough structure that a second signal has something to check [12], and the calling agent has to do something different on WEAK than it does on STRONG [6][7].

What to watch

  • Whether Graft publishes scores on the failure cases the post lists, especially wrong-version near misses and superseded decisions.
  • Whether STRONG, WEAK and MISS survive into the shipped API surface or collapse back into a single similarity number.
  • Whether other local memory layers adopt supersession links so an old decision stays inspectable after it is replaced.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories