Skip to content

Writing

The Agent Didn't Guess. It Checked.

Somewhere in the middle of a playbook run last night, on a live production deployment, a step returned this: 41 nodes and 96 edges downstream, including two production-planning flows.

No model wrote that sentence. Nobody had to decide whether to believe it. A deterministic simulator — a separately built model holding the real dependency graph of a real system — computed it, signed it, and handed it to the next step. The AI steps on either side of that moment then had to reason from the number instead of around it. That's the whole mechanic, it ran end to end for the first time last night, and I think it's the most important small thing we've shipped this year.

Five Agents Compared

The agent landscape in mid-2026 has crystallized into distinct architectural philosophies. This post compares five entries. Four of them — Claude Code, Crush, OpenClaw, kcp-agent — are standalone tools, each successful, each widely discussed, representing fundamentally different answers to the question "what should an agent be?"

This is not a feature matrix. It's an architecture comparison. The interesting part isn't which one is "better" — it's what each one assumes about the problem, and where those assumptions diverge.

The fifth entry, pi-kcp, is a different kind of thing, and the difference is worth being precise about up front. It isn't a standalone product you'd install instead of the others — it's the KCP governance stack integrated into Pi, an independent coding-agent harness; you'd encounter it as part of choosing Pi as your coding agent. It gets full table presence anyway, because it does something none of the other four do: it verifies its own execution against what was approved — digesting what a gate approved for a tool call and, separately, what actually executed, keyed to the same call, and flagging divergence. Along the way it also settles a question the layering argument below would otherwise leave open: whether the deterministic knowledge layer really can be lifted out of one agent ecosystem and dropped into a completely different one. We'll get there.

How to Build Agentic Software on Sunstone Atlas

Add agents. Keep control. A hands-on walkthrough of the building blocks, using a real production system as the worked example.

Most "agentic" software today is an LLM in a loop with tool access and a prompt that says please be careful. That works right up until the agent is allowed to do something that costs money — approve an expense, send a quote, create an order — and someone from Risk or Compliance asks the only question that matters: how do you know it stayed inside the rules, every time, and can you prove it?

If the honest answer is "we trust the prompt," the deployment stops there.

Sunstone Atlas takes a different position: agents should be able to act autonomously and the system should be able to prove, after the fact, that letting them act was safe. Not with a gateway that blocks everything interesting, but with a substrate where every capability, every fact, every procedure, and every participant is a signed, versioned artifact, and every decision at runtime — model judgment, deterministic rule, or human sign-off — is a cryptographically signed, replayable event on an append-only ledger. Conformance + signing + grounding: defendable by construction, not by assurance.

Fast Turned Out to Be Fun

Last week, two serious systems went from empty repository to actually working, each in a single working day. One of them, a governed sales-demo system I'll call Project Falcon, went from repo creation at 09:27 to live and running for a real prospect around 16:45. The other, a commercial-intelligence engine I'll call Project Otter, went from first commit at 08:16 to its ninth tested build phase committed at 17:15. Not prototypes, not slideware. Real functionality, tested, running.

I want to write down what that week actually looked like, because the honest version is more interesting than the hype version. Yes, it was fast. Yes, it was genuinely fun, the kind of fun I remember from the early days of getting anything to work at all. And no, it was not effortless. Both of those are true at the same time, and I think the "how" behind it is worth explaining properly.

The Skill Is the Security Boundary

The Skill Is the Security Boundary — deterministic, declarative governance for defendable AI agents with pi-kcp

When your agent loads a skill, it loads a playbook — and, implicitly, an author's idea of what that playbook should be allowed to touch. A deploy skill means the deploy scripts. A research skill means the research corpus. But in almost every agent harness today, that idea stays implicit: the skill shapes the agent's behavior while the agent keeps its entire toolbelt. The deploy skill can read /etc/shadow. The research skill can call out to the network. Nothing binds the actions to what the skill claimed to be.

The illusion of implicit boundaries — an agent with an active "deploy" skill still holds a robotic arm that can reach network access and /etc/shadow, because nothing binds the claim to the action

pi-kcp makes the binding explicit. A governed skill declares its authority — an allowlist of tools and path prefixes called an action_scope — in the same knowledge.yaml that already governs what the agent knows. At runtime, inside the turn, every native tool call taken under that skill is adjudicated against the declaration. In scope: it runs. Out of scope: it is held, fail-closed, with a written reason naming the violating target and the authorized scope it fell outside of. Deterministic. No LLM in the loop.

This is the hands-on follow-up to the Policy vs. Enforcement post from earlier today, which named both kcp-harness and pi-kcp but didn't show the mechanics. Below are the mechanics — three worked demos, real outputs pasted from real runs, ending with the one that motivated the LinkedIn post: the same out-of-scope action, checked at two different depths of the stack, producing a byte-identical verdict.

The Software Itself Is Becoming Agentic

This week we shipped a feature in Sunstone Atlas where one playbook can, at runtime, call in another playbook as a real sub-orchestration — a crew calling in another crew, each with its own ledger and its own replay story. A playbook can also propose handing off to a successor when it completes; nothing auto-fires, an explicit human act is required to actually start the successor. And neither the calling unit nor the called unit may participate at all until each has separately, explicitly earned certification for exactly that — a binary, human-signed trust decision that can be revoked as easily as it was granted.

Notice what that is. It is not a developer using an AI to write code faster. It is the shipped software making a composition decision at runtime, and being held to a governance standard for making it.

The KCP Universe: Everything, and What July Changed

In July 2026, twelve repositories in the Knowledge Context Protocol ecosystem took 1,012 commits and shipped 88 releases. The specification went from v0.22 to v0.30.3 — sixteen releases in a single month.

That is either a lot of noise or a lot of signal, and the only honest way to tell you which is to show you the whole thing.

This is the complete map. If you have never heard of KCP, start at the top and it will make sense. If you have been following since February, skip to July in focus — that is where everything new is.

Same Blueprint, Different Doors

Same Blueprint, Different Doors — the convergent evolution of governed AI agents, rendered as an engineering blueprint

Anthropic published a long, careful writeup of how they built self-service data analytics on Claude internally — the system that lets anyone at the company ask a business question in plain English and get back a governed, provenance-tracked answer. 95% of their analytics queries are now automated this way, at roughly 95% aggregate accuracy.

We read it the way we read anything that touches how agents know things: looking for where we were wrong.

We found something else instead. Strip away the domain — theirs is a data warehouse, ours is a codebase and a governance practice — and the architecture underneath is close enough to feel less like inspiration and more like recognition. Two teams, no contact, building the same shape from opposite doors.

From Pasted Prompts to Signed Charters: A Short History of the Agentic Skill

From Pasted Prompts to Signed Charters — the evolution from a pasted release prompt to a signed, enforceable skill charter

In 2023, if you wanted an AI to help you cut a release, you typed a small prayer into a chat window and pasted the answer into your terminal.

This morning, an agent in my toolchain was offered a release skill by a deterministic planner, which noted — in writing, in a receipt — that the skill was relevant to the task but not eligible to run, because no human had granted it enactment rights. The skill itself declared, in a signed manifest, exactly which tools it may invoke and which files it may touch. A linter had checked that declaration. A different program stood ready to block any tool call that reached outside it.

Same workflow. Same twenty lines of playbook. Completely different kind of object.

The distance between those two moments is about three and a half years, and almost nobody noticed the transitions while they happened — each one looked like a small quality-of-life improvement at the time. Told end to end, they form one story: the agentic skill slowly acquiring the properties of a charter — a scoped, reviewable, revocable grant of authority. This post walks that history with one deliberately boring running example, because boring examples keep us honest: how does the AI help you cut a release?

The Agent That Knows What It Knows

The Agent That Knows What It Knows — moving AI procedural memory from flat grep to a living protocol

Here is a confession. Our AI development rig — the one we call ExoCortex — has 644 skills: little packets of procedural memory that tell it how we deploy, how we review, how a specific client's CI is wired, how to publish to this very blog. And until this week, the way it found the right one, out of 644, was grep.

Keyword match against a flat index. No ranking. No freshness. When a query touched a common word, it got back a pile of candidates and had to read through them to guess. We only really noticed the cost the day we discovered that one of the skills it leans on daily had sat three weeks stale — describing a system four pull-requests out of date — and nothing, anywhere, had flagged it.

An agent that can't tell which of its own memories is rotting is not, in any deep sense, remembering. It's hoarding.