THE THESIS
Sovereign Machine Agency
Machine agency is not a property of a model. It is a property of the system built around it.
I · THE STORY
Every era of computing has settled the same question: who holds the power.
The personal computer put it in your hands. The network took it back. Machine intelligence asks the question a third time, and the stakes are higher, because what is being centralized now is not storage or compute. It is judgment.
By default, these systems are built for the operator running them, not the person using them. Your context lives on their infrastructure. Your judgment compounds into their product. The record of what happened is whatever they show you. Your protection is a promise in a document they can revise.
When revenue is measured in tokens, no one upstream of you profits when your work costs less.
The answer is not a better promise. It is a different architecture.
II · THE VISION
A world where sovereignty is ordinary.
What you accumulate is yours.
The corrections, the procedures, the context that makes a system useful in your particular work compound into an asset you own.
You can actually leave.
Not an export folder stripped of the meaning that made it useful. The state and the authority, lifted and resumed elsewhere.
You can see everything.
Not because you asked the system to explain itself. Because it could not have run without producing the record.
The model is a choice, not a fate.
A frontier API today, open weights tomorrow, something small on your own hardware for the work that must never leave the building.
Efficiency is a design goal.
Work costs what the computation costs, not what a business model requires it to cost.
III · THE THESIS
Sovereign Machine Agency is machine intelligence that acts with real capability while the user remains the principal.
A model supplies inference. The system supplies memory, authority, execution, and the record. The system decides whether a suggestion becomes an action, whether the work survives, and who owns what accumulates.
If agency lives in the model, sovereignty waits on the goodwill of whoever trained it. If agency lives in the system, sovereignty is an engineering problem.
The principal is the one whose authority the system acts under, who holds its state, and whose direction prevails when it diverges from the operator's.
FOUR PROPERTIES
Authority
The system acts only inside a boundary you declare. Outside it, nothing runs.
FOR THE TECHNICAL READER →FOR THE TECHNICAL READER ↓
Execution is scoped before it begins. A request outside the declared scope, or missing what it needs, is rejected before anything runs and the caller is asked to correct it. This is validation and scope, not a claim of universal safety: code that passes every check can still be wrong, and access you grant outside the system changes what it can reach.
Observability
Every step is recorded, because execution cannot proceed without producing the record.
FOR THE TECHNICAL READER →FOR THE TECHNICAL READER ↓
Work runs in stages, and each stage records its inputs and its decision as it happens. A failure can be traced to the stage where it occurred and reproduced. This is a record of execution, not a reasoning trace written after the fact.
Portability
State and authority lift and resume elsewhere, under another provider, without the incumbent's cooperation.
FOR THE TECHNICAL READER →FOR THE TECHNICAL READER ↓
Authoritative state, your worlds, your policies, your history, is held outside any model session in versioned form. The same system runs on a small local model or a frontier API without changing shape. Full continuation under a different provider is what the architecture is built for, and we will show it in stages rather than assert it.
Efficiency
Work costs what the computation costs: many small, checked steps instead of one expensive call.
FOR THE TECHNICAL READER →FOR THE TECHNICAL READER ↓
Work is decomposed into bounded steps, each simple enough for an inexpensive model, with deterministic checks between them. The bet is that this substitutes for expensive model capability on a growing class of work. Early internal results on Python editing support the direction. Numbers arrive as dated outputs with their test suite named, never as a headline.
Observability is not monitoring. It is the mechanism.
The industry prices these four against each other: observability costs performance, portability costs integration depth, authority costs capability. That is an artifact of building on top of a model instead of around one. When each step is visible, you can tell which steps need a model and which ordinary code can do reliably, and every step moved to code is work the model no longer has to do. The boundary is visible, so authority can be enforced at it. State has explicit structure, so it can leave. Efficiency follows.
FOR THE TECHNICAL READER →FOR THE TECHNICAL READER ↓
Put another way, observability is a mechanism for extracting entropy from the model. A stage whose inputs and decision are recorded can be checked deterministically or replaced by deterministic code, so the model's uncertainty is confined to the stages that still need it. Visibility makes that engineering possible. It does not by itself establish correctness, authority, or portability. Each of those is a separate claim, tested separately.
IV · OUTPUTS
Everything we have published or shipped, and the property each is evidence for.
- 001Model Encryption ProtocolPROTOCOLRun a model on hardware you do not trust, with its weights encrypted and the key in your hands. Early research, with known gaps.PORTABILITYPUBLISHED
- 002Own Your Models, Own Your MindMANIFESTOThe argument before the architecture: rent your intelligence, or own it.THESISPUBLISHED
- 003ConduitFRAMEWORKTyped calls into any model, open source. The same system runs on a local model or a frontier API without changing shape.PORTABILITYEFFICIENCYPUBLISHED
- 004ProofVMRUNTIMEA runtime for coding agents that validates each Python change before it lands. Results land here dated, with their test suite named.AUTHORITYOBSERVABILITYEFFICIENCYIN PROGRESS