Scry can answer both halves of a question it can’t yet answer in one call.
It can recall that a service moved to another machine because the original host lacked dependencies and needed to stay focused on inference. It can also inspect the service repository, find its configuration, trace callers, read git intent, and map runtime endpoints.
What it can’t do is return one native graph path from the remembered decision to the exact code and deployment files changed because of it.
For now, the agent performs that join between global memory and local repository knowledge itself.
The current bridge is a repository reference
Memory entities can carry repo_refs. When recall returns a project or service, those paths tell the agent which repository graphs may contain its implementation.
The agent performs the join:
- Recall the service and decision from global memory.
- Select the relevant repository reference.
- Query git history or the local graph for the implementation.
- Open the source files that support the path.
This worked well enough for the first memory release. It also made the avoidable reconstruction obvious.
Two agents may choose different repositories or search terms for the same memory entity. A renamed service may have no obvious symbol match. A decision may affect several repositories, and the current reference only narrows the set.
A native join needs stable identities
Paths are convenient identifiers on one machine and weak identifiers across machines.
The same repository may live under different directories. Worktrees create several paths for one git history. A fork shares ancestry but shouldn’t automatically inherit every project relationship. A monorepo can contain several products represented as separate memory entities.
A cross-graph layer needs a canonical repository identity, probably based on git remotes plus a local instance identifier. It also needs mappings from memory entities to graph nodes that survive symbol movement and renames.
Commit hashes are strong join points. A memory episode can mention a delivered commit, and the git domain already connects commits to files, authors, and migrations. Pull requests and branches are weaker because they can disappear or move.
Decisions that never mention a commit need another mapping step. That may be explicit, inferred, or both.
Explicit links are the cleanest start
The first implementation doesn’t need to discover every relationship automatically.
scry_remember could accept structured links to a repository, commit, symbol, table, or endpoint. An agent recording a durable decision often knows the exact artifacts it changed because it just worked on them.
A remembered deployment decision might store:
{
"fact": "Hermes gateway moved back to the mini",
"links": [
{"type": "repo", "id": "hermes-ops"},
{"type": "commit", "id": "abc123"},
{"type": "file", "id": "config/providers.yaml"}
]
}
Those links become edges with direct provenance. Later extraction can propose additional links, but it shouldn’t overwrite the explicit ones. The agent already has these artifact IDs at the end of the task, so recording them then is cheaper than rediscovering them later.
Git can connect the middle
Git history already knows which files changed together and which commit introduced a line. It can provide much of the path between a decision episode and current code.
If an episode records a commit, Scry can traverse:
decision
-> established_in -> episode
-> delivered_as -> commit
-> changed -> file
-> defines -> function
-> queries -> table
The current repository graph doesn’t include global memory nodes, and the memory graph doesn’t duplicate code nodes. A small join index could store only cross-store edges and delegate the rest of the path to each owning graph.
That avoids copying entire code graphs into the shared memory authority. Local code can stay local.
Inferred links need an expiration story
Automatic linking sounds easy when names match. A memory entity called OrderService probably relates to the class named OrderService.
Names aren’t stable enough on their own. The service may be renamed. Two repositories may define the same class. A conversational name may refer to the product while the code uses an internal package name.
Inferred links need confidence, provenance, and invalidation just like other memory facts. They also need to notice repository reindexing. If a symbol disappears, the join should become stale rather than pointing at a node that no longer exists.
This is one reason I haven’t rushed the feature. I would rather keep the current two-step workflow than return a clean-looking path to a symbol that disappeared two reindexes ago.
The questions worth supporting
The feature should be driven by real queries. The ones I want are concrete:
- Which code implements this remembered decision?
- What incidents involved this function or service?
- Which current files still depend on a superseded architecture?
- What earlier agent runs changed this table?
- Who has worked on the subsystem, and in which sessions?
- Did a later commit undo the fix described in this episode?
These questions cross time, repositories, and evidence domains. They are difficult to answer with transcript search because the session only knows what was visible then. They are difficult to answer with a code graph because the intent may never have entered the repository.
Today I can answer each side separately. These are the queries that require joining them.
What I don’t want to build
I don’t want one cloud graph containing every source file, prompt, HTTP body, and personal conversation. I don’t want an extraction model generating links with no source. I don’t want a chat interface that hides whether an answer came from code or a remembered sentence.
The existing Scry boundaries should remain:
- Deterministic project data stays in per-repository stores.
- Global memory stores entities, time, decisions, and episode provenance.
- Cross-store edges identify joins without taking ownership of either side.
- The agent can inspect the path and open its sources.
That is enough architecture to test the first joins. I would start with repository and commit links, use them for a few months, then decide whether symbol-level linking earns its maintenance cost. None of that exists as a native path query yet; the agent still performs the two-step lookup described at the top.
Read the series from the beginning: I Built a Knowledge Graph for Everything I Work On.