Why I Built SMALL Protocol
Why I Built SMALL Protocol
Every AI agent system I've built or observed hits the same wall. The prompts get more elaborate, the outputs get stranger, and nobody can explain why a given run produced what it did. I started calling it the vibes problem: agents operating on vibes-based intent, where the only contract between the human and the machine is a paragraph of natural language that means something slightly different every time it runs.
That's not an engineering foundation. It's a prayer.
SMALL is my answer. It stands for Structured Metadata for Agentic Logic and Layering, and it's a minimal execution model that gives AI agents a deterministic skeleton to operate within. The core idea is that intent, constraints, plan, progress, and handoff should be explicit, layered artifacts - not buried inside prompts or inferred from conversation history.
The Problem with Vibes-Based Prompting
Prompt engineering has its place. You need natural language to communicate with models. But when you're building systems that need to run reliably at scale - where an agent orchestrates other agents, where one task's output feeds another's input, where a failure at step 3 needs to be diagnosed and resumed from a clean checkpoint - natural language alone fails you.
The failure modes are predictable:
- Intent drift: what the human meant and what the model understood diverge over long contexts
- State amnesia: the agent loses track of where it is and what it's already done
- Silent corruption: an agent produces plausible-looking output that's structurally wrong
- Handoff collapse: one agent can't pick up where another left off because there's no shared state format
I saw all of these in my own projects. I saw them in agent frameworks I evaluated. The frameworks kept adding more prompt engineering on top as the solution. More detailed instructions. More example outputs. More CoT scaffolding. But none of that changes the fundamental problem: if you can't prove what a system was told to do, you can't prove it did the right thing.
What SMALL Actually Is
SMALL defines five layers, each a first-class artifact:
Intent - A machine-readable declaration of what the system is being asked to do. Not prose. A structured object with a type, a target, and explicit constraints. The intent layer is immutable once set - an agent can't drift from it because it's not embedded in a prompt.
Constraints - Hard limits on what the agent may and may not do. Which files it can touch. Which APIs it can call. What it's forbidden from changing. Constraints are validated, not hoped for.
Plan - The execution sequence, broken into bounded steps. Each step has a defined input schema, a defined output schema, and a defined success condition. No vague "then do the rest" steps.
Progress - A running ledger of what has been completed, what failed, and what's pending. Agents write to progress. Observers read from it. This is how you resume a crashed run without replaying from scratch.
Handoff - The terminal state artifact. When an agent finishes its scope, it emits a handoff that contains the final state, the receipts for what was done, and the input surface for the next agent or human step.
These five layers are designed to be read by machines, not just humans. Any compliant SMALL agent - regardless of what model or runtime it uses - can pick up a handoff from another SMALL agent and continue without confusion.
Why This Matters for Multi-Agent Systems
The reason I built SMALL is specifically for multi-agent orchestration. When you have a single agent and a single human watching it, you can tolerate some ambiguity. When you have agents spawning agents, the tolerance for ambiguity is zero. One agent's bad output is another agent's bad input, and the error compounds.
SMALL gives you the contracts that make composition safe. Every agent in a SMALL system has a defined input surface and a defined output surface. You can validate at each layer boundary. You can audit any run end-to-end without relying on logs. You can swap out one agent for another as long as the new one respects the same layer contracts.
Current State
SMALL Protocol is released and in use in my own infrastructure. OpenClaw - my ops agent - runs under SMALL governance. The Reaper CLI project uses SMALL for its plan execution. The loopexec runtime is built on top of it.
The spec is available at smallprotocol.dev. The CLI tooling is in active development. If you're building agents and you're tired of the vibes problem, take a look.
The core conviction is simple: you should be able to explain what your system was told to do, what it actually did, and what state it left behind. If you can't answer all three, you're not running a system. You're running a mood.
