00intake
Most sites tell you what their agent does. This one walks you through the machine while it works. stella is a terminal coding agent — fast, BYOK, model-agnostic — and it refuses to call work done until the work is proven. Walk the engine and watch a goal become verified work.
$ stella run "make the flaky scheduler test deterministic"
goal received — engine turning
01the turn loop
At the heart of the engine is a single-threaded step loop: the model proposes tool calls, the tools execute — independent reads fan out in parallel — the results feed back, and the loop repeats until the work is done. That is the entire trick. Everything else on this tour is structure built on top of it.
model proposes
tools execute
results feed back
guardscompact · budget · loop-detect
pure decision coreno network · no filesystem · no clock
Compaction, eviction, budget arithmetic, loop detection, retry, skill selection — every decision the engine makes is a synchronous function over owned data. No I/O can happen inside the core, so the loop is property-tested, replayable, and deterministic enough to prove things about.
The budget guard is consulted between model calls and never interrupts a tool in flight — a run stops at a seam, not mid-motion. When the conversation gets noisy, the engine compacts it and keeps going.
on stella run, the loop rides a staged pipeline —
dashed stages are conditional: a task that does not need them skips them — they are never performed for show. the full pipeline, staged
{"type":"step_manifest","turn":4,"step":2,"planned_tools":3} {"type":"tool_start","tool":"task_list","call_seq":0} {"type":"tool_start","tool":"get_state","call_seq":0} {"type":"tool_result","tool":"task_list","status":"ok"} {"type":"tool_result","tool":"get_state","status":"ok"} {"type":"step_receipt","turn":4,"step":2,"outcome":"continue"} {"type":"step_usage","role":"worker","tokens_in":18204,"cached":17651}
02the tool bay
A parameter may scope an operation — a path, a key, an offset. It may never select one. A tool that can both edit and delete is two tools wearing one schema, so stella splits it: the model learns each verb properly, and policy can withhold the destructive verb without withholding the benign one.
your external tool servers merge into the same registry, behind the same per-tool permissions — a guest tool follows house rules.
readmutating — every tool declares which it is, honestly: the engine's concurrency contract depends on it. This is the whole built-in registry; everything else docks via MCP or a custom manifest. The full toolbelt and its permissions.
03the verification chamberdeterministic
Every other agent ends a task when the model says it is finished. That is the whole problem: the thing that did the work is also the thing grading it. vera is the deterministic verifier at the back of the engine, and she never asks a model anything. She runs commands and reads what happened.
the flip oracle
One command, locked by name, run on both sides. A suite that was already green proves nothing — only the fail→pass flip proves the change did the work. The oracle is a state machine: it locks onto the first command it sees fail, and only a later pass of that same command moves it to flipped. The "it passed, ship it" false positive is structurally excluded.
With no test command configured, an independent model — never the worker — authors a minimal failing test, working from a pristine snapshot of the pre-change tree, blind to the diff, so it cannot write a test that merely restates the patch. It gets exactly three tools. Every other tool name returns an error.
The witness file's full filesystem identity is pinned where it was written and re-pinned inside the candidate. A worker that edits the witness does not get credit for passing it.
It encodes a moment — "this code doesn't do X yet" — not an invariant, so it lives and dies with the candidate workspace. You never inherit an already-satisfied test nobody reviewed. --keep-witness promotes it if it is worth keeping.
The ladder is arithmetic over measurements. Every rung is terminal, no reviewer is consulted, and the verdict is emitted from the answer directly.
five outcomes. every one of them terminal —
1revise
Touched tests are red. That is already a deterministic failure — the evidence goes straight back into a revision turn. Nothing is spent confirming a failure nobody doubts.
2nothing attempted
The turn dispatched no call capable of changing the workspace, and nothing that could look saw a change. The one place an absence is read as evidence.
3unverifiable
Every channel was blind — no flip, no test result, an unreadable tree. vera abstains. Nothing is claimed about the work, in particular not that it failed.
4submit fast
Flip achieved, touched tests green, diff within budget, no fresh diagnostics. The full deterministic pass — the only rung that means proven.
5unverified
The probes looked, and what came back did not amount to a proof. vera's honest I do not know — stated, not dressed up as a pass.
The last rung used to ask a second model for PASS or FAIL. Over an 89-task Terminal-Bench run, that verdict agreed with the benchmark's grader 46% of the time — a coin flip — and 17 of its false passes cost 5 tasks outright. So it was removed structurally, not defaulted off.
{"type":"witness_authored","by":"witness-author","tamper_watch":true} {"type":"probe","command":"cargo test -p scheduler","phase":"pre","result":"FAIL"} {"type":"probe","command":"cargo test -p scheduler","phase":"post","result":"PASS"} {"type":"flip_oracle","state":"flipped","locked_command":"cargo test -p scheduler"} {"type":"diff_budget","changed_lines":38,"limit":400,"within":true} {"type":"verdict","rung":"SubmitFast","model_calls_spent":0}
04the governance plane
An agent that behaves differently on every laptop is not governed, it is merely configured. The governance plane makes steering policy a reviewable artifact: records that live in the repository, travel with a clone, and are validated in CI on every pull request — so a teammate's session obeys the same rules yours does, because it read the same file.
.stella/rules/*.toml
One record per file, tracked in git — the only part of .stella/ that is. A record only steers a teammate's session if it travels with the repository, so it is committed like code and reviewed like code.
.stella/governance.toml
How much authority a record may hold. This repository runs regulated — enforcement is a grant, not a default, and a record earns it through promotion rather than by existing.
.stella/promotions.jsonl
Every enforcement grant, retirement, and supersession, chained so the history cannot be quietly rewritten. stella context validate re-verifies the records and the chain in CI on every pull request.
Community stella sends telemetry nowhere. Your prompts, paths, tool payloads, reasoning, errors, git state, memories, and rules are never exportable — not off by default, not exportable. There is no update check and no anonymous analytics. Model-provider traffic is the normal network exception you chose when you brought your own key.
The one addition is an explicitly enrolled Oxagen Enterprise managed mode: a signed org-managed document may authorize a minimal content-free operational rollup to one exact allowlisted HTTPS sink.
enforced, not assumedA reviewed allowlist of exportable columns plus a sentinel harness every egress encoder registers with. Adding a field fails the build until the allowlist is edited in the same change — so a human has to answer "is this content?" before it can ship. A leak here is a privacy incident, not a bug.
05the evolution deckpaid tier
Most of what gets called agent self-improvement is recall: a note file the agent writes and reads back. Useful — and not the same thing as getting better. Each engine on this deck changes what stella can do, and each one is gated on a measured lift against data it did not train on.
your team's recurring wins become reusable procedures
Every turn is reflected on and mined. A lesson that keeps recurring is promoted into a Skill — a parameterized procedure, not a recalled fact — and injected as volatile context when it is selected. Mining ships today; what is still in design is the evaluation run that promotes on measured lift instead of on recurrence.
the engine builds the tool it keeps wishing it had
When stella reconstructs the same shell incantation for the third time, the capability-gap detector notices. The foundry authors a typed tool, proves it with a witness test, and files it for adoption. A proposed tool is inert until it is both adopted and enabled — new capability lands disabled, behind the same authority gate as any other.
frontier-quality work on a model your team's traces taught
Accepted, verified turns export as one JSONL record each, every string through the secret redactor, owner-only, with a manifest describing the filter that selected them. The frontier item is what comes next: train and evaluate open-weight adapters on that corpus offline, and — gated by eval and human sign-off — promote one that measurably improves behavior. The economics are the point: inference on a model you own is inference you are not renting.
the conditions under which any of it is allowed to ship —
What this deck is, today. The chips above are accurate as of this writing: some of this ships, some of it is a design under active discussion in the open issue tracker, and the details will change. We would rather you read a status chip than discover the gap after you paid. the full track, component by component
06the exit
One binary, one API key you already have. No account, no sign-up, nothing proxied. The engine you just walked through is the one that installs.
$ curl -fsSL https://stella.oxagen.sh/install.sh | shstella is open source and built in the open by @macanderson. Every mechanism on this tour is documented in full, including the parts that are still a design — start with the pipeline.