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 describes that missing layer. The premise 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 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?
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.
Figure 1 · A temporal knowledge graph in miniature
Two Workspace policy documents connect through a supersedes relationship. An agent request dated August 12 selects version two because it is valid from July 1. That document defines a retention metric, which is computed from a BigQuery table and owned by Customer Operations.
Valid as of · 12 Aug
Supersedes
Defines
Computed from
Owned by
Selected / valid Superseded Typed relationship Metadata node
The graph shape matters less than the context attached to each node and relationship.
| Context family | Examples | Retrieval value |
|---|---|---|
| Identity | Stable ID, title, aliases, source URI | Resolves naming differences across systems |
| Meaning | Description, business definition, examples | Distinguishes similar-looking assets |
| Topology | Links, joins, lineage, dependencies | Supports traversal beyond lexical matches |
| Authority | Owner, provenance, verification, lifecycle | Helps prefer governed and current knowledge |
| Time | Valid interval, observation time, last modification | Selects the version appropriate to the request |
| Operation | Source type, access method, query hints | Routes the agent to the correct tool |
The layer stores this contextual metadata and concept relationships while underlying rows, documents, and records remain in their originating systems. Concepts carry stable pointers to source objects rather than replicated payloads.
This separation creates two distinct retrieval stages: broad, low-cost discovery over metadata to narrow candidate objects, followed by narrow, authoritative execution where source connectors fetch data under caller permissions. Because source pointers are not access grants, the knowledge layer requires access-aware indexing while systems of record retain final authorization.
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 separates when an assertion was valid, when the layer learned it, and when its source changed. Keeping those clocks distinct exposes ingestion lag and makes historical answers auditable.
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.”
Figure 2 · Three clocks on one policy
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.
Figure 3 · Two paths to the same source documents
Direct source search
Context-assisted search
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:
| Task shape | Example question | What the layer must contribute |
|---|---|---|
| Exact lookup | Find a known table or document by stable name | Little; direct search should already be strong |
| Semantic ambiguity | Which “customer status” definition is authoritative? | Meaning, ownership, and verification |
| Temporal selection | What definition applied on a given date? | Validity and supersession |
| Cross-system discovery | Which policy governs this warehouse metric? | Relationships across source types |
| Source routing | Where should the current value be retrieved? | Resource identity and tool hints |
| Lineage | What source and transformation produced this result? | Derivation links and provenance |
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 model to 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.
The maintenance path publishes metadata and source pointers. At request time, the agent resolves context first, then fetches through an authorized source connector. The catalog or graph does not serve the source content itself.
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 model 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 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.
| Build stage | Google surface | Responsibility |
|---|---|---|
| Observe | Workspace Events API, Drive API, BigQuery INFORMATION_SCHEMA |
Detect change and read source metadata |
| Represent | OKF v0.2 | Preserve portable concepts, links, provenance, lifecycle, and temporal extensions |
| Govern | Knowledge Catalog | Unify managed metadata and business context for discovery |
| Traverse | Spanner Graph, when needed | Resolve relationship paths and application-defined temporal predicates |
| Recall | Agent Platform text embeddings | Find semantically related concept candidates |
| Execute | ADK on Agent Runtime | Query context first, then call the authoritative source tool |
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.
| Risk | Observable signal | Response |
|---|---|---|
| Stale context | Source modified after concept generation | Exclude, refresh, or lower the concept’s rank |
| Conflicting assertions | Overlapping validity intervals | Preserve both, flag conflict, require adjudication |
| Broken source pointer | Authorized fetch returns not found | Mark lifecycle state and repair the resource identity |
| Permission leakage | Metadata appears where source access does not | Apply access-aware indexing and minimize exposed metadata |
| Over-enrichment | Retrieval spends more time reading context than searching | Keep filterable signals concise; load prose progressively |
| Unsupported relationship | Edge lacks provenance or verification | Treat it as unverified rather than authoritative |
What applying the model shows
The observations below come from evaluations I have run against enterprise data. They are observations, not benchmark results, and they carry no percentage improvement: the acceptance criteria above are what attach numbers to them. The patterns are consistent enough to direct where the layer is worth its cost.
- 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.
Use the knowledge layer to choose and explain the source—not to impersonate it.
Where the layer must earn its cost
The architecture earns adoption where temporal context repays its indexing and latency overhead. The deciding criterion is whether explicit valid-time bounds and relationship graphs produce higher source precision than direct tool search, and at what scale that advantage justifies the multi-stage pipeline.
That criterion exposes an operational bottleneck: who keeps the map current? While schemas and modification timestamps refresh mechanically, business definitions, validity intervals, and supersession links resist simple automation. A stale graph node is worse than a missing one if an agent relies on an out-of-date pointer. The next paper, Keeping Knowledge Alive, addresses this maintenance challenge through an event-driven producer fleet, idempotent regeneration, and confidence-aware verification.
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 standard the layer is held to: better context should produce better search decisions, and better search decisions should let agents reach the right authoritative data with fewer wrong turns.