How it works
A temporal knowledge graph stores facts as relationships that have a time shape. Instead of recording only that a domain uses a vendor, a user holds a role, or a policy allows an action, the graph records when that statement was observed, when it became valid, and when it stopped being valid if that is known.
In harness engineering, the useful unit is usually a claim edge with provenance: subject, predicate, object, source, timestamp, confidence or status, and validity interval. Some systems separate event time from ingestion time. That distinction matters. A fact may have been true in March, discovered in April, and superseded in June.
The control loop is simple:
- Ingest observations as dated assertions rather than overwriting the previous value.
- Link assertions to sources, runs, users, tools, or ledgers that produced them.
- Resolve a time-bounded view when the agent asks a question or prepares an action.
- Mark superseded, contradicted, expired, or unverified facts without deleting the record.
- Expose enough provenance for a reviewer, verifier, or recovery path to inspect why the harness believed something.
The graph is not magic memory. It is a state model that preserves change. The important engineering move is refusing to collapse historical truth, current truth, and inferred truth into one undated blob.
Why it matters in an agent harness
Agents act inside moving systems. Permissions change. APIs deprecate. Customers update requirements. A workflow that was safe yesterday may be unsafe today because the authority behind it changed. If the harness retrieves stale context without knowing it is stale, the model receives a polished lie.
A temporal knowledge graph gives the harness a way to ask sharper questions: Was this fact true at the time of the original decision? Is it still true now? Did another run observe a contradictory state? Which source established the current authority? Those questions are control questions, not trivia.
The first outcome is reversibility. If an agent makes a bad change, the operator needs to know which facts shaped the trajectory. A temporal graph can connect an action to the state view used at that moment. That makes rollback and compensating action less speculative.
The second outcome is permission discipline. Authorization is rarely a timeless fact. A credential may be valid for a narrow task, a repository may be writable only during a maintenance window, and a human approval may apply only to one proposal hash. Encoding those facts temporally helps prevent old permission evidence from being reused as current authority.
The third outcome is evaluation. When a regression eval fails, we need to separate model behavior from context failure. If the agent answered from an outdated source, the harness should show that the retrieval layer supplied stale evidence. Without temporal metadata, the failure is easier to misattribute to the model.
The fourth outcome is observability. A normal trace shows what happened. A temporal graph helps explain what the system believed when it happened. That difference is small in demos and large in production.
Temporal knowledge graph vs vector memory
The distinction changes design decisions because vector memory optimizes for recall by similarity, while a temporal knowledge graph optimizes for dated, inspectable state.
| Concept | Primary shape | Good at | Weak at |
|---|---|---|---|
| Temporal knowledge graph | Entities, relationships, assertions, and time intervals | Tracking changing facts, provenance, contradictions, authority, and state transitions | Fuzzy retrieval over vague language unless paired with search or embeddings |
| Vector memory | Embedded chunks retrieved by semantic similarity | Finding related notes, examples, prior cases, and loosely phrased context | Knowing whether a retrieved statement is current, superseded, scoped, or authoritative |
The two can work together. I would use vector retrieval to find candidate evidence and a temporal graph to decide whether that evidence is allowed to influence the run. Similarity should not be treated as authority. A chunk that sounds relevant may be old, contradicted, or outside the current permission scope.
For agentic RAG, this boundary is especially important. The retrieval system may surface passages from historical tickets, old documentation, and previous run logs. The harness then needs a resolver that asks: current as of when, valid for which operation, supported by which source, and superseded by what. That resolver is where a temporal graph earns its keep.
The Rifty take
We optimize for recoverable belief, not maximal memory. A harness should be able to explain which time-bounded facts it used before it lets an agent act on them.
The tradeoff is additional modeling cost. We accept that cost around permissions, customer state, workflow state, evaluation evidence, and operational decisions. We do not need every note in the system to become a formal graph edge, but facts that authorize action should not be timeless.
Implementation checks
- Separate observed time from valid time. If only one is known, record which one it is.
- Store supersession instead of overwriting important facts. Deletion destroys recovery evidence.
- Attach provenance to claim edges: source, run, tool, user, or ledger reference.
- Require temporal resolution for action-critical context, especially permissions and workflow state.
- Treat undated facts as lower authority, not as permanently true defaults.
- Make contradiction visible. Two conflicting assertions should produce an inspectable state, not a silent winner.
- Keep graph scope bounded. Model the facts that govern action, recovery, evaluation, and authority first.
- Test stale retrieval directly. Seed an old valid fact and a newer contradictory fact, then verify the harness chooses the right view.
Frequently asked questions
When does an agent harness need a temporal knowledge graph?
An agent harness needs a temporal knowledge graph when important facts change and those changes affect action. Permissions, workflow state, customer requirements, source authority, and operational decisions are common triggers. If stale context could cause a bad write, bad approval, or misleading evaluation, time needs to be modeled.
Is a temporal knowledge graph the same as an audit trail?
No. An audit trail records events that happened, while a temporal knowledge graph models time-bounded facts the system may reason over. They should connect. The audit trail can prove an observation occurred, and the graph can expose which version of a fact was considered valid during a run.
Should every memory become a temporal graph fact?
No. The useful boundary is action relevance. Casual notes, examples, and loose background can remain in ordinary retrieval or documents. Facts that authorize tools, shape workflow state, settle evaluation evidence, or influence irreversible actions deserve temporal structure and provenance because mistakes there are harder to unwind.
How does this reduce stale retrieval?
It reduces stale retrieval by making time part of the query and resolution step. The harness can filter for facts valid now, facts valid at a prior checkpoint, or facts observed before an action. Old evidence can still be inspected without being silently treated as current truth.
What is the main implementation risk?
The main risk is building a graph-shaped database that still behaves like undated memory. If callers can ignore validity intervals, provenance, or supersession, the harness has only added complexity. The resolver must enforce temporal rules at the point where context is assembled for the agent.