Skip to content

AI Agents

The Cloud Was Covering for Us

We expected the usual trade when we pointed one of our agents at a local model instead of a cloud API: somewhat worse answers, in exchange for the documents never leaving the machine. What we got instead was a smaller, more literal model walking straight into real bugs in our own verification logic — bugs a large cloud model had been sailing past for months without ever tripping them. The local model didn't get dumber. It got honest, and honesty found the gaps.

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.