Google Cloud Shows How OKF and Knowledge Catalog Can Scale Agent Context Across an Organization

Google Cloud connects Open Knowledge Format with Knowledge Catalog

Google Cloud has detailed an approach for scaling Open Knowledge Format (OKF) bundles across an organization by publishing them into Knowledge Catalog, its context engine for agents.

The goal is to make structured context created for AI agents easier to discover, govern, and retrieve alongside the technical metadata already maintained by data teams.The announcement, published by Firat Elbey, Group Product Manager for Data Analytics, and Sam McVeety, Tech Lead for Data Analytics, builds on earlier versions of the Open Knowledge Format.

Why OKF needs an organizational layer

Google Cloud describes OKF as an open specification designed to formalize the "LLM-wiki pattern" into a portable and interoperable format.

OKF v0.1 established a structure based on Markdown files with YAML frontmatter and defined conventions for packaging context. OKF v0.2 added trust signals covering provenance, verification, freshness, and attestation.

That provides a way for teams to create trustworthy context bundles, but Google Cloud points out a separate challenge: sharing and governing those bundles at organizational scale.

A Git repository can store an OKF bundle, but it does not automatically provide the same search, identity, governance, and metadata capabilities available for enterprise data.

Teams may also have to know where individual bundles are stored, while the context itself remains separate from information such as schemas, lineage, ownership, and tags.

Google Cloud's approach is to use Knowledge Catalog as the organizational layer for these bundles.

Knowledge Catalog becomes the discovery layer for agent context

Knowledge Catalog provides a governed index across resources such as BigQuery, Cloud Storage, operational databases, and applications.

According to the announcement, catalog entries can contain schema, lineage, ownership, and tags. They can also be extended with typed aspects for domain-specific information. Search and cross-project lookup allow agents to retrieve context for individual queries.

The proposed OKF integration maps concepts from an OKF bundle onto existing Knowledge Catalog types.

This means the context can be discovered through the same catalog mechanisms used for other enterprise resources.

How an OKF bundle is published

Google Cloud says publishing an OKF bundle requires a one-time setup followed by a push operation.

The sample implementation in the Knowledge Catalog repository registers three resources:

1. An EntryGroup to hold the bundle

2. An EntryType called okf-bundle

3. An AspectType called okf

The okf AspectType carries the structured signals defined by OKF v0.2.

When the bundle is pushed, each concept becomes an okf-bundle Entry.

Each concept receives two Aspects:

• An overview Aspect containing the Markdown body

• An okf Aspect containing structured OKF signals

The Entry itself stores information such as display name, description, and tags.

The bundle's navigation files and root log.md are also published as Entries, preserving the structure of the original bundle inside Knowledge Catalog.

The 13-field OKF Aspect

The okf AspectType defined in Google's sample code contains 13 fields covering the OKF v0.2 specification.

These include:

• okf_type for identifying the document type

• generated for the actor and timestamp associated with meaningful changes

• sources for source materials and credibility signals

• verified for verification events

• status for lifecycle state

• stale_after for freshness boundaries

• usage_window for the period covered by source usage information

• runtime for how an Attested Computation runs

• parameters for typed caller-supplied inputs

• computation for the computation body location

• executor for execution and evidence requirements

• attester for the component that evaluates execution evidence

• extra for producer-defined frontmatter that is not otherwise modeled

The structured representation is important because agents do not have to parse every signal from Markdown.

Google Cloud says scalar fields can be used directly in Knowledge Catalog search predicates. Agents can then perform additional client-side filtering for array-based fields after retrieving the complete Entry.


From Git repository to searchable catalog

The publishing workflow uses kcmd, the Metadata-as-Code CLI included in the Knowledge Catalog repository.

The tool reads the OKF bundle from Git and writes its concepts into the target Knowledge Catalog EntryGroup.

The bundle uses a Documents Layout, with Markdown files under a catalog/ directory and a catalog.yaml file defining the snapshot's entry and aspect types.

Google Cloud's example uses an Acme Retail bundle to demonstrate the process.

The synthetic bundle contains concepts covering areas including attesters, tables, metrics, computations, policies, and skills. The announcement says the example produces 17 pushed Entries, with Dataplex also creating an additional Entry associated with the EntryGroup.

What agents can retrieve

Once an OKF bundle is published, agents can discover its concepts using Knowledge Catalog's existing APIs.

The workflow described by Google Cloud has three main stages:

1. Search

searchEntries identifies candidate Entries using search terms and supported aspect predicates.

2. Retrieve context

LookupContext retrieves the full concept body for selected Entries as pre-formatted YAML.

3. Retrieve structured trust information

entries.get with view=ALL returns the structured OKF signals, including fields such as okf_type, generated, and sources.

An agent that already knows the Entry names it needs can skip the search stage. Google Cloud also notes that LookupContext can resolve up to ten explicitly supplied Entry names in a single call.

IAM provides the governance model

Governance is another central part of the approach.

OKF Entries inherit permissions from their Knowledge Catalog EntryGroup. This means organizations can use the existing Knowledge Catalog IAM model rather than maintaining a separate permission system for OKF bundles.

The source states that an agent requesting an OKF concept and a BigQuery table in the same call receives only the resources that the caller is permitted to access.

The announcement identifies roles/dataplex.catalogViewer for agents that need catalog read paths such as entries.get, LookupContext, and searchEntries.

The identity performing kcmd push uses roles/dataplex.catalogEditor for write operations.

Google Cloud also describes an EntryGroup-per-team model for organizations managing multiple bundles. IAM permissions on the EntryGroup then apply to its Entries.

Trust and freshness become machine-readable

The integration also gives AI agents access to structured trust signals.

The source describes fields covering provenance, verification, lifecycle state, freshness, execution, and attestation.

The example Revenue concept demonstrates how a business definition can include verification information and a stale-after date. Its structured Aspect separately represents fields such as its OKF type, generator, verification record, status, freshness date, and source information.

This distinction matters for agent workflows because trust information is represented separately from the main Markdown body.

An agent can retrieve the human-readable concept through LookupContext while obtaining structured OKF signals through entries.get.

Lifecycle and continuous updates

Google Cloud describes kcmd push as an idempotent upsert.

Running the push again does not create duplicates, although every Entry is written during the operation.

Deleting individual concepts requires an explicit kcmd delete, while cleanup.ts can remove an entire EntryGroup and its Entries. The shared okf AspectType and okf-bundle EntryType remain available for other bundles.

For continuous production ingestion, the announcement recommends connecting a CI job to kcmd push so changes to the bundle repository can be synchronized with Knowledge Catalog.

What this means for enterprise AI

The announcement highlights a broader industry shift toward treating context as an enterprise-managed resource rather than simply as files stored alongside an application or AI project.

For enterprises, this could mean AI agents can consume business definitions, policies, metrics, and other contextual information through an existing catalog and permission framework.

The approach also separates three concerns that can otherwise become tightly coupled:

• Content: the Markdown knowledge itself

• Trust: provenance, verification, freshness and attestation signals

• Governance: catalog discovery and IAM-based access

This separation could make it easier for organizations to manage agent context as the number of bundles and consuming agents grows.

However, the announcement focuses on the Knowledge Catalog integration and sample implementation. It does not provide independent performance measurements, adoption figures, or enterprise deployment statistics. Additional details were not disclosed in the announcement.

Getting started with OKF and Knowledge Catalog

Google Cloud recommends starting with the OKF v0.2 specification and the Acme Retail example bundle.

Teams can then create a smaller bundle for a domain they manage, synchronize it with Knowledge Catalog using the provided setup and push tooling, and connect existing agents to Knowledge Catalog.

The intended result is that newly published context becomes available through the same searchEntries and LookupContext mechanisms already used by Knowledge Catalog clients.

For organizations building agentic AI systems, the development points toward a practical architecture in which context, metadata, discovery, and access control are handled through a common enterprise layer.