63 specialist agents
The Quox facts, as a page
This is the human-readable form of quox.ai/facts.json, rendered from the same registry that generates it, so the two cannot drift.
The JSON and its witness receipt at quox.ai/facts.receipt.json remain the canonical machine artifacts: every entry below carries a source and an as-of date there too, the file’s bytes are hashed into an append-only WARD chain, the chain tips are Ed25519-signed and countersigned by an independent RFC-3161 timestamp authority, and the whole check runs offline. How to verify, step by step: /for-ai.
Each claim below can carry a Claim Registry evidence block: issuer, independence, a link to inspect it, a stated limitation, and any open findings. quox.ai/facts.json is the machine-readable claim registry; only evidence the owner has approved is ever shown.
Why this page exists: an AI answer engine was observed correctly explaining our receipt and hash chain to a user, then failing four direct requests to quote the actual data, because answer engines cite indexed pages, not raw JSON. So here is the data, as a page.
This page is deliberately plain, by design: built for crawlers, AI answer engines, and anyone who wants the signal without the polish, the neurodivergent among us included. For the human tour, start at the homepage.
Counted claims
168 governed tools
Import from a library of more than 1,300 browsable workflow templates. 12 are Quox-curated and verified.
49 seed skills
12 QuoxMind faculties
413 integration types
76 command groups, 384 commands
Protocols
Live IETF Internet-Drafts are working documents, not standards, and we do not claim IETF endorsement.
AEE (Agent Envelope Exchange): specification published, implementation shipped, live IETF Internet-Draft draft-cowles-aee-01. Current revision expires 2027-03-04.
Self-attestedIETFinspect the evidence
Fetch the draft from the IETF Datatracker at the url above and confirm draft-cowles-aee exists at the stated revision.
An Internet-Draft is an individual submission hosted by the IETF, not IETF review or endorsement.
AOCL (Agent Orchestration Control Layers): specification published, implementation shipped, live IETF Internet-Draft draft-cowles-aocl-01. Current revision expires 2027-03-04.
Self-attestedIETFinspect the evidence
Fetch the draft from the IETF Datatracker at the url above and confirm draft-cowles-aocl exists at the stated revision.
An Internet-Draft is an individual submission hosted by the IETF, not IETF review or endorsement.
VOLT (Verifiable Operations Ledger and Trace): specification published, implementation shipped, live IETF Internet-Draft draft-cowles-volt-01. Current revision expires 2027-03-04.
Self-attestedIETFinspect the evidence
Fetch the draft from the IETF Datatracker at the url above and confirm draft-cowles-volt exists at the stated revision.
An Internet-Draft is an individual submission hosted by the IETF, not IETF review or endorsement.
WARD (Write-once Append-only Receipt Digests): specification published, implementation shipped, live IETF Internet-Draft draft-cowles-ward-00. Current revision expires 2027-03-04.
Self-attestedIETFinspect the evidence
Fetch the draft from the IETF Datatracker at the url above and confirm draft-cowles-ward exists at the stated revision.
An Internet-Draft is an individual submission hosted by the IETF, not IETF review or endorsement.
Enforcement
What the gates actually do, per claim, with the source module and date.
A HITL approval hold blocks execution until a named human decides, and the per-node approval gate fails closed: an action it cannot evaluate is held, it does not proceed by default.
A pending approval never silently proceeds: the held action stays held. Approvals past their expiry window are swept to expired status by a scheduler registered at server boot; an expired approval does not auto-approve, auto-deny or auto-escalate, the workflow remains paused until someone acts on it.
A policy DENY hard-stops the node: the pipeline emits a POLICY_DENIED envelope and returns failure without walking further edges.
Collector API routes are deny-by-default: in production the auth gate enforces 401/403 even when the enforcement flag is unset, unless an explicit time-boxed break-glass record exists. Outside production the gate can run in shadow, log-only mode.
An agent working through Quox does not hold the stored credentials it works with. When a tool call needs a vault credential, the platform resolves it server-side and makes the call; the model receives the result, never the secret value. The one agent-facing vault tool is a health test-connect that never reveals or echoes the credential value.
A WARD receipt is tamper-evident proof that Quox recorded the governed request, decision and result, in sequence, unmodified since. It does not independently prove an external system’s final state; pair it with that system’s own records when the question is whether the world changed accordingly.
Containment
How a running agent is stopped, bounded and governed, including the gaps we state plainly.
Agent budgets for tokens, tool calls, wall-clock duration and optionally USD cost are enforced as a pre-execution gate: a breached budget blocks the next scheduled run or loop iteration before it starts. This is not after-the-fact accounting. Status Beta; known gap: per-request token-in usage is not populated on the hot path.
The loop-stuck detector fires after three identical action results or errors in sequence (also on oscillation and monologue patterns) and requests termination of the live session; Beta, the interrupt path has fired live. Per-resource circuit breakers (ssh, llm, collector) are wired at the primary execution chokepoints and fail fast with a typed error when open, with real half-open recovery; Beta, first wiring 2026-09-02, uncovered paths named in the status doc.
The kill switch is enforced server-side: a per-agent E-STOP or instance DEFCON RED blocks new dispatch at the scheduler, at every collector invocation chokepoint, and at the shared objective-dispatch chokepoint that covers team schedules, human plan approvals and calendar-triggered work (each refused with a typed AGENT_HALTED error; a refused plan is held for later re-approval, not destroyed). Live loop sessions are killed at the turn boundary, and every path fails closed if the halt store is unreachable. Only a human administrator can set or release it; an agent or service key cannot, and every trigger and release lands in the audit trail.
Agents configured at DEFCON ORANGE or RED cannot act autonomously: the autonomy decision engine forces escalation to a human before acting. Retry limits and consecutive schedule failures likewise force deferral or escalation instead of another autonomous attempt.
Memory writes accept only the fact role (other roles are rejected with a typed error) and are scoped server-side to the authenticated org and user; client-supplied org or user identifiers are discarded. Not yet implemented: retention or expiry policy, content redaction, and human review before a memory becomes readable.
Acceptance ("did it work")
Outcome attestation, separate from run status. An attestation layer, not automated evaluation; the difference is stated inside the claims.
A terminal run can carry a witnessed acceptance verdict: a pass or fail attestation of whether the action achieved its intent, recorded separately from run status. The verdict pins the run's evidence-chain head hash and is itself witnessed through the same VOLT bundle and WARD receipt pipeline as the run; the run's sealed bundle is never touched retroactively.
Who attested is derived from the credential class (human, agent or service), never self-asserted: an agent that marks its own work as passing is recorded as an agent, in the verdict row, in its audit envelope and in its witnessed evidence run.
An acceptance verdict is an attestation, not automated evaluation: the platform records who said it worked and binds that statement to the evidence; it does not yet evaluate declared acceptance criteria itself. Verdict history is append-only; a later verdict supersedes but never edits the record.
Track record
The operations canary: one signed, TSA-countersigned checkpoint per day, on an append-only public chain, failures included. The day count is yours to recompute, never ours to assert.
Two operations canaries publish one signed, RFC-3161 TSA-countersigned checkpoint per day each, on append-only public chains whose signing key was publicly pinned before either began: one observing the development instance, and one observing the production instance that runs Quox Ltd's own operations (observation-only in its first phase; the governed self-workload arrives in later published phases, so the buildout itself is visible in the history). Failures are included: production day 0 already records a failing container healthcheck, a missing recurring-backup schedule and its own corrected day-0 parser slip. Day zero for both is 2026-09-03; accumulated day counts are independently recomputable and cannot be backdated.
Registry-only claims
Claims that live only in the Claim Registry, not as a row in the counted/protocol/enforcement claims above, each with its own owner-approved evidence.
quoxproof is published on PyPI with build provenance an outside party can trace to its source repository and commit.
IndependentPyPIinspect the evidence
Inspect the PEP 740 provenance attestation PyPI generated via Trusted Publishing (https://pypi.org/integrity/quoxproof/0.2.0/ , per-file provenance returns HTTP 200). PyPI, not Quox, binds the published artifact to the GitHub repository and commit it was built from.
PyPI provenance attests where the artifact was built from (repository and commit); it is not an independent audit of what the code does.
Every crawl of every site Quox runs is captured as a signed, hash-chained WARD receipt that a reader can recompute offline without trusting Quox.
Self-attestedvisitor-recomputableinspect the evidence
Download the bundle and run: node recompute-chain.mjs <site>-chain.json quox-seo-pubkey.pem . It recomputes every entry's hash chain and verifies the Ed25519 tip signatures offline, with no call back to Quox.
The receipts are issued by Quox; the independence is that the reader recomputes them offline, not that a third party issued or audited them.
Quox runs governed security scans against its own production surface and publishes the findings, both fixed and still open.
Self-attestedQuoxinspect the evidence
Findings from the 2026-09-28 DRAGO discovery scan of quox.ai are filed as tracked issues and projected onto /security. Two are already fixed and closed (X-Powered-By #632, legacy TLS 1.0/1.1 #631); the open ones are listed below.
This is Quox auditing Quox. An independent third-party security audit is a stated next step, not yet done.
Quox continuously witnesses the health of its own evidence chain, and that self-witnessing check is itself machine-proven on the proof matrix.
Self-attestedQuox
Recompute from /facts proof-engine-evidence.json: the receipts/witness-health rows at checks ed0ee30fa935; the projection hash and WARD receipt make the snapshot independently checkable.
Proven on our own dev box and clean throwaway VMs, not yet on a third-party-operated install.
Quox's secret vault reports its own health as a machine-proven check; an earlier regression was caught red on the matrix and fixed.
Self-attestedQuox
Recompute from /facts proof-engine-evidence.json: the vault/vault-health rows at checks 294e3221f797; the projection hash and WARD receipt make the snapshot independently checkable.
Proven on our dev install only; the earlier failure is preserved in the status history, not erased.
Quox searches your files on a running install. It is proven on our dev install and is not yet proven on fresh clean-VM installs, where it currently fails.
Self-attestedQuox
Recompute from /facts proof-engine-evidence.json: the files/t3-search-files rows at checks 046769154e07; the projection hash and WARD receipt make the snapshot independently checkable.
Proven on our dev install only; currently fails on fresh clean-VM installs.
Check any of this yourself
The runnable worked example at quox-facts-witness/worked-example is a real run held at its approval gate, denied, and attested, with the platform’s own verifier beside it. Its adversarial sibling, worked-example-adversarial, publishes the unfriendly case on purpose: a false pass verdict, attributed and refuted on the permanent record, with the README stating plainly what the platform cannot catch today. The same repository holds the append-only history of every witnessed facts-chain tip.
Newest claim date on this page: 2026-10-11.