Concepts

QLoop

QLoop is an Objective run in loop mode. Instead of decomposing the goal into a reviewable DAG of tasks up front, it hands the goal to a model’s own native agentic loop (claude -p / codex exec) on a server you govern, turn by turn. It is the highest-stakes capability in the dev suite, so every moment of it is gated, scoped, or witnessed.

For the pitch, see the QLoop page. This page is the technical definition and the honest maturity map.

The five moments

1. Spawned

You create an Objective with execution_mode=loop. Loop mode always requires a pre-start human approval, so the objective waits. On approval, the collector mints a session and an ingest token, an oracle signs the job envelope, and it is delivered through the bastion to the quoxagent on a governed fleet dev server, which starts the model’s own loop.

2. Scoped

The loop can only call the tools named in its capability_scope. It is deny-by-default: an empty scope escalates every tool, and reaching for anything outside the scope is interrupted and witnessed. For Claude the scope compiles to genuine pre-flight --allowedTools enforcement; for Codex it maps to the sandbox plus the per-session MCP grants.

3. Witnessed

Each turn streams back to the collector, which wraps it in a quox.dev.loop.turn AEE envelope carrying the turn sequence and a SHA-256 of the raw turn, and lands it on a WARD hash chain. Tampering with a stored turn breaks chain verification.

4. Governed live

While it runs, budget and interval gates can raise a checkpoint you approve or deny (a risk gate is built behind them, not yet driven live), and you can halt the loop unconditionally at any time. A halt or deny fires a signed structured-kill that ends the process on the fleet host; the reason is witnessed.

5. Remembered

A finished loop is not discarded: its outcome is recorded and reflected on through the same QuoxMind path every governed objective uses, and a scoped loop can author a skill through the governed skill chokepoint (see self-extension below).

Running one

Loop objectives are created and governed through the canonical CLI. Loop mode always forces a before-start approval.

quox objective create "your goal" \
  --execution-mode loop --loop-backend claude \
  --capability-scope "Read,Grep,Glob,mcp__quox__skill_manage" \
  --max-iterations 6

quox objective start <id>                     # returns a checkpoint
quox objective approve-checkpoint <id> <cid>  # the pre-start gate

# while it runs:
quox objective checkpoints                    # pending gates across the org
quox objective approve-checkpoint <id> <cid>  # let a gate carry on
quox objective deny-checkpoint <id> <cid>     # stop it at a gate
quox objective halt <id>                       # stop it NOW, no gate needed

The scope is a fail-closed allowlist authored once in Claude vocabulary and translated per backend. A halt or a gate deny fires a signed kill that ends the process on the fleet host, freezes the turn stream, fails the objective, and writes the reason to the evidence chain.

The evidence model

Every loop turn is an AEE envelope (quox.dev.loop.turn) carrying the turn sequence and a SHA-256 of the raw turn, witnessed on a WARD hash chain. The lifecycle events (spawn, interrupt) and the AOCL classification and VOLT run ride the same substrate. The chain is verifiable: recomputing each entry’s hash and checking each link detects any tampering with a stored turn.

Self-extension

A loop scoped to the QSKL tools can author a real skill mid-run by calling mcp__quox__skill_manage. It enters the same governed pipeline a human skill does: a firewall pre-persist scan, a weekly LLM safety judge, and crystallisation at three or more runs at eighty percent success. A loop-authored skill is tagged self-authored and carries its loop session. Proven on both backends.

Honest maturity

We would rather you trust the green than be sold the grey. This traces to our internal status tracker for the surface.

Solid: proven on the fleet

The native loop on a governed, signed-capability fleet host, on both Claude and Codex through one seam
Per-turn WARD witnessing on a tamper-evident chain (proven: 19 of 19 turns on an intact chain)
Deny-by-default scope, the pre-start approval, and live budget / interval / approve gates
A signed kill that stops a live loop: deny and on-demand halt both proven on the fleet
Self-extension: a scoped loop authored a firewall-checked skill through the governed chokepoint, both backends
All four protocols on a live run: AEE envelopes, per-turn WARD, a completed VOLT run, AOCL classification
Loop outcomes recorded and reflected on through the same QuoxMind path as every governed objective

Beta: built, not fully driven

The Observer’s stuck / oscillation verdicts (the interrupt path is proven; the verdicts have not fired on a wedged live loop)
Skill lineage from a loop-authored skill (shipped, not driven end to end)
The risk checkpoint gate: unit-green, not yet triggered by a live risky call
Codex scope nuance: Codex’s native tools sit outside per-tool scoping, so patterned scopes are rejected loudly for Codex rather than silently widened
The dashboard halt button: shipped in the dev.sessions panel, wired to the proven halt route; the click itself has not yet fired on a live running loop

Planned: on the roadmap

Precedent as binding policy: write path and gate logic proven; the full model-driven citation loop is blocked on an inference provider in the running stack
Fully autonomous, "no human required" self-build: the north star, deliberately not shipped. The pre-start human approval is by design

Governance · Human in the loop · The four protocols · QLoop (the pitch)