The Work Between AI Runs Is Still Work
Most AI tooling concentrates on what happens during a run. I keep coming back to what happens after it.
A run ends. The chat grows too long. A branch moves to another machine. Another agent picks up the task. Someone asks whether the tests actually passed, whether the plan changed, or whether "done" meant that the work was verified or merely that a command returned successfully.
That space between runs is where a surprising amount of real work gets lost.
SMALL began as a way to make that state explicit. Intent, constraints, plans, progress, and handoffs live with the project instead of disappearing into terminal history or a conversation nobody can reliably reconstruct.
Version 1.1.0 extends that model with the SMALL 2.0 session profile.
Solo should stay simple
The important decision was to keep solo work as the default.
Most projects do not need distributed coordination every time one person or one agent changes a file. Making collaboration the default would add ceremony before it added value. In SMALL 2.0, a workspace begins in solo mode. Collaboration is an explicit transition made when multiple writers actually need to contribute state.
That distinction is small on paper, but it keeps the normal path understandable. One writer can work without carrying the coordination model for a team that does not exist. When the work does spread across clones or operators, the project can change modes deliberately and record that decision in its own state.
Collaboration should be chosen
Once collaboration is enabled, each session has a durable identity. Events are immutable. Command results and acceptance evidence are recorded as different facts. Independent clones can reconcile their SMALL histories through deterministic union rather than taking turns rewriting a shared progress file.
This does not make source-code conflicts disappear. It does not provide distributed consensus. It does not decide which agent should run next.
Those boundaries matter because a state protocol should not quietly become an execution system. SMALL records what the work is, what happened, what was accepted, and what can be resumed. The system performing the work remains responsible for scheduling, retries, model selection, authorization, and integration of the source changes themselves.
Migration is a product decision
Existing SMALL 1.0 workspaces do not migrate automatically. The v1 artifact profile remains supported, and the v2 session profile is there when the work actually needs it.
Migration starts with a read-only preview. The resulting plan identifies the expected input state. Apply revalidates that state, preserves the original artifacts, validates the candidate workspace, and uses a recoverable transaction before replacing anything. If the inputs have changed since the preview, migration stops instead of guessing.
I wanted that process to be deliberately uneventful. A migration should explain the state it found, preserve the state it replaced, and make interruption recoverable. It should not treat a version change as permission to rewrite project history invisibly.
The release is the complete path
The implementation was only one part of this release. I tested the session model across two independent clones, ran the race-enabled Go suite and full repository verification, built all six platform archives, and checked every published checksum.
The npm package was published through trusted OIDC publishing with provenance. I then installed the release again through both npm and the public curl installer. Both paths returned the same result:
small v1.1.0
Supported spec versions: ["1.0.0","2.0.0"]
That outside-in check matters. A release is not complete because a source tag exists. It is complete when the public path still leads from the documentation to a verified binary that reports the version users were promised.
State should survive the run
SMALL v1.1.0 is not a claim that agent work is solved. It is a smaller and more practical claim: the state of the work can survive the run that created it.
That means a future operator does not have to trust a summary when the repository can carry the plan, evidence, acceptance boundary, and handoff itself. It means collaboration can be added when needed without making every solo task behave like a distributed system. It means migration is something the operator chooses and verifies rather than something a new binary silently performs.
The work between runs is still work. It deserves the same care as the execution in the middle.
SMALL v1.1.0 is available now:
Install it with:
npm i -g @small-protocol/small