System Record - SMALL Protocol - Execution State for Agent Work
How repeated failure modes in AI-assisted work became a released state protocol for legible, auditable, and resumable execution.
- Client
- Justyn Clark Network
- Year
- Service
- Protocol Design, Agent Governance, Execution Infrastructure
SMALL Protocol
Execution state that survives the session.
what should happen
what must not change
how work should move
what actually happened
where the next run resumes
Chat is the input. The `.small/` artifacts are the contract.
System Context
SMALL did not start as a branding exercise or a speculative AI wrapper. It came from a practical problem inside JCN: AI-assisted work could move quickly, but the surrounding state model could not always be trusted to survive the work.
Modern tools made it easy to start. They made it much harder to resume safely. Intent lived in chat. Constraints lived in memory. Progress arrived as a paragraph at the end of a run. Handoffs depended on whoever was writing the summary. When a session failed, restarted, or crossed into another tool, too much of the real execution state had to be reconstructed from context.
SMALL was built to remove that ambiguity.
SMALL makes agent-assisted work legible by moving the contract out of ephemeral chat and into explicit artifacts: intent, constraints, plan, progress, and handoff.
The Failure Mode
The issue was never that models were not impressive enough. The issue was that intelligent tools were operating inside systems that were too implicit.
Across JCN work, the same failures kept showing up:
- A run could claim progress without durable evidence.
- A resumed session could drift away from the actual prior state.
- A tool could bypass the intended command surface and leave no clean record.
- A plan could change without the audit trail changing with it.
- A handoff could sound confident while losing the details needed to continue safely.
Those failures are not cosmetic. They break trust. They make the operator spend energy figuring out what happened instead of deciding what should happen next.
Problem
Approach
Outcome
The Design Move
The important shift was simple: stop treating chat as the source of truth.
Chat can be an input method. It can be useful for direction, judgment, and review. But it should not be the canonical record of execution. SMALL moves the record into artifacts that can be read by a person, validated by a CLI, committed when appropriate, and handed to another run without relying on memory.
The core contract is intentionally small:
intent.small.ymlrecords what the human wants.constraints.small.ymlrecords what limits apply.plan.small.ymlrecords the proposed path.progress.small.ymlrecords what actually happened.handoff.small.ymlrecords the next safe resume point.
That split matters. Humans own intent and constraints. Agents propose plans, record progress, and generate handoffs. The CLI enforces structure so the system can reject invalid state instead of quietly carrying it forward.
Why It Was Ingenious
The strength of SMALL is not that it adds more AI. It adds less room for hidden behavior.
It names the part of the work that most agent systems still blur together: the difference between what was requested, what was allowed, what was planned, what happened, and what can safely happen next.
That is why the protocol feels more like infrastructure than a feature. Terraform works because state, intent, validation, and history are explicit. Git works because changes have a record. Reliable deployment systems work because boundaries are declared before execution. SMALL applies that same discipline to AI-assisted work.
The protocol is not trying to make agents smarter. It makes the system around the agent understandable enough for smarter agents to be useful without becoming ungovernable.
What Shipped
SMALL is not a June milestone. The v1 line has been public for months: v1.0.0 was tagged on January 14, 2026, and the public release trail has continued through v1.0.10. The system now includes:
- A canonical protocol model for intent, constraints, plan, progress, and handoff.
- A CLI for scaffolding, validating, checking, checkpointing, and generating handoff state.
small checkas the normal enforcement gate for validation, linting, and protocol verification.- Append-only progress conventions so reality does not get rewritten to match a stale plan.
- Workspace metadata to prevent accidental use of the wrong execution state.
- Public docs covering installation, first run, CLI usage, the agent operating contract, and the execution-model essay.
- Distribution surfaces through npm, curl installer, GitHub releases, and the docs site.
This is the difference between a note about a protocol and an operating surface people can actually try.
Evidence In The Wild
SMALL is also visible across the public JCN project surface. It is not only a standalone protocol site.
- smallprotocol.dev carries the public explanation, docs, install path, spec surface, and execution-model essay.
- The GitHub repository carries the released CLI, schemas, tags, and release history.
- The JCN release note explains why v1.0.0 exists and what problem it was built to solve.
- The human-agent workflow note explains the ownership split between human-defined intent and agent-recorded execution state.
- Loopexec is framed publicly as the bounded execution companion to SMALL: SMALL owns durable work state, while Loopexec owns the loop and machine-readable outcome.
- Musketeer v0.3.0 shows the protocol moving into another JCN project, with SMALL owning canonical workspace state and Musketeer owning trio execution artifacts.
The visible proof is also in public repositories that carry tracked .small/ artifacts on their
default branches:
- SMALL Protocol
.small/shows the protocol governing its own release work. - Loopexec
.small/shows the runtime companion using the state contract it is built around. - Thread-Based Engineering
.small/shows the same discipline inside a deterministic execution kernel. - Devports
.small/shows SMALL attached to public CLI tooling outside the protocol repo itself. - Wakeplane
.small/shows the pattern inside durable scheduling and automated execution work. - Boardroom
.small/, yt-transcript.small/, and pretext-chat-poc.small/show the state model appearing across agent coordination, media ingestion, and interface experiments.
That is the stronger proof point: SMALL is released, in use, and visible across the way JCN builds public tooling, not only in the way JCN describes the protocol.
How It Fits JCN
SMALL is the floor under the larger JCN story.
JCN is not a collection of unrelated projects. It is a system for turning accumulated workflows, judgment, media knowledge, business process, and engineering experience into tools that improve over time. That requires memory. It requires receipts. It requires private evaluation. It requires operators to know what happened without guessing.
SMALL gives that work a state model.
Loopexec can sit on top of it as a bounded execution companion. Agent workflows can use it to separate intent from action. Client operating surfaces can borrow the same bias toward evidence, handoff, and source-of-truth state. The point is not that every product becomes SMALL-branded. The point is that JCN systems inherit the same operating belief: work should survive the session.
Current State
SMALL is a released protocol and active JCN foundation. The public site, repository, release trail,
and adjacent JCN projects explain the protocol from multiple angles: why agents fail without an
execution model, how the .small/ state contract works, what agents are allowed to do, how a
developer can start using the CLI in a real project, and where the model is already appearing in
JCN's broader execution stack.
The next step for the JCN site is to tell that story with the same seriousness as the protocol itself. SMALL is not a short project blurb. It is one of the clearest examples of the JCN pattern: real operational pain turned into a named system, released publicly, and reused as infrastructure for the next layer of work.