Temporal Knowledge Graphs for Agentic Retrieval

An agent can have access to every approved enterprise tool and still search poorly. A database catalog can expose tables. A document system can return files. A business application can provide records through an API. What those systems rarely provide together is a coherent account of what an object means, how it relates to other objects, whether it was valid at the time in question, and which source remains authoritative.

This paper documents an ongoing investigation into that missing layer. The working hypothesis is that an agent searches better when it starts from a temporal knowledge graph of contextual metadata than when it starts with an undirected search across source systems. The graph does not replace the database, the document store, or the business application. It tells the agent where to look, what to retrieve, and how to read what comes back.

When access is not enough

Enterprise search is usually framed as a relevance problem: given a request, rank the most similar documents or records. Agentic retrieval adds a decision problem. Before an agent can rank content, it must choose a system, a tool, a data asset, a version, and a path through several related objects.

Consider a request for “the current customer retention definition.” The answer might depend on a policy document in Workspace, a metric definition in a catalog, a table in a warehouse, and a change approved in an enterprise system. Lexical or vector similarity can surface all four. It cannot say which document superseded another, which table implements the definition, or when that definition became valid. The failures follow: a deprecated document outranks the current one because it uses the query’s exact words; a current schema is applied to a historical question; the agent fans out across systems because it cannot guess the source; and a plausible answer cannot be traced to the object and version that supported it.

The research question is therefore narrow: under the same model, source permissions, task set, and tool budget, does a contextual and temporal knowledge layer improve the agent’s ability to identify the correct source objects?

Better retrieval is not merely finding text that resembles the question. It is finding the right object, from the right system, for the right point in time.

A temporal map of distributed knowledge

A temporal knowledge graph, or TKG, combines the entities an agent may need, the relationships that give those entities meaning, and the periods during which each assertion is valid. It replaces one unconstrained content search with a sequence of explicit decisions: identify the concept, follow its relationships, select the version valid for the requested time, and route the agent to the authoritative source.

The graph is a map, not a warehouse

Nodes describe database tables, fields, documents, metrics, policies, teams, workflows, applications, and business entities. Edges express relationships such as owned by, derived from, joins with, governed by, supersedes, or implemented in.

The graph shape matters less than the context attached to each node and relationship.

The layer stores that metadata and the relationships between concepts. The underlying rows, documents, and records stay where they are already managed. A concept carries a stable pointer to its source object, not a replica of the object’s payload.

This separation creates two retrieval stages. Discovery is cheap and broad: the agent searches metadata, follows relationships, applies time constraints, and builds a short list of candidates. Execution is narrow and authoritative: the source connector fetches the selected object under the caller’s existing permissions. A source URI is not an access grant, and the graph must not become a way around the access controls of the system it describes. Metadata is itself sensitive, since a title, an owner, or a relationship can reveal what a reader is not cleared to see, so the layer needs access-aware indexing of its own. The source still makes the final authorization decision at fetch time.

Make time part of the fact

A conventional knowledge graph describes the latest known state. A policy can be current today but wrong for a transaction from last quarter. A table can keep the same name while its grain changes. A document can remain searchable after it has been superseded. The temporal model used here separates three clocks:

1. Valid time records when an assertion was true in the domain. A metric definition might be valid from July through December even if it was written earlier.
2. Observation time records when the knowledge layer learned the assertion. It makes ingestion lag, replay, and audit visible.
3. Source modification time records when the originating object changed. It signals that the contextual representation may need regeneration.

Lifecycle state (draft, stable, deprecated) and a stale_after date sit alongside those clocks, so a retrieval policy can distinguish “true as of the requested date” from “recently observed” and “still safe to use.”

Changes are kept as versioned assertions rather than overwrites of one timeless node. A supersedes relationship connects definitions across versions, and validity intervals decide which one is eligible for an “as of” query, without the graph holding historical source payloads.

Comparing context before content

The evaluation holds the agent constant and changes only the presence of the knowledge layer. Both conditions share the same model version, system prompt, source snapshot, permissions, latency budget, and maximum tool calls.

Baseline: direct tool search. The agent receives the task and its approved source tools, chooses among them, and fetches content directly from databases, Workspace, or other enterprise systems.

Treatment: knowledge-assisted search. The agent receives the same task and tools plus a knowledge-layer search operation. It uses contextual and temporal metadata to select candidate resources, then fetches them through the same source tools as the baseline.

Source selection is only the first decision. A single Workspace search can return two documents with nearly identical titles and overlapping content, and the newer modification timestamp does not identify the correct policy: one file may have been edited later for archival reasons while the other carries the validity interval approved for the requested date. The temporal layer uses valid_from, valid_to, lifecycle state, and supersedes to select the latest applicable version rather than the latest edited file.

The test set should include several retrieval shapes:

Search quality is measured at the source-object level, not by whether an answer sounds correct: precision and recall of the top-ranked objects, correct-version rate, task completion, unsupported answer rate, source traceability, tool calls, and time to the first relevant object. Latency matters because an extra knowledge hop is only worthwhile if it reduces waste later in the retrieval path.

An ablation separates context without relationships, relationships without time, time without provenance, and the full layer, so the evaluation does not credit the graph for gains a smaller metadata index might have delivered. The expectation, recorded before the benchmark runs, is that temporal eligibility produces the largest correctness gains on time-scoped tasks while depending on the metadata that is costliest to maintain. If both hold, the ablation is a cost argument as much as a quality argument.

From research model to a reference architecture

What follows is one Google Cloud reference architecture for the layer, not a requirement of the model. Each component can be swapped because the portable knowledge contract stays separate from the source systems, the graph runtime, the search index, and the agent framework.

Read top to bottom to follow how source changes become portable knowledge, and across the bottom lane to follow a request: context first, then an authorized fetch from the originating system. That final step is what keeps a catalog or graph from appearing to serve enterprise content.

Use OKF as the interchange contract

The Open Knowledge Format (OKF) is Google Cloud’s vendor-neutral representation for the metadata, context, and curated knowledge that agents need. A bundle is a hierarchy of Markdown concept documents with YAML frontmatter. People can review it, agents can read it directly, and version control shows how it changed. OKF is a format, not a platform: it prescribes no graph database, vector store, retrieval algorithm, or source connector. Standard Markdown links make a bundle graph-shaped, and consumers decide whether to materialize those links into a graph index, a search engine, or a hybrid retrieval service.

The OKF v0.2 specification adds optional vocabulary for provenance, verification, lifecycle, freshness, and attested computation, and permits producer-defined frontmatter, which lets this research add explicit temporal fields without claiming they belong to the core standard. A simplified concept:

---
type: Workspace Document
title: Customer retention policy
description: Approved definition and operating policy for customer retention.
resource: https://docs.google.com/document/d/example
tags: [customer, retention, policy]
generated:
  by: process:workspace-catalog
  at: 2026-08-10T18:30:00Z
status: stable
stale_after: 2026-09-10
sources:
  - id: workspace-object
    resource: https://docs.google.com/document/d/example
    last_modified: 2026-08-09
temporal:
  valid_from: 2026-07-01T00:00:00Z
  valid_to: null
  observed_at: 2026-08-10T18:25:00Z
relationships:
  supersedes: /policies/customer-retention-2025.md
  implemented_by: /data-assets/customer-retention-metric.md
---

The resource identifies the authoritative object. Standard OKF fields carry provenance and lifecycle. The temporal and relationships blocks are extensions owned by this research model. The Markdown body can hold business definitions, schemas, examples, and join guidance without forcing that prose into a graph schema.

The v0.2 trust additions matter most when agents also maintain the layer: they separate when a concept was generated from when it was verified, record its sources, and make staleness queryable before the full body is read. None of that makes a concept correct. It gives the retrieval system evidence for deciding whether the concept is eligible.

Observe change at the source boundary

Each source needs a small producer that emits knowledge about its objects without turning the layer into a replica of them.

For Workspace, the Google Workspace Events API notifies a producer when a Drive file is created, edited, renamed, moved, or gains a revision, and the Drive API change and revision model supplies the stable file identity, metadata, permissions context, and revision signals. An event establishes that something changed, not when the business assertion became valid. Google’s documentation notes that editor revisions can be merged, so the revision list may not reflect every change, and that revisions not marked for permanent retention can be purged. The TKG therefore records its own observed_at and takes valid_from, valid_to, approval, and supersession from explicit policy metadata or a human review workflow. Drive’s modification time remains a freshness signal, not domain validity.

For BigQuery, read-only INFORMATION_SCHEMA views expose metadata about datasets, tables, columns, constraints, views, jobs, indexes, and, in preview, property graphs, which a producer can turn into OKF concepts and relationships without extracting rows. Producers for other enterprise systems follow the same contract: observe a change, resolve a stable resource identity, emit contextual metadata, and retain a pointer to the source.

Materialize graph and search projections

The OKF bundle stays the portable, reviewable representation. Runtime systems build projections from it, and the two Google Cloud paths need not both be used. Knowledge Catalog is the managed path for governed discovery, and it also harvests technical metadata from Google Cloud data systems; Google Cloud’s OKF launch material states that it can ingest OKF and serve its context to agents. Spanner Graph is an optional layer for explicit cross-system traversal, queried through an ISO GQL-compatible interface. A TKG projection models Concept, ConceptVersion, and SourceObject nodes joined by DESCRIBES, SUPERSEDES, DERIVED_FROM, and IMPLEMENTED_BY edges. Spanner Graph does not supply temporal meaning; valid_from, valid_to, and observed_at remain application-defined properties enforced by retrieval predicates.

Gemini Enterprise Agent Platform text embeddings supply semantic candidates when a request and a concept use different language. That stage should maximize recall, not make the final decision. The graph then expands relevant relationships, while validity, lifecycle, trust, and access rules remove ineligible candidates. In compact form: semantic similarity proposes; temporal and governed context decides.

Expose a context-first agent tool

The agent should not need to know how bundles, catalog entries, embeddings, and graph tables are assembled. Give it one narrow tool with an explicit contract:

find_context(query, as_of, source_types)
  → concept_id
  → authoritative_resource
  → valid_interval and lifecycle
  → provenance and verification
  → relationship_path
  → recommended_source_tool

An agent built with Google’s Agent Development Kit and deployed to Agent Runtime in Gemini Enterprise Agent Platform calls find_context before broad source search when the request is ambiguous, cross-system, or time-scoped, then invokes Drive, BigQuery, or another approved source tool with the returned resource identity. The source system performs the final authorization and returns current content. The context tool never grants access and never substitutes cached source data.

Operate it as a living layer

Source-specific producers observe schemas, document metadata, application objects, and approved reference material; they create or update OKF concepts, preserve temporal assertions, and record provenance. Validation checks format and links, and a consumer materializes the indexes. No single update schedule fits every source: a database schema, a policy document, and a fast-changing operational record have different freshness requirements, so stale_after should reflect each concept’s expected volatility while source events or periodic reconciliation trigger regeneration.

What the current work suggests

The observations so far come from evaluations I have run against enterprise data. They are observations, not benchmark results: I have not attached a percentage improvement because the evaluation set, relevance judgments, and ablation runs still need to be formalized. The patterns are consistent enough to shape the next phase.

• Contextual metadata improves routing. When the same business concept lives in a database, a policy document, and an operational application, the agent can name the likely system before it fans out across broad searches.
• Relationships improve disambiguation. Ownership, lineage, implementation, and supersession edges separate objects that share language but play different roles, which text similarity cannot reliably infer at query time.
• Temporal qualifiers improve version selection. They turn “current,” “at the time,” and “as of” into explicit retrieval constraints instead of words the agent must interpret against an undifferentiated result set.
• The gain is smaller for exact identifier lookup. When a request already carries a stable table name, record ID, or document URL, a direct tool call is usually the shortest path. A knowledge layer inserted by habit adds a hop without adding a decision.
• The layer can make a poor result more confidently wrong. Context that is stale, over-broad, or detached from source permissions hands the agent a citation for the wrong object. Search quality depends as much on maintenance and eligibility rules as on graph construction.

Next research phase

The next step is a reproducible benchmark: a fixed multi-system corpus, independently judged queries, explicit time-scoped tasks, and relevance labels at the source-object level, with every run recording the candidate list, selected source, version, tool sequence, latency, and citations. Three questions matter most:

1. Does the full temporal and contextual layer improve top-ranked source precision over direct tool search?
2. Which contribution accounts for the improvement: semantic context, graph relationships, or temporal eligibility?
3. At what corpus size and task ambiguity does the extra retrieval stage repay its indexing, maintenance, and latency cost?

The benchmark also exposes a second problem: who keeps the map current? Manual edits do not scale across changing documents, schemas, permissions, and enterprise records, and a stale concept can be more dangerous than a missing one, because its resource pointer may still work after its meaning or validity has drifted. Identities, schemas, modification times, and provenance can usually be refreshed mechanically. Business definitions, ownership, validity intervals, supersession, and prior human verification need evidence or review before publication. Temporal version selection, the layer’s most distinctive capability, rests on exactly the signals that resist mechanical refresh, so the feature that separates this layer from a plain metadata index is also the costliest to keep true. The next paper, Keeping Knowledge Alive, takes up that problem with a bounded producer fleet and a hybrid loop of source events, scheduled reconciliation, idempotent regeneration, and confidence-aware review.

The architecture succeeds if it gives agents a better map while leaving enterprise data where its ownership, permissions, and operational controls already live. This is not an argument for moving everything into a graph. It is an argument for making the knowledge about distributed data portable, temporal, and usable before an agent commits to a source call. That is the claim to test: better context should produce better search decisions, and better search decisions should let agents reach the right authoritative data with fewer wrong turns.