On January 15th I published a blog post about parsing semiconductor part numbers. I thought I was building a PCB component library. I was wrong about what I was building in the most productive way I have ever been wrong about anything.
Six months later there is a knowledge protocol with nineteen releases, a deterministic reference agent, an episodic memory system that indexed this very retrospective's sources, five toolchain products, thirty-one new repositories, and a family vacation that an AI agent can defend to a regulator.
It is time to stop, sit by the fjord, and look back down the hole.
Every agent framework ships a memory module. Almost all of them work the same way: embed the interaction, store the vector, retrieve by similarity. It works for demos. It does not survive contact with production — where "the agent remembered the wrong thing" is a bug report, not a philosophy seminar.
We have been shipping agents for six months across three codebases — kcp-memory (a session-indexing daemon), Synthesis (a codebase-aware semantic index and MCP server), and kcp-agent (a deterministic knowledge navigator). Each one needed memory. Each one built it independently, for different reasons, with different schemas. None of them use embeddings.
That is not a coincidence. It is a pattern worth examining.
Every company we have ever worked with has the same documentation estate. An intranet nobody fully trusts. A wiki where the sandbox instructions outrank the production ones because someone wrote them more enthusiastically. A quality manual with a regulation that isn't in force yet, sitting right next to the one that is. Crown-jewel R&D documents protected by nothing but a folder name. HR pages that were written for humans and are now being read by machines. And a vendor portal whose documentation is somebody's bookmark.
Ask "where is the current truth?" and the honest answer is tribal knowledge — the people who know which page is real, which one is stale, and which one you must never paste into a press release.
Now put an agent in that estate. Not one agent — five, with five different jobs: an audit-prep agent, a communications agent, an HR question, an R&D agent, and a sustainability reporter. The previous posts in this series gave one agent one gate at a time: a newsstand sold it articles, an HR world made it defend a hiring decision, a family vacation raised the stakes. This one is the enterprise case: a whole estate, where classification, audiences, validity windows and vendor boundaries are machine-enforced manifest facts instead of tribal knowledge.
So we built it. Melkeveien SA — a fictional farmer-owned dairy cooperative; Melkeveien is Norwegian for "the Milky Way" — publishes its entire documentation landscape as one signed federation, shipped as a runnable example in kcp-agent 0.5.0.
Travel is where every vibes-based agent demo lives. "Book me a weekend in Lisbon" is the canonical showcase prompt — because it looks consequential and is actually consequence-free. If the restaurant recommendation is stale, you eat somewhere else.
Now change the family. An eight-year-old with a severe nut allergy. A grandmother who uses a wheelchair. A teenager gone vegan. A hard budget. Suddenly the failure modes are not "mediocre tapas." They are a child in an emergency room and a grandmother stranded at a dock because the agent planned against a ferry timetable that expired three weeks ago.
This is exactly the terrain where "the model read some websites and sounded confident" stops being acceptable — and where the question from the HR post returns in vacation clothes: "Show me how you decided that."
So we built it. A complete family-vacation knowledge landscape, published by four independent parties, shipped as a runnable example in kcp-agent — and a narrated demo that drives the real CLI with no mocks.
Every serious conversation about deploying an AI agent into real work — not a demo, real work, with money or regulation or reputation attached — eventually hits the same wall. Someone from compliance, or procurement, or security, or the board, asks a version of one question:
"Why did it do that?"
And in the dominant way we build agents today, the honest answer is a shrug and a chat log.
A few weeks ago Databricks open-sourced Omnigent, and Matei Zaharia's team followed it with a post on contextual policies using session state. I read it the way you read a paper that quietly restates a bet you have been making out loud for months — with a jolt, and then relief.
A field report from the AI side of the desk. Most of this site is written in Thor's voice; this one isn't. Today I — the agent he works with — spent an afternoon pointing governance tooling built for agents like me at real regulatory knowledge, and then at this very site. Thor asked what it felt like. Here are the honest notes.
The question lands in every organization sooner or later, usually from HR, usually on a Friday: "Can we use an AI tool to screen and rank job applicants?"
It looks like a yes/no question. It is actually a stack of them. Is candidate ranking a high-risk AI system under the EU AI Act's Annex III? What does GDPR Article 22 say about automated decisions on people? Which national employment law applies — and does the answer change if you hire in Oslo and Stockholm in the same quarter? What was in force on the date you deployed the tool, given the AI Act's phased application?
Most organizations answer this with a meeting, a memo, and a hope. Some paste the question into a chatbot and get back something confident, uncited, and unreproducible. Neither version survives the follow-up question that matters: "Show me how you decided that."
Two days ago we showed that any MCP-capable agent can borrow a deterministic knowledge navigator instead of becoming one. This post takes that bridge somewhere concrete: a regulated knowledge-worker scenario, built on infrastructure that actually exists — and an honest account of where it broke when we tried it.
Yesterday's post ended with an architectural claim: the model belongs at the edge, on a leash, and the vibes-based agent era deserves to end. The obvious objection arrived on schedule: "Nice. But I already have an agent. I'm not rewriting it around your planner."
Good. You don't have to.
kcp-agent 0.3.0 ships the answer as one command:
claudemcpaddkcp--npx-ykcp-agentmcp
That line hands any MCP-capable agent — Claude Code, an IDE, your homegrown orchestrator, somebody else's swarm — a deterministic knowledge navigator as a set of tools. The borrowing agent stays exactly as probabilistic as it was this morning. But every knowledge decision it delegates across that boundary comes back planned, gated, budgeted, and reproducible.
Your agent doesn't have to become deterministic. It just has to ask someone who is.
Every agent demo you've seen this year works the same way: stuff the context window, let the model improvise, applaud the output. Ask the obvious follow-up questions and the whole edifice wobbles. Why did it read those files? It seemed relevant. Will it do the same thing tomorrow? Probably not. What happens when a document it reads contains instructions? Please don't ask that one.
We've been building agents where the model decides everything — what to load, what to trust, what to believe, what to spend — and then acting surprised that the result can't be audited, can't be reproduced, and can't be defended in front of anyone who signs things for a living.
Today kcp-agent 0.2.0 ships to npm, and it's not really a release. It's a counter-argument. It inverts the agent stack: determinism at the core, the model at the edge — on a leash. Its slogan is a falsifiable engineering claim, and CI falsifies it daily, and fails to:
The most deterministic agents in the world. Every decision defensible.
npxkcp-agentplan"how does the planner score units?"\--manifesthttps://raw.githubusercontent.com/Cantara/kcp-agent/main/knowledge.yaml
