The previous post
introduced KCP and why llms.txt does not scale to production agent deployments. This post covers
what happens when you connect a knowledge.yaml manifest to a live MCP server — and why the
combination changes how agents behave.
Every mature engineering team graphs their code. Almost no one graphs their knowledge. The asymmetry is strange — and costly.
A real engineering session where Claude Code with Opus diagnosed 4 bugs, wrote 23 tests, and took a knowledge graph from zero virtual links to 11,777 — including one mistake and its recovery.
The agent answered the ROI metrics question with zero tool calls. It reported the indexing speed, the search latency, the file count, the retrieval time improvement, the test count. All correct. Every number accurate.
Then it said the metrics were validated on February 19, 2026.
The actual date was February 17.
We had 15 skill files documenting every Synthesis CLI command — syntax, options, example invocations, expected output. We wrote them carefully. We loaded them into the agent's context. We assumed the agent would use them.
Then we ran a benchmark.
The CLI condition was the worst-performing integration in the entire test. Worse than no integration at all.
Earlier today I published a post about Synthesis and why knowledge infrastructure is the layer the AI agent ecosystem is missing. Several people responded with a version of the same question: "We use llms.txt — isn't that enough?"
It depends on what you are trying to do. And I think the answer is worth a dedicated post.
I have been watching the AI agent space closely for the past year. The frameworks are impressive. The orchestration tools are clever. The models are increasingly capable. And yet, most agent deployments I see make the same quiet mistake: they treat the knowledge problem as solved.
It is not solved. It is barely addressed. And until it is, all the reasoning capability in the world will not make your agents reliably useful.
We build Synthesis — a knowledge indexing tool whose purpose is to make everything in a workspace searchable. We had been running it on our own workspace for months and the coverage number looked excellent: 99.6%. Nearly perfect.
That number was a vanity metric. It told us exactly what we wanted to hear while hiding what we needed to know. The real asset coverage was 15.2%.
I spent part of today rebuilding this wiki. Not because it was broken. Because when I read it carefully, it was wrong.
Not dramatically wrong. Wrong in the way things get wrong when you stop paying attention. I was listed as Chairman of IASA Norway. I stepped down from that role in 2011 -- fifteen years ago. One of my companies had the wrong founding year. The framing throughout was from a different era: SOA, distributed systems, the vocabulary of a decade ago. The site looked like me. It described someone who used to be me.
At the end of Part 1, I had IronClaw running on EC2, connected to Slack, with 28 tools registered — 8 of them from a Synthesis MCP server backed by 155 indexed files. The architecture looked correct. The logs said "connected." The tool list confirmed registration.
So I sent it a task.