Done is a verdict, not a claim.
Quidoris builds with autonomous agents. This is the system that runs them: it decides which seat may take a piece of work, meters what that seat spends, and then refuses to call the result finished until a composed verifier passes it. Production and judgment are one system, and a run that fails is recorded on the same terms as one that passes.
It runs your toolchain. Any toolchain. Compilers, test runners, package managers, browser drivers, database clients: it executes what your application declares, and rules on what comes back.
What the system is made of.
The parts are few, and each one is a control that leaves a record. They are described here as controls rather than as files, because the question a reader is actually asking is what stops the wrong thing from happening.
- The gate
A composed verifier that decides whether work is finished. Any command that can fail is a stage. The gate runs them in order and rules on what they return.
- The evidence bundle
The durable artifact of a run: every stage with what it proved and what it could not, the assumptions the run made, the regions it left untested, the risk it knowingly carries, and the verdict.
- The permission ladder
What an automated agent may do unattended, sorted by what cannot be undone rather than by how hard it is.
- The approval ledger
Irreversible change takes a human decision, written under a credential held separately from the one the agents connect as. The agent role carries no privilege on the ledger: not read, not write, not grant.
- The change contract
An edit to the system's own governing instructions declares its scope. The check compares that declaration against the diff and fails on any tracked file outside it.
- The divergence check
What the system claims it has built, read back against what its store actually holds. Disagreement is a defect on the board, not something reconciled quietly.
- The fleet
Automated seats matched to work by cost and capability. The seat that checks the work is never weaker than the seat that produced it.
- The record
Every run writes its bundle, failures included. Persistence to the shared store is attempted every time, and a miss is reported in the run's own output rather than swallowed.
Five steps, and the last one is not optional.
The system builds. Autonomous seats do the work, and it moves through the same five steps: specified before a seat is chosen, checked against the running system rather than against its own report, attacked by something other than whatever produced it, and only then put to the verifier. Review is batched to the point where work ships rather than run after every edit, and mechanical work already green on a deterministic check goes straight to the gate. The gate is the step nothing skips — so by the time it rules, the verdict is the last question left rather than the only one ever asked.
- Contract
The work is specified before a seat is chosen: what changes, which files it may touch, and, wherever the work admits one, a definition of done that is executed rather than read. Work that cannot be given a runnable definition of done is not refused. It is routed to adversarial review instead, on the reasoning that unverifiable work is the last thing that should travel unattended.
- Admission
The seat is matched to the work by what the work is, and its model pin is checked mechanically before it runs rather than after it has spent. A dispatch pinning neither a known seat nor an approved tier is refused outright — an unpinned dispatch silently inheriting whatever the session was already running is the specific leak that check was built to close.
- Build
The work is done, then checked against the system that will actually serve it — the running service, the live store, the object cache. Not against documentation, and never against the agent's own account of what it just did.
- Review
Review is a separate dispatch, not a self-assessment: the seat that produced the work does not certify it. The reviewing seat is instructed to refute rather than confirm, and it does not apply its own findings — it returns them, and someone else decides what to do with them.
- Gate
The composed verifier runs last and rules on the result. A non-zero verdict forbids three things at once: calling the work done, committing it, and deploying it. A run that merely executed earns nothing.
Which seats exist, and what each one is permitted to attempt unattended, is the governance question rather than the engineering one: it is answered on QRG Governance System, and stated once so the two pages cannot drift apart.
One core. Any toolchain.
We run it across fourteen software languages, every commercial operating system, and more than 120 operating-system sidecars. It integrates with every frontier model, connects to any MCP server, any database system, and every inference engine published on Hugging Face. From robotics software to every tool PRISM reaches: we will build it, test it, and deliver it to your production stack.
- Languages
Fourteen
- Operating systems
Every commercial OS
- OS sidecars
120 and counting
- Models
Every frontier model
- Tooling protocol
Any MCP server
- Data
Any database system
- Inference
Every engine on Hugging Face
What it drives here, through one contract.
- Compiler
Builds the module and fails the run on the first error.
- Test runner
Executes the unit suite; cases needing a credential self-skip and are recorded as skips.
- Package manager
Resolves a locked environment and runs a curated hermetic suite inside it.
- Browser driver
Drives a real browser and reads pixels back off the canvas, reproducing the defect before the fix.
- Database client
Opens a read-only transaction and checks lineage completeness. Absent a connection it records a skip with the reason.
Five kinds of tool, one repository, one record. The core carries no reference to any of them: a stage is any command that can fail, described by what it proves and what it cannot. Onboarding an application is a manifest file naming its gate, its capability matrix and its store. Not a port, and not a fork.
Five stages, and what each one cannot see.
The gate is a composed verifier, not a checklist. It runs in order and writes an evidence bundle recording, for every stage, what it proved and what it had no power to prove. The second column is the one worth reading. Below is one real run of one application's gate; another application's stages would be entirely different commands recorded in exactly this shape.
- compilepassexit 0
Every package in the application compiles.
Cannot prove Runtime behaviour, logical correctness, or whether the binaries do the right thing.
- unit_testspassexit 0
Unit tests for database-free packages pass. Tests that need a live connection string self-skip rather than fail.
Cannot prove Behaviour of the database-gated paths against a live store, and packages that ship no tests at all.
- hermetic_worker_testspassall passed
The curated credential-free subset of the compute worker's tests passes with every secret unset: value sanity, hashing, physics guards, slope consistency, render ladder, provenance, point-spread compactness, black-hole to host ratio, population bundle, broad stack.
Cannot prove Anything needing network or credentials, the rest of the suite, and the scientific plausibility of the numbers it computed.
- value_sanityskipno value record supplied; a skip is not a pass
A supplied measurement record is structurally sound: provenance present, values finite, resolving power positive or explicitly null, minimum not above maximum.
Cannot prove That the values are scientifically correct or physically plausible. Only that the record is well formed.
- provenance_completenesspass0 orphan rows, read-only
Every derived value in the science database carries a hash that joins a succeeded job with a non-null output. Lineage is unbroken.
Cannot prove That the job producing it computed the right answer. Only that the link exists.
One stage fails and the whole gate fails. So does a stage whose output the gate cannot parse. A stage skipped for a missing input is recorded as a skip with its reason attached, and a skip is never counted as a pass.
Fail-closed is the whole design. A verifier that degrades to a pass when it cannot tell is worse than no verifier, because it manufactures confidence.
Metered everywhere. Capped in one place.
Autonomous work spends money whether or not anyone is watching it, so every dispatch and every turn is metered against a weighted token count rather than against a wall-clock guess. Exactly one of those meters is allowed to refuse a dispatch. The rest observe and report, and the second column below says so plainly, because a page that presented five controls where the system has one would be committing the inflation this system was built to catch.
- Spend is weighted, not just counted
A run's cost is recorded as a weighted token count alongside the raw one, because the four kinds of token are not priced alike: written output is weighted at five times an input token, a cache write a quarter above one, and a cache read at a tenth. The weighted figure is the quantity the bill is actually a function of.
Where it stops The weighting is a model of a price list, not the price list, and it is never presented as an invoice. Where a dispatch returns no breakdown of its token kinds, the weighted figure falls back to the raw total and is flagged approximate rather than being estimated into something that looks precise.
- One control can refuse to spend
The premium reviewing seat carries a hard daily ceiling, fixed as a percentage of its weekly allowance. Once the day's weighted spend reaches it, the next dispatch of that seat is denied before it runs. The operator then defers the work or raises the ceiling deliberately, in a file, under their own name.
Where it stops It bounds one seat. The remaining seats are metered and reported but not capped, so a runaway loop on those tiers is visible in the ledger rather than stopped by it.
- Every other meter observes and never intervenes
Usage is recorded after each dispatch and after each turn of the orchestrator. Each writes its ledger line and then exits successfully by construction — including on the path where it failed to record anything at all.
Where it stops A meter that cannot stop a dispatch is not a control, and calling it one would be the exact inflation this system exists to refuse. These make spend auditable after the fact. Nothing in this row prevents anything.
- Cost attaches to a dispatch, not to a verified change
The ledger records what each seat spent and when, aggregated by day, by seat and by model, and reported against the ceiling on demand.
Where it stops There is no join between a gate run and its cost. Answering what one verified change cost means matching timestamps by hand. That is a gap in the record, and it is stated here rather than rounded off.
- Resumed work spends off the ledger
A seat is metered per dispatch, with the usage line written when that dispatch returns. A seat resumed in place, rather than dispatched afresh, matches neither meter, so its spend goes missing from the ledger rather than wrong in it.
Where it stops Missing is not zero, and the totals should be read as a floor. The first dispatch is still admitted through the same check; the residual is carried knowingly rather than quietly netted away.
What the gate is not allowed to decide.
Scientific plausibility
The gate checks that a measurement is structurally sound and that its lineage is unbroken. Whether the number is physically sensible is a scientific judgment, and it is not delegated to a script.
Visual correctness
Rendering is proved separately, by driving a real browser and reading pixels back off the canvas. Those proofs must reproduce the failure before the fix and pass after it.
The final say
A green gate means no verifier could find a defect. It does not mean the work is good. Sign-off stays with a person, and the build system exists to make that person's attention worth spending.
The open problems, closed in production.
A 2026 survey of agent harnesses (Code as Agent Harness, arXiv:2605.18747) maps the field and closes, as surveys do, with what remains unsolved. Three items on that list decide whether anything an automated agent builds can be trusted: evaluation beyond final task success, verification under incomplete feedback, and human oversight for safety-critical actions.
They are the three parts of this system that were built first. Evaluation beyond final task success is the evidence bundle: a run is judged by what it proved, what it could not, what it assumed and what it left untested, not by whether it terminated. Verification under incomplete feedback is the rule that a skip is never a pass, and that a stage whose output cannot be read fails the whole gate. Human oversight for safety-critical actions is the ledger.
The survey lists them as directions for future work. Here they are implemented and running in production, under an astrophysics platform and a clinical decision system.
Kept either way, failures included.
Every run writes a bundle: schema, commit, timestamp, each stage with its own limits, the assumptions the run made, the ground it did not cover, the residual risk it is knowingly carrying, and the verdict. Gate runs, build state, drift, telemetry and approvals go to a shared store the agents write and the operator reads. The write is attempted every time; a miss is reported in that run's own output, and the verdict never depends on it having succeeded.
Patent pending, U.S. and international.