Who Let the Agent In?
Part 7 of the KCP series. Previous: The Agent Read the Whole Spec. It Didn't Need To.
AI Agents & the Agentic Web¶
Add knowledge.yaml to Your Project in Five Minutes
A practical walkthrough of the KCP adoption gradient — from the minimum viable manifest to a full knowledge graph. No theory. Just the steps.
Your AI Has One Layer. It Needs Four.
The debate is "RAG or knowledge graphs?" The answer is neither — and both. Most teams pick one retrieval approach and stop. The interesting question is which layer they are missing, and what blind spot that creates.
KCP and MCP: One Protocol for Structure, One for Retrieval
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.
The Date the AI Invented
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 Gave the AI Better Documentation. It Got Slower.
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.
Beyond llms.txt: AI Agents Need Maps, Not Tables of Contents
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.
AI Agents Without Knowledge Infrastructure Are Interns With Amnesia
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.
When Your AI Lies About Its Tool Calls: Debugging kimi-k2.5
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.
Giving an AI Agent a Brain: Connecting IronClaw to Synthesis via MCP
IronClaw is the internal AI agent I run for eXOReaction. It sits on an EC2 instance, connected to Slack via a Python Socket Mode bridge, and answers questions from the team. The underlying model is kimi-k2.5 via OpenRouter. It is fast and capable, and it has no idea who we are.