Skip to content

Architecture

The Borrowed Leash: Determinism as a Service for the Agentic Web

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:

claude mcp add kcp -- npx -y kcp-agent mcp

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.

The Vibes-Based Agent Era Deserves to End

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.

npx kcp-agent plan "how does the planner score units?" \
  --manifest https://raw.githubusercontent.com/Cantara/kcp-agent/main/knowledge.yaml

Selling News to Robots

Yesterday's tour of the whole protocol ended with a loose thread: "A knowledge economy ends with a payment — and RFC-0005 is still sitting at the RFC stage, waiting."

It didn't wait long. v0.25 landed on main the same day: Economic Metadata, the full promotion of RFC-0005. payment.methods[] — free, x402 micropayments, metered billing, subscriptions — plus per-tier rate_limits, all at manifest and unit level. Nothing of RFC-0005 remains RFC-only.

Which means something new is possible on the agentic web this weekend that wasn't possible last weekend: you can open a shop. So let's open one — a newswire that sells to agents — and then play the customer: an agent with a funded wallet, a briefing to write, and a budget. Step by step, both sides of the counter.

One Agent's Journey Through the Whole Protocol

This morning the Knowledge Context Protocol got its login page — v0.22 and v0.23, the consumer half of the trust model. This afternoon, v0.24 landed on main: Org-Federation, from RFC-0011. The enterprise front door.

That's twenty-four versions in six months — v0.1 shipped January 10th. And with the front door in place, something has quietly become true: an agent can now traverse the entire protocol, from "I know nothing but a company domain" to "I hold a signed receipt for the restricted knowledge I just consumed", and every step of that traversal is declared, verifiable, and standard.

So instead of another release note, let's take the tour. One agent, one traversal, every layer annotated with the release that built it.

The Human in the Loop — at Design Time

Tim O'Reilly posted something this week about craftsmanship in the AI age. The question he was circling: how do you maintain quality standards when agents are doing the work?

The default answer in the industry is: keep the human in the loop. For every meaningful decision, have a human review before proceeding.

That model contains a fatal flaw.

From What to Why: When AI Reveals Questions You Didn't Ask

For most of my career, analysis meant asking a question and getting an answer. How many deployments last quarter? Which modules have the most open defects? What is the test coverage of the payment service? The tools were built for this. You formulated a query, you ran it, you got a number. The number was correct. And the quality of your insight was entirely bounded by the quality of your question.

I did not think of this as a limitation. It was just how analysis worked. You got better at it by learning to ask better questions. Thirty years of architecture experience is, in large part, thirty years of learning which questions to ask and in what order. The senior architect's advantage was not access to better data. It was knowing which query to run.

That model is breaking. Not because the tools got faster at answering questions, but because a new class of tooling -- AI-augmented, temporally aware, relationship-tracking -- does something structurally different. It does not just answer your question. It tells you what you should have asked instead.

Why Temporal Matters: The Time Capsule Graph

Most systems I have built over thirty years answer one question well: what is the current state? A database query returns the latest row. A service responds with the live configuration. A dashboard shows what is happening right now. Current state is the default, and it is sufficient most of the time.

Some systems go further. They add history. An audit table, an event log, a change data capture stream. Now you can answer: what was the state at time T? Useful for compliance, useful for debugging. But still a limited question, because history stored as a sequence of snapshots tells you what changed without telling you how those changes relate to each other.

The questions I keep running into -- the ones that matter most -- are different. How did we get here? In what order? What does that trajectory mean? Those questions require something most architectures are not built to answer.