Perslis shells · Kist
Kist: the loop shell.
A goal goes in. What comes out has been checked. Kist plans, acts through real tools, verifies the result, and goes round again until the work is proven or a cap stops it.
Kist is the engine Perslis is built on. It is not a language model. It is the loop around one: the language model supplies the reasoning, and Kist supplies the tools, the memory, the checks and the rules for what counts as done. It works with whatever model you point it at, a cloud model on your own key or a local model on your own hardware. The shell, the safety gate and the verification machinery ship as one checksum-verified binary.
The rules it runs by
Kist is a shell, not a model: it holds a language model to a fixed set of rules that decide what a result has to survive before it counts. There are four:
- Done means verified. Every cycle ends in a check. A result that has not passed one is not reported as finished.
- Failure feeds the plan. A step that fails is repaired and retried, or the plan is rebuilt around it. The run does not end at the first error, and it does not paper over one.
- The irreversible waits. Every action is classed by whether it can be undone. One that cannot waits for approval, both when it first launches and again if a repaired version is retried.
- No single model is trusted alone. High-stakes work goes before a council of models from different labs before Kist calls it done.
The loop, one turn at a time
- Size the goal. Kist estimates how much effort the goal needs before spending on it.
- Plan. The goal becomes ordered steps, each doing one thing, with the dependencies between them explicit. Steps that do not depend on each other run side by side.
- Act. Each step runs through real tools: files, shells, services and legacy systems.
- Verify. The result is checked against the goal, by running it where it can be run.
- Replan. Whatever failed or turned out differently goes back into the plan.
- Learn. Kist reads its own run history, so the next plan starts from what the last one found.
- Stop. The loop ends when the work is verified, or when a budget, time or cycle cap is reached. A cap is reported as a cap, not as success.
The same loop, seen from the product
From the outside, the loop has eight stages: research, plan, analyze, decide, build, test, deploy and connect. You make the calls an architect makes. Kist does the research, the building and the proving, and nothing is called done until it is verified.
The council of models
Before Kist trusts an important result, it puts it in front of more than one model. A builder drafts. Reviewers from different labs critique, so their blind spots do not overlap. An adversary tries to break the result, and the strongest available model signs off. Disagreement between models is treated as signal, because that is where real errors surface.
Who sits on the council, and why →
Where it runs
Kist runs the same loop against a cloud frontier model or entirely offline. For sensitive work it drops into AirTight mode, where building, review and records stay local. For regulated work it applies the citation-and-verification discipline of the legal loop. Kist never resells inference: you point it at accounts you already have, or at models on your own hardware.
What it is not
Kist does not make a model smarter. It makes a model's work checkable. Its guarantees reach only as far as its checks: a result can be verified only against what a test, a run or a reviewer can actually observe. Where no check exists, the honest output is that the work is unverified, and Kist says so.
Read further
- The white paper: the loop, the symbolic guardrails and model-agnostic orchestration, proven from the binary.
- The Orchestration Gap: why model-level alignment cannot survive multi-model runtimes.
- Verified Before Acting: a pre-action adversarial loop with factored authorization.
- Retrieval Is Not Memory: memory as a governance function over experience.