Why the runtime is the part you own
A coding agent is a manifest, a harness, a model, and the state around them. Owning the runtime means those four live in one root you can read, lock, and delete. It does not mean the model is yours, the output is correct, or the agent is sandboxed.
One manifest, one root
A manifest is a declarative outerloop.yaml plus a versioned AGENT.md. The manifest names the task, the model, the harness, and the host. The root holds the pinned host, the harness copy the runtime provisions, the model rows, and the run state. Every file opens in a text editor.
The root is one directory you choose. The installer uses a default under your home directory; a project root or an absolute path is a flag away. There is no system package to remove, no global harness config to undo, and no second directory the tool writes to without telling you.
A stack has a package manager, a service, a config directory, and a cache, each with its own removal instructions. One root has one removal instruction, and the installer names each path it writes.
- One config describes the run; the same config works with a different model row.
- The harness runs from the root. oloop does not fall back to a harness already on your PATH.
- Starting and opening a host write no user-global config.
- The model rows stay under the root, so a second project cannot quietly reuse a stale endpoint.
The lock is the identity
oloop.lock records what the manifest resolved to: the host, the harness, the model revision, and the digest of the bundle that was applied. An exact lock is what makes a run repeatable. An adaptive manifest may resolve newer pins, and the plan says when it did.
The lock does not promise the upstream model still exists. It records the identity this root used, so a later run can say whether it is the same identity or a different one. It is plain text, and a diff shows which pin changed between two runs.
What each artifact settles
Six files carry the facts a reviewer asks for. None of them is a security review, and none of them means the runtime was audited.
| Artifact | Where it lives | The question it settles |
|---|---|---|
| outerloop.yaml | The project directory | Which task, model, harness, and host the run names. |
| AGENT.md | The project directory | What the agent was told to do, versioned with the manifest. |
| oloop.lock | Next to the manifest | Which host, harness, and model revision the resolve used. |
| Bundle checksum | The lock and the catalog | Whether the bytes applied are the bytes published. |
| Evidence JSON | The catalog | What one qualification run measured, on which hardware, on what date. |
| Run receipt | The project and the Hub | How the run ended, and whether the result was submitted. |
A checksum settles identity. The evidence settles what one probe did. Neither says whether an answer is correct, and a run receipt that was never submitted is still a receipt.
Local and cloud-you-own are the same claim
When you own and manage the runtime, a machine under your desk and a box you rent are the same arrangement: one manifest, one root, one lock, one removal. The difference is who owns the hardware and who can read the disk, and the runtime contract does not change.
A hosted model API is a different arrangement. You do not own the runtime, the model identity may move without a lock you can inspect, and each request leaves the boundary you control. That can be the right trade. Calling both arrangements local hides that difference.
Removal is a directory
oloop remove stops the host processes it started and deletes the host state it owns. The root is the unit. To do it by hand, rm -rf <root> is the last step, and there is no package database to reconcile afterwards.
A runtime that scatters state across a home directory, a system service, and a package manager cannot make that promise, because no single command knows every place it wrote.
What this does not claim
It is not a sandbox. The agent can touch what the manifest's tools allow, and the harness runs with your user's permissions unless you change them.
It is not a hosted service, a compliance certification, or legal advice. The model license belongs to the model publisher, and a passing check does not make an answer correct.
Install
Install the CLI, then pick the setup for your machine class.
curl -fsSL https://oloop.run/install.sh | shQuestions
Is this the same as running a model locally?
No. A model is one part. The runtime also owns the harness, the pins, the lock, the evidence, and the root. A model server without those gives you inference and nothing to inspect.
Does oloop send my prompts anywhere?
The CLI sends a machine profile and usage events by default, and the privacy page lists both. A model endpoint you choose sees what you send it. A local host keeps the inference on the machine.
What does a checksum prove?
That the bytes you applied are the bytes with that digest. It does not prove the contents are safe or correct.
Can I move the root?
The root is a path you choose at install or start. Moving it means moving one directory and pointing the next command at it; the lock and evidence travel with it.