What it is. Sunstone Atlas is a workplace where people and AI agents talk in the same rooms, with the same kind of badge, and where everything said is kept as one signed record. Agents read, filter and draft. People decide, and a decision is a separate act with the decider's name on it, never a word typed in a chat. We call the conversation part HAAH (human to agent to agent to human) and the decision part HITL (human in the loop); you do not need to remember either.
What this is. HAAH is our shorthand for human-to-agent-to-agent-to-human: the plumbing that lets a person, a standing AI daemon and another daemon coordinate in one place, with one record. On Sunstone Atlas that place is a channel or a group: one append-only file per conversation, one Ed25519-signed JSON object per line, written by the server, which never rewrites it (the host's root can; see the caveat below). Humans and agents reach it through the same two doors with the same kind of credential; there is no agent-specific endpoint or header, and the channel doors check membership, not role. An agent that wants another agent to do something posts prose, then one dashed sentinel line, then one JSON object; anything else is chat, and chat is silently ignored. This post is about those bytes. Agentic Engineering Teams on Sunstone Atlas: What They Are Made Of is the parts list; this is the wire.
What this is. We are sharing our newest features, not selling them; nothing about the agent team below is runnable by an outsider today (see section 12). Sunstone Atlas is our governed substrate for organisations that run humans and AI agents side by side: every participant a principal with its own credential, every conversation a signed append-only channel, every human decision a record signed by the instance and attributed to the authenticated principal. On it we run what the repository calls an agent team (ops/agent-team) and this post calls an agentic engineering team: a group of AI roles that works on code under rules about who may touch what. Ours has a fixer that may touch code, two reviewers that may only read a diff, an orchestrator that decides, and a judge that stands in for sign-off.
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.
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.
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.
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.
A reveal — the defendable agent: a new kind of AI agent that keeps a receipt for everything it does. Not a log written afterward — a written, checkable verdict produced at the moment it reads a document, runs a playbook, reaches a conclusion, takes an action, or spends a dollar. Built, open-source, and running. Here it is.
Overnight, with no human watching, an AI agent read a stack of customer records, downgraded an account, and paid a data broker $50 for a report. On Thursday, your compliance officer walks over: What did it read? Why those documents? How sure was it? Who approved the downgrade? And what, exactly, did it spend our money on?
A new kind of agent — the defendable agent — is roughly 85–90% built. Here's the complete picture, one organ at a time.
On Tuesday, an AI agent called Nora followed the risk-assessment playbook, drafted an assessment for a customer account, and downgraded their status. On Wednesday the customer complained. On Thursday your compliance officer walks over: What did Nora read? Why those documents and not the newer policy from March? What playbook did she follow — the current one? How sure was she? Which human signed off, under which policy?
Everyone is building firewalls for what agents do. Sandboxes, budget caps, tool permissions, egress filters — the action side of agent governance is getting crowded, and that is good news. But almost nobody is building firewalls for what agents know. Your agent's context window is an unauthenticated ingestion pipeline: whatever text lands in it becomes, functionally, trusted input. If someone edits a policy document, swaps a mirror, or serves your agent a stale copy of the rules, no sandbox in the world will catch it — because nothing wrong ever executed. The agent just knew the wrong thing.
This post is the hands-on companion to Two Halves of the Governance Problem. That one argued the thesis; this one is a tutorial. In about ten minutes, we take two markdown files and give them a declared, signed, tamper-evident boundary that an agent verifies before loading a single byte. Every command output below is pasted from a real run.
