Agentic Memory Comes of Age: Inside OKF

Everyone building AI agents eventually hits the same wall. The model is brilliant, the tools are wired up, the demo dazzles—and then the agent forgets everything the moment the context window rolls over. Reasoning has raced ahead. Memory has not. It remains the single most important and least mature layer of the entire agentic stack.

For the last two years, "agent memory" mostly meant one of two crude approximations: stuffing more history into an ever-larger context window, or bolting on a vector database and hoping semantic search retrieves the right chunk at the right moment. Both work in a demo. Both fall apart in production, because neither is actually knowledge—they are just text, retrieved by luck, with no structure, no provenance, and no way for a human to read or correct what the agent believes.

That is finally starting to change. In June 2026, Google Cloud published the Open Knowledge Format (OKF) v0.1—an open, vendor-neutral specification for how organizations represent and share the knowledge their agents depend on. It is the clearest signal yet that agent memory is graduating from a clever hack into real infrastructure. And as it does, it becomes something SecuriX cares about deeply: a new boundary that has to be governed.

Why Memory Is the Hard Problem

The knowledge an agent needs to be genuinely useful inside a company is almost never in one place. It is scattered across:

• Metadata catalogs locked behind proprietary APIs
• Wikis, Notion pages, and shared drives
• Code comments and docstrings
• The heads of a handful of senior engineers who "just know" why the orders table has three status columns

Every team building an agent solves this same context-assembly problem from scratch, and every solution is a bespoke, brittle pipeline that locks the knowledge inside one vendor's runtime. The result is that the most valuable asset an agent has—accumulated institutional understanding—is the least portable, least auditable part of the system.

Memory as Files: The Core Idea

The Open Knowledge Format makes a deceptively simple bet: the best format for agent memory is the one humans already use to write things down.

OKF is not a platform, a database, or an SDK. It is a format. Knowledge is represented as a directory of Markdown files—one file per "concept" (a table, a dataset, a metric, a runbook, an API)—each with a small block of YAML frontmatter for structured metadata and a Markdown body for the detail. Concepts link to each other with ordinary Markdown links, forming a navigable graph of relationships.

A single concept looks like this:

type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z

And a knowledge bundle is just a folder you can commit to git:

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
    ├── index.md
    └── weekly_active_users.md

That is the whole idea. No proprietary runtime, no required SDK. It is just Markdown (readable in any editor, renderable on GitHub), just files (shippable as a tarball, hostable in a repo, mountable on a filesystem), and just YAML frontmatter (enough structure to make it queryable).

Three Principles That Make It Work

1. Minimally opinionated. The only required field is type. Everything else is the producer's choice, so the format bends to your domain instead of forcing your domain into a schema.
2. Producer/consumer independence. Whoever writes the knowledge is cleanly decoupled from whoever reads it. An enrichment agent can generate documentation for a data warehouse while a completely different agent framework consumes it—no coordination required.
3. A format, not a platform. No accounts, no lock-in, no runtime dependency. Knowledge you author today outlives whatever agent framework is fashionable next quarter.

The LLM-Wiki Insight

OKF builds directly on an observation from AI researcher Andrej Karpathy about treating a knowledge base like a wiki that agents themselves maintain: "LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass."

That single line captures why files beat vector blobs for memory. A wiki of Markdown documents is a substrate that both humans and agents can edit. An agent can walk a data warehouse, draft a document per table, enrich it with join paths and citations, and cross-link it—maintaining its own library the way a diligent engineer would. A human can open the exact same files, correct a wrong assumption, and manage the whole thing with pull requests. The documentation lives next to the code it describes and stays synchronized because updating it is part of the workflow, not an afterthought.

To prove the point, Google shipped reference implementations alongside the spec: an enrichment agent that drafts OKF documents by walking BigQuery datasets, a zero-backend static HTML visualizer that turns any bundle into an interactive graph, and sample bundles built on GA4 e-commerce, Stack Overflow, and Bitcoin datasets.

Why This Matters: A Comparison

The shift is from memory as a black box you query to knowledge as an artifact you can read, review, version, and trust.

The Part Nobody Is Talking About: Memory Is Now a Security Boundary

Here is where it gets interesting for anyone deploying agents in the enterprise. The moment agent memory becomes a durable, shared, human-and-agent-writable artifact, it stops being a convenience and becomes an attack surface.

At SecuriX we look at every new agent capability through one lens: what happens when it is wrong, hijacked, or abused? Portable agentic memory raises exactly the questions OAuth scopes and RAG pipelines were never built to answer:

• Memory poisoning. If an agent writes to its own knowledge base, a single prompt injection can plant a false "fact" that quietly steers every future decision. Poison the wiki once and you have compromised every agent that reads it—no exploit needed, just a persuasive paragraph.
• PII that never forgets. Structured memory is durable by design. Sensitive values that once flashed by in a transient context window can now be written to a file, committed to a repo, and replicated everywhere the bundle travels. Memory turns a momentary exposure into a permanent one.
• Unbounded read access. A knowledge graph is only safe if agents can read their slice of it. Without enforcement, one over-permissioned agent can traverse cross-links straight into datasets, runbooks, and credentials it was never meant to see.
• No audit of belief. When an agent acts on a "fact," which document did it come from, who wrote that document, and when? Without a trail, you cannot explain the agent's behavior—let alone defend it in a compliance review.

These are not reasons to avoid portable memory. They are reasons to govern it. The same deterministic, policy-as-code layer SecuriX places between agents and their tools applies cleanly to memory: enforce what an agent may read and write into its knowledge base, mask PII before it is ever persisted, and keep an immutable audit trail of every read and write so an agent's beliefs are as accountable as its actions.

The industry spent two years teaching agents to remember. The next two will be about making sure that memory is portable, correct, and trustworthy. Open standards like OKF solve the first. Governance solves the rest.

Credits & Source

The data, insights, and technical details on the Open Knowledge Format in this article are drawn from Google Cloud's original announcement, How the Open Knowledge Format can improve data sharing. Full credit to the Google Cloud team for authoring and open-sourcing the OKF specification. The security perspective and commentary in this post are our own.

Deploying agents with real memory? Put a security boundary around what they read, write, and remember. Set up your first governed connection in seconds at https://dash.securix.app.