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 agentic search improves when retrieval begins with a temporal knowledge graph containing contextual metadata, rather than beginning with an undirected search across source systems. The graph does not replace the database, document, or enterprise application. It helps the agent decide where to look, what to retrieve, and how to interpret the result.

The argument follows that sequence deliberately: begin with the retrieval failure, introduce the temporal knowledge graph as the proposed mechanism, test the context-first path against direct search, and only then translate the model into an engineering system. Directional observations and the next research phase follow that implementation path. The comparison holds the model, permissions, source data, and tool budget constant.

When access is not enough

Enterprise search is commonly 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 often 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 useful 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, but similarity alone does not reveal which document superseded another, which table implements the definition, or when that definition became valid.

The resulting failures are familiar:

• a deprecated document outranks the current one because it uses the query’s exact language;
• a table name looks relevant, but the agent lacks its business meaning and join relationships;
• a current schema is applied to a historical question;
• the agent searches several systems because it cannot identify the likely source in advance; or
• a plausible answer cannot be traced back 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?

Research frame

The comparison in three numbers

2 retrieval paths

Direct source search is compared with knowledge-layer-assisted search.

3 time signals

Valid time, observation time, and source modification time remain distinct.

1 authority rule

The originating system remains the source of truth and the access-control boundary.

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 three things: the entities an agent may need, the relationships that give those entities meaning, and the periods during which each assertion is valid. It resolves the retrieval problem by turning an unconstrained content search into 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

A knowledge graph represents concepts as nodes and their relationships as edges. In this setting, nodes can describe database tables, fields, documents, metrics, policies, teams, workflows, applications, and business entities. Edges can express relationships such as owned by, derived from, joins with, governed by, supersedes, or implemented in.

Figure 1 · A temporal knowledge graph in miniature

Scroll horizontally to explore →

The useful part is not the graph shape by itself. It is 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 that metadata and the relationships between concepts. The underlying rows, documents, messages, and records remain where they are already managed: databases, Workspace, and other enterprise systems. A concept carries a stable pointer to its source object, not an uncontrolled replica of the object’s full payload.

Figure 2 · Context before content

Authority Databases · Workspace · enterprise systems

→

Knowledge layer Metadata · context · time · relationships

→

Agent execution Discover · route · fetch · cite

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 candidate resources. Execution is narrow and authoritative: the relevant source connector fetches the selected object under the caller’s existing permissions.

That boundary is also a security requirement. A source URI is not an access grant, and a knowledge graph must never become a way to bypass the permissions of the system it describes. Metadata can itself be sensitive—titles, relationships, and ownership may reveal information—so the knowledge layer also needs access-aware indexing and filtering. Source authorization remains the final decision at fetch time.

Make time part of the fact

A conventional knowledge graph often describes the latest known state. That is insufficient for questions about changing organizations and systems. 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 in this research 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 or recorded the assertion. This makes ingestion lag, replay, and audit visible.
3. Source modification time records when the originating object changed. It is a signal that the contextual representation may need regeneration or verification.

Lifecycle signals sit alongside those clocks. A concept can be draft, stable, or deprecated; it can also carry a date after which it should be treated as stale. Together, these signals let a retrieval policy distinguish “true as of the requested date” from “recently observed” and “still safe to use.”

Question	Temporal signal	Failure it prevents
When was this assertion true?	valid_from / valid_to	Applying today’s meaning to historical data
When did the layer learn it?	observed_at	Hiding ingestion delay or retroactive correction
Has the source changed since enrichment?	Source last_modified	Treating stale context as synchronized
Should an agent still select it?	status, stale_after, verification time	Preferring superseded or unreviewed knowledge

Figure 3 · Three clocks on one fact

Earlier As-of query Later

Valid time

01 Jul — 31 Dec · policy applies

Observed

10 Aug · layer records

Modified

03 Sep · source changes

The implementation should preserve changes as versioned assertions rather than continually overwriting one timeless node. A supersedes relationship can connect definitions across versions; validity intervals can determine which one is eligible for an “as of” query. This allows the agent to reason about history without copying historical source payloads into the graph.

Comparing context before content

The evaluation should hold the agent constant and change only the presence of the knowledge layer.

Baseline: direct tool search. The agent receives the task and its approved source tools. It chooses tools, submits searches, inspects results, 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 those resources through the same source tools used by the baseline.

Figure 4 · The experimental contrast

A

Baseline

Direct source search

Agent ↓ Broad tool fan-out

Database Workspace · 2 matches Enterprise app

↓ Similar Workspace results

Document A Customer retention policy Modified 28 Jun

Document B Customer retention policy Modified 02 Jul

The agent finds two plausible files, but modification time alone does not establish which policy was valid.

B

Treatment

Context-assisted search

Agent ↓ Temporal knowledge layer ↓ Ranked source selection

Database Workspace · selected Enterprise app

↓ Temporal object selection

Document A · superseded Customer retention policy Valid through 30 Jun

Document B · selected Customer retention policy Valid from 01 Jul

The layer narrows both the source and the valid version; Workspace still authorizes and returns the document.

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

Both conditions should share the same model version, system prompt, source snapshot, permissions, latency budget, and maximum tool calls. 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 should be measured at the source-object level, not by whether an answer merely sounds correct. Useful measures include 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 study can identify which part produces the improvement: context without relationships, relationships without time, time without provenance, and the full layer. This prevents the evaluation from attributing every gain to the graph when a smaller metadata index might have been sufficient. 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 that holds, the ablation becomes a cost argument as much as a quality argument.

From research model to a working system

With the mechanism and evaluation criteria established, the next step is to translate the research model into an operable knowledge layer. The following is one Google-oriented reference architecture, not a requirement of the model. Its components remain replaceable because the portable knowledge contract is kept separate from source systems, graph runtime, search index, and agent framework.

Figure 5 · A Google Cloud reference architecture

Scroll horizontally to inspect the architecture →

Read the architecture from top to bottom to follow how source changes become portable knowledge. At request time, read across the bottom lane: the agent asks for context first, then uses the returned resource identity and version to call the originating system. The long dashed return path is deliberate—it makes the source boundary visible instead of implying that a catalog or graph serves the enterprise content.

Use OKF as the interchange contract

The Open Knowledge Format (OKF) provides a useful representation boundary for this layer. Google Cloud introduced it as a vendor-neutral way to represent the metadata, context, and curated knowledge that agents need. An OKF bundle is a hierarchy of Markdown concept documents with YAML frontmatter. People can review it, agents can read it directly, and ordinary version-control workflows can show how it changed.

The distinction between format and platform is important. OKF does not prescribe a graph database, vector store, retrieval algorithm, or source connector. Standard Markdown links make a bundle graph-shaped, while consumers are free to materialize those links and fields into a graph index, search engine, or hybrid retrieval service. The format is the portable contract between producers and consumers.

The current OKF v0.2 specification adds optional vocabulary for provenance, verification, lifecycle, freshness, and attested computation. It also permits producer-defined frontmatter, which allows a research implementation to add explicit temporal fields without claiming that those fields are part of the core standard.

A simplified concept can look like this:

---
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 expose the concept’s provenance and lifecycle. The temporal and relationships blocks are extensions owned by this research model. The Markdown body can add business definitions, schemas, examples, join guidance, or human-reviewed interpretation without forcing all of that prose into a graph schema.

OKF v0.2’s trust additions are especially relevant when agents also maintain the knowledge layer. The v0.2 release material distinguishes when a concept was generated from when it was verified, records the sources from which it was derived, and makes staleness queryable before a consumer reads the full body. That does not make a concept correct, but it gives the retrieval system explicit evidence with which to decide 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 knowledge layer into a replica of those objects.

For Workspace, the Google Workspace Events API can notify a producer when a Drive file is created, edited, renamed, moved, or has a new revision. The producer then uses the Drive API change and revision model to read the stable file identity, metadata, permissions context, and available revision signals. An event establishes that something changed; it does not by itself establish when the business assertion became valid.

That distinction is essential. Google 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 over time. The TKG therefore records its own observed_at event while obtaining 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 a substitute for domain validity.

For BigQuery, read-only INFORMATION_SCHEMA views expose metadata about datasets, tables, columns, constraints, views, jobs, indexes, and, in preview, property graphs. A producer can turn those records into OKF concepts and relationships without extracting the table rows. Knowledge Catalog can also harvest technical metadata from Google Cloud data systems and add governed business context. 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 should remain the portable, reviewable representation. Runtime systems consume that bundle and build projections optimized for their jobs. There are two useful Google Cloud paths, and they need not both be used.

Knowledge Catalog is the managed path for governed discovery across data and AI assets. Google Cloud’s OKF launch material states that Knowledge Catalog can ingest OKF and serve its context to agents. It is the natural first choice when catalog governance, automatic technical-metadata collection, and shared enterprise discovery are the primary requirements.

Spanner Graph is an optional execution layer when the research requires explicit cross-system traversal over custom nodes, edges, and temporal properties. It maps relational tables into a property graph and supports an ISO GQL-compatible query interface. A TKG projection can model Concept, ConceptVersion, and SourceObject nodes connected by DESCRIBES, SUPERSEDES, DERIVED_FROM, and IMPLEMENTED_BY edges. Spanner Graph does not supply the temporal meaning automatically; valid_from, valid_to, and observed_at remain application-defined properties enforced by retrieval predicates.

Gemini Enterprise Agent Platform text embeddings can supply semantic candidate generation 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 understand how OKF bundles, catalog entries, embeddings, and graph tables are assembled. Give it one narrow retrieval 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. It then invokes Drive, BigQuery, or another approved source tool using the returned resource identity. The source system performs the final authorization and returns the current content; the context tool never grants access or substitutes cached source data.

Operate it as a living layer

The architecture needs a continuous maintenance loop. 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. A consumer then materializes search and graph indexes from the bundle.

No enrichment pipeline can assume that one update schedule fits every source. A database schema, a policy document, and a rapidly changing operational record have different freshness requirements. stale_after should reflect the expected volatility of the concept, while source change events or periodic reconciliation should 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

The OKF specification supports this operating model without dictating it. Its concepts are portable; its indexes enable progressive disclosure; its provenance and lifecycle fields can be checked before a full document is loaded. The retrieval engine, access model, temporal extensions, and refresh policy remain deliberate choices for the system implementing the format.

What the current work suggests

The observations so far are directional rather than a completed quantitative benchmark. I have not attached a percentage improvement because the evaluation set, relevance judgments, and ablation runs still need to be formalized. The patterns are nevertheless consistent enough to guide the next phase.

First, contextual metadata improves routing. The agent can identify the likely system and resource before invoking several broad source searches. This is particularly useful when the same business concept appears in a database, a policy document, and an operational application.

Second, relationships improve disambiguation. Ownership, lineage, implementation, and supersession edges distinguish objects that share similar language but play different roles. The graph contributes structure that text similarity cannot reliably infer at query time.

Third, temporal qualifiers improve version selection. They make “current,” “at the time,” and “as of” explicit retrieval constraints rather than words the agent must interpret against an undifferentiated result set.

Fourth, the gain is smaller for exact identifier lookup. When a request already contains a stable table name, record ID, or document URL, a direct tool call is often the shortest path. A knowledge layer should not be inserted by habit where it adds no decision value.

Finally, the layer can make a poor result more confidently wrong if its context is stale, over-broad, or detached from source permissions. Search quality depends as much on maintenance and eligibility rules as on graph construction.

Next research phase

The next step is to convert the directional findings into a reproducible benchmark. That requires a fixed multi-system corpus, independently judged queries, explicit time-scoped tasks, and relevance labels at the source-object level. Every run should record the candidate list, selected source, version, tool sequence, latency, and final citations. It is also the highest-priority measurement in this series, because the maintenance architecture that follows exists to keep this layer true.

For the retrieval study, three questions matter most:

1. Does the full temporal and contextual layer improve top-ranked source precision over direct tool search?
2. Which contribution—semantic context, graph relationships, or temporal eligibility—accounts for the improvement?
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 research problem: who keeps the map current? A small OKF bundle can be maintained by hand, but manual edits do not scale across changing Workspace documents, database schemas, permissions, and enterprise records. A stale concept can be more dangerous than a missing one: its resource pointer may still work even though its meaning, validity, or verification has drifted.

That bootstrap-and-maintenance problem is developed in the next paper, Keeping Knowledge Alive. It establishes a bounded producer fleet that builds the first generations progressively, then uses a hybrid loop to keep them current: source events provide speed, scheduled reconciliation catches missed changes, idempotent producers regenerate repeatably, and confidence-aware review protects governed meaning. Stable resource identities, schemas, modification times, and provenance can often be refreshed mechanically. Business definitions, ownership, validity intervals, supersession, and prior human verification need stronger evidence or review before publication. The dependency is worth stating plainly: 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.

Its validation framework compares manual maintenance, event-only regeneration, and the hybrid loop. It measures freshness lag, missed changes, incorrect automatic publications, human-review load, recovery after delayed, duplicate, or out-of-order events, permission-leakage incidents, and the time stale concepts remain eligible for retrieval. The architecture answers the central design question: automation reduces maintenance work only when deterministic observation and review-gated meaning remain separate.

The architecture will be successful if it gives agents a better map while leaving enterprise data where its ownership, permissions, and operational controls already live. The research 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 central claim to test: better context should produce better search decisions, and better search decisions should let agentic tools reach the right authoritative data with fewer wrong turns.

References

1. Sam McVeety and Amir Hormati, “Introducing the Open Knowledge Format”, Google Cloud, 12 June 2026.
2. GoogleCloudPlatform, Open Knowledge Format v0.2 specification, 2026.
3. Sam McVeety and Amir Hormati, “Open Knowledge Format v0.2 tackles agentic trust”, Google Cloud, 24 July 2026.
4. Google Workspace, Subscribe to Google Drive events, 2026.
5. Google Drive, Changes and revisions overview, 2026.
6. Google Cloud, Introduction to BigQuery INFORMATION_SCHEMA, 2026.
7. Google Cloud, Knowledge Catalog overview, 2026.
8. Google Cloud, Spanner Graph overview, 2026.
9. Google Cloud, Get text embeddings, 2026.
10. Google Cloud, Scale your agents with Gemini Enterprise Agent Platform, 2026.
11. Google Cloud, Use Pub/Sub with Cloud Run, 2026.

Suggested citation