One of the first things Scry remembered about my agent setup became false a few weeks later.
The service had moved from one machine to another. A normal notes file would leave me with two options: overwrite the old sentence and lose the history, or keep both sentences and hope the next agent works out which one is current.
Overwriting loses the history. Keeping both without dates leaves the next agent to guess. Scry stores facts with time instead.
Current truth isn’t the only useful truth
Most recall questions want current state:
- Where does this service run?
- Which repository owns this project?
- What model does this job use?
- Is this migration still blocked?
Sometimes the question is about an older state:
- Where did the service run when the outage happened?
- Which branch contained the feature before the repositories split?
- What did we believe the deployment process was when this script was written?
If memory only preserves the latest fact, incident analysis quietly rewrites history. A command that was correct in June may look irrational against the September architecture.
Each Scry fact has a valid_from timestamp and an optional invalid_at timestamp. Current recall ignores invalidated edges. An as_of query filters the graph to facts that were valid at the requested time.
The old fact isn’t necessarily a mistake. It may have been correct for months, and it may explain why an old script points at the wrong host today.
Invalidate facts instead of deleting them
Scry invalidates a fact in three cases.
The extractor can say a new fact explicitly supersedes an earlier one. This works when a session contains a clear correction such as “we no longer deploy through the old host.”
Some relations are exclusive. A service has one current deployed_on target in the common case. A new target invalidates the existing edge for the same subject and relation.
Everything else can coexist. A project may use several tools, touch several repositories, and depend on several services. Adding one doesn’t cancel the others.
Manual invalidation exists because an extraction model can still get it wrong. The graph isn’t above correction.
Time needs provenance
The timestamp alone isn’t enough. Scry also records the episodes supporting each fact.
Suppose recall says a local inference service moved back to a Mac mini on August 24. The edge points at the session that discussed the migration, including the reason: cron scripts depended on tools available on the mini, while the inference machine was better kept focused on model serving.
Later, a separate episode may record another topology change. Both facts survive with their own time ranges and sources.
An agent answering a routine setup question can use the current edge. An agent debugging a historical failure can open the older episode and see the actual context instead of a compressed retelling of it.
Temporal memory catches contradictions
Flat project memory tends to accumulate contradictions silently. One paragraph says a job runs every hour. Another says every fifteen minutes. Both may have been correct at different points, or one may simply be wrong.
A temporal graph gives the resolver something concrete to do. If schedule is configured as an exclusive relation, the newer fact can invalidate the older one. If the facts should coexist, they remain separate and the ambiguity is visible.
This doesn’t eliminate extraction mistakes. It does make the conflict visible and gives me two source episodes to inspect instead of two loose paragraphs.
I have found the time model most useful around machines and deployments. Those are the facts agents confidently repeat after the environment has changed. They are also the facts most likely to break something when stale.
Remembering decisions is harder
Decisions don’t always have clean replacement semantics.
“Use Go for local agent infrastructure” may remain valid across many projects. “Fork this repository rather than sending changes upstream” applies to one codebase. “Keep deployment manual” may be a temporary constraint pending credentials.
Scry represents decisions as entities and connects them to projects, tools, and episodes. A status or replacement edge can change over time without deleting the decision itself.
That lets recall answer two different questions:
- What is the current decision?
- What alternatives were considered before it?
The second answer usually lives in the episode, not the compact edge. I don’t want an extractor turning a messy design discussion into a fake formal rationale. The graph should find the conversation, then get out of the way.
Time also helps forgetting
Not every remembered fact deserves permanent attention.
Scry’s orientation query favors recently active projects and current facts. Old invalidated state remains queryable without appearing in every new session. This is a useful kind of forgetting: the evidence stays, but it stops competing for the agent’s immediate context.
That balance matters once a graph contains thousands of episodes and tens of thousands of facts. Dumping all of it into a prompt would recreate the transcript problem at a larger scale, so orientation only includes a small current slice.
The awkward parts
Time in conversation is messy. A user can say “we moved that last week,” and the extractor has to choose between the session timestamp and an inferred earlier date. Two sessions can describe the same change differently. A later session can refer to an old state without reinstating it.
Scry falls back to the episode timestamp when it can’t establish a better one. Confidence and provenance stay attached. Manual corrections remain available.
I wouldn’t use this graph as a billing ledger or source of legal truth. It is operational memory for agents. Its job is to find the likely current state and the sessions that explain it.
For this job, the rough time model has been more useful than a tidy notes file. At least the agent can tell that the host changed and open the August 24 episode before it touches the deployment.