QLoop

Govern the model's own native loop turn by turn, and witness every turn on a tamper-evident chain.

Overview

Most "autonomous agent" products reimplement the loop: they wrap a model in their own planner, their own tool dispatch, their own retry logic, and inherit every bug in that reimplementation.

QLoop does not. It hands an Objective to the model's own native loop (claude -p, codex exec) running on a governed fleet dev server, and governs that loop from outside: what tools it may touch, what it must pause for, and what happens when a human says stop. Every turn is witnessed as it happens.

The claim that matters: you can replay what the loop believed at any moment, because each turn was hashed into a chain at the time it occurred, not reconstructed from logs afterwards.

Witnessed turns

Each turn is hashed into a WARD chain carrying its sequence number and a content hash, linked to its predecessor. A 19-turn run landed all 19 entries on an intact chain, each recomputed and verified against its predecessor.

This is what separates a receipt from a log. A log is a claim about what happened. A chain is evidence, because altering any turn breaks every link after it.

Deny-by-default scope

The loop may use only the tools you named. Not "should not", not "is instructed not to": the dispatch carries the tool scope and anything outside it is refused at the boundary, so a persuasive prompt cannot widen the loop's reach.

Gates and halting

Live gates pause the loop on budget or interval. A pending gate waits for a human in the approval queue:

bash

quox objective checkpoints
quox objective approve-checkpoint <objectiveId> <checkpointId>
quox objective deny-checkpoint <objectiveId> <checkpointId>

And when you want it stopped now, with no pending gate to respond to:

bash

quox objective halt <objectiveId>

halt fires the same signed kill as a gate denial. The distinction from a status flag is the whole point: a flag asks the loop to notice it should stop, which a wedged or busy process may never do. A signed kill ends the process.

Running one

bash

quox objective create "<goal>" --execution-mode loop
quox objective list
quox objective get <id>

Note the flag. quox objective create defaults to a DAG plan, not a loop. --execution-mode loop is what makes it a QLoop run.

Verifying a chain yourself

Witnessing is only worth something if you can check it without trusting us. Two commands:

bash

quox volt fetch <runId>              # download the run's evidence bundle
quox volt verify <runId>-bundle.json # check the hash chain

A good bundle reports the chain as PASS with its event count, any signatures and any RFC 3161 timestamps. Alter a single stored event and verification fails, naming the sequence number and both hashes:

RESULT: FAIL
  [EVENT_HASH_MISMATCH] Hash mismatch at seq 1:
    computed 02041b2dad84f941..., stored f2ed6efd762cb9cc...

That failing case is the half that matters. A verifier which only ever passes proves nothing.

Find run ids with quox governance cert list, and the underlying evidence records with quox governance evidence.

Honest note: quox volt fetch was added on 2026-08-19. Before that the verify command existed but accepted only a local file, and nothing in the CLI could produce one from a running instance, so this chain could not be completed by a customer at all.

Limits and honest status

2 concurrent loops per org, 200 turns maximum per loop, on the paid tier. The free tier has zero loops.
Requires a dev server. QLoop runs on a fleet host holding the right dev-mode capability. It is not a hosted sandbox, and there is no cloud runner.
The chain witnesses turns, not correctness. An intact chain proves the sequence of turns is unaltered. It does not prove the loop did the right thing, and nothing here claims it does.
Replay reconstructs belief, not the world. You can see what the loop had in front of it at turn N. External state it acted on is not snapshotted.

For the current per-surface maturity map, see STATUS_AND_LIMITS_DEVSUITE.md in the dashboard repo.