AI Agents Need a Source of Truth
A field note on Open Knowledge Format, Codex-style long-running work, and why AI agents need readable context before memory gets useful.
A small Google Cloud post made the problem easier to name.
On June 13, Google Cloud published Open Knowledge Format, an open way to keep metadata, context, and curated knowledge in a directory of Markdown files with YAML frontmatter.
That sounds like data plumbing.
It is data plumbing. That is partly why it matters.
The boring part is the useful part
Most agent talk still points at the model.
Bigger context windows. Better memory. Better tools. Longer tasks. OpenAI has been writing about agents doing more complex work, and Codex examples now talk about projects that continue beyond a single prompt.
Good. The surface is getting more capable.
The quieter question sits underneath:
Where does the agent read from before it starts?
That is where the Google Cloud post gets interesting. The format itself is plain: Markdown files, frontmatter, links, metadata, and a folder structure. No magic.
That is the point.
Useful knowledge needs a place where people can inspect it and agents can use it. A wiki can hold some of it. A chat can hold some of it. A product database can hold some of it. The working layer still has to be readable, portable, and easy to correct. This is the practical job of a context system.
If the context is hidden, stale, or scattered, the agent can still sound fluent.
It will just be fluent from the wrong place.
Memory gets strange when nobody can inspect it
This is the part that keeps showing up in real work.
People want assistants to remember more. Then the assistant remembers something too broadly, too late, or with no source attached. A short-term decision becomes a permanent preference. A passing comment turns into a rule. A useful correction stays in one chat and never changes the system.
Memory often fails quietly.
You do not always know which old detail shaped the answer. You do not always know whether the model is using a current fact, an old summary, or a compressed version of something that used to be true.
That can be fine for casual use. It is weak for work that has evidence, ownership, risk, and review.
I wrote about the same failure from another angle in Understanding Is the Missing Layer. The problem is larger than recall. The problem is whether the system knows what kind of context it is using.
What a source layer looks like
The useful version is simple enough to draw.
The same layer as a folder view:
/context
├── CURRENT.md
├── MEMORY.md
├── decisions/
├── evidence/
├── review-log.md
└── routing-rules.md
This is only the shape.
Some things are current. Some things are durable. Some things are raw evidence. Some decisions need rationale. Some old material should stay visible while clearly marked as historical. Some corrections should update the source, so the next answer does not depend on somebody remembering to paste the same warning again.
The agent should be able to read the layer.
The human should be able to argue with it.
The human should be able to argue with the source.
That is where decision memory becomes useful. The point is to separate what was decided, why it mattered, what remains open, and where the operating source changes.
The same pattern shows up in brand memory. The useful layer explains why an asset should be used, when it breaks, and what needs review before it reaches production.
Why I keep testing this with LifeOS
LifeOS is where I keep testing this in practice.
The system lives in files: domain folders, current context, durable memory, raw evidence, local rules, logs, and small repairs when the assistant gets something wrong. The seven-domain structure is the simplest public map of it so far.
ChatGPT does the reasoning. Codex handles file operations. The important part is that the working state lives outside a chat history.
When the assistant gives a weak answer, the better question moves past the prompt.
The useful question is:
Which source did it read, and what needs to change?
Sometimes the answer is a better context file. Sometimes it is a clearer routing rule. Sometimes a temporary note needs to expire. Sometimes raw evidence needs to stay raw, instead of becoming a confident summary.
This is slower than pretending memory will solve everything.
It is also more reliable.
The work before the agent
I think this is the practical shift behind a lot of agent news right now.
Agents are getting better at doing work. That makes the layer before the work more important: the files, the context, the examples, the review path, the decisions, the logs, the source.
The agent can help once that layer exists.
When that layer is missing, the output may still look finished. That is the uncomfortable part. It can look clean while the foundation is missing.
For now, I would treat memory as useful support. The operating state belongs somewhere visible.
The serious work is making the source readable before asking the agent to be smart.