SMALL Protocol v1.0.0 Is Released

Most AI execution breaks in the same place.

Not in generation quality. Not in token count. Not in whether a model can write code, summarize context, or propose a plan.

It breaks at state.

Chat transcripts are not durable project state. Session memory is not a contract. Prompt history is not governance. Once work stretches across multiple turns, multiple tools, multiple files, or multiple actors, teams start reconstructing reality from fragments.

That is the problem SMALL Protocol is built to solve.

SMALL Protocol v1.0.0 is now released.

What SMALL is

SMALL is a protocol for durable execution state.

It defines a machine-legible contract for how work is declared, constrained, proposed, recorded, and handed off. The goal is not to make agents more theatrical. The goal is to make execution inspectable.

SMALL gives a project explicit state surfaces for:

• what the work is
• what cannot change
• what is proposed
• what actually happened
• what is needed to resume cleanly

In practice, that means less drift, less ambiguity, and fewer fake resumes where a system pretends it knows more than it does.

What shipped in v1.0.0

SMALL v1.0.0 defines five canonical artifacts:

• intent.small.yml
• constraints.small.yml
• plan.small.yml
• progress.small.yml
• handoff.small.yml

That set is intentionally strict.

It is large enough to preserve ownership, continuity, and auditability. It is small enough to stay usable in real projects.

This is not a sprawling framework with twenty layers of abstraction. It is a minimal execution contract that survives contact with actual work.

Why this matters now

The industry is moving fast on agents and slow on boundaries.

Top labs are shipping stronger models. Indie developers are wiring those models into real tools faster than ever. But most stacks still rely on implicit context, mutable instructions, and transcript archaeology once something goes off the happy path.

That is not a scaling problem. It is a state problem.

If a system cannot answer these questions clearly, it is not ready for serious agent execution:

• What is the intended outcome?
• What constraints are binding?
• What work is proposed versus verified?
• What changed?
• Where is the clean resume point?

Without explicit answers, teams get motion without reliability.

SMALL is the missing contract layer between "an agent can do something" and "a system can be operated safely over time."

The core design choice

SMALL governs state, not execution.

That distinction matters.

Execution engines will keep changing. Models will keep changing. Toolchains will keep changing. The protocol should not have to change every time the surrounding stack does.

By keeping the contract focused on durable state, SMALL stays useful across:

• solo operator workflows
• human plus agent collaboration
• multi-agent runs
• long-running build cycles
• resumable project execution
• audit-heavy environments where evidence matters

This is a protocol you can build around, not a product cage you have to buy into.

Ownership is explicit by design

One of the biggest failure modes in AI-assisted work is blurred authority.

Humans think constraints are fixed. Agents quietly rewrite them. Plans get mistaken for facts. Progress updates become narrative instead of evidence. A handoff becomes "scroll up and read the thread."

SMALL fixes that by making ownership visible on disk.

In the reference workflow:

• humans define intent
• humans define constraints
• agents can propose plans
• agents can append progress with evidence
• systems can serialize handoff state for resume

That split is not bureaucracy. It is operational clarity.

When ownership is explicit, resume quality goes up and failure recovery gets simpler. You can inspect the state instead of inferring it from whatever the last model happened to say.

What SMALL is not

SMALL is not:

• an agent framework
• a workflow engine
• a prompt format
• a replacement for source control
• a substitute for human judgment

It does not try to be the entire runtime.

It is the protocol layer that makes runtime behavior legible.

That is an important difference. The point is not to centralize everything into one magical abstraction. The point is to establish stable boundaries so the rest of the stack can evolve without turning execution into guesswork.

What changes in practice

With SMALL in place, interruption stops being catastrophic.

A project can pause and resume without forcing the next actor to reverse-engineer intent from chats, comments, or partial tool traces. A new agent can enter the loop without pretending it has inherited perfect context. A human can audit what happened without reading an entire transcript.

That changes the day-to-day reality of delivery:

• plans are distinguishable from results
• constraints remain visible under pressure
• progress becomes append-only evidence instead of fuzzy status theater
• handoffs stop depending on memory
• resumes stop depending on luck

For teams building serious agent workflows, those are not nice-to-haves. They are the difference between repeatable execution and expensive drift.

Why release v1 now

Because the problem is already here.

People are already running critical work through language models, coding agents, automation layers, and mixed human-agent systems. The tooling is improving faster than the operational discipline around it.

v1 exists to put a stable floor under that work.

It does not solve everything. It is not trying to. It establishes the baseline invariants that serious execution needs first.

That is the right release shape: small enough to adopt, strict enough to matter, and durable enough to build on.

Start here

If you are new to SMALL, start with the spec and the reference workflow.

The fastest way to understand it is to look at the artifact set and see how the ownership boundaries work in practice. Once that clicks, the value becomes obvious: execution stops living inside vibes and starts living inside explicit state.

SMALL v1.0.0 is released.

Now the work is adoption, operational hardening, and integration into the execution surfaces that need a real contract instead of another layer of implicit context.