Independent testing, at the same order of cost as the coding.

Is it end-to-end testing?

Yes, and it does more than a usual end-to-end suite.

Like any end-to-end test, OneDroid Argus exercises the running system, with nothing mocked: HTTP, the message broker, the database, web pages in a real browser. It does not judge the diff. Four things are different.

Why

Testing was the part teams could skip. Not any more.

For years companies spent between 23% and 35% of their IT budget on quality assurance and testing (23% in 2013, 26% in 2014, 35% in 2015, 31% in 2016, 26% in 2017). When it was first measured at 18%, Capgemini's World Quality Report called that "an indication of insufficient attention on quality". Testing took people and time, so it was the part that got cut. Coding agents now build a feature for a few dollars, and code nobody tested independently is still code nobody tested independently.

OneDroid Argus brings independent testing down to the same order of magnitude as the coding. In one measured experiment, Claude Code built a feature for $1.01 to $1.97 a run, and the independent tester's session, which wrote the checks once for the whole feature, cost about $5.30. Those checks stay as regression checks for the next change. The experiment, its figures and its limits.

No test proves code free of bugs. Different testers catch different things, and a model can give a different answer on each run. What stays fixed is the record: the scenarios are sealed before the build, run against the build you pinned, and anyone can run them again.

The evidence contract

Sealed before the build.

A tester writes the scenario set: a person or an agent who is not the builder, working from the ticket, the acceptance criteria and the shape of your system. Each scenario says what to trigger, where to look and what a healthy answer is. The tester seals the set, and its hash goes on a cryptographic ledger before the work is judged, so anyone can check that the scenarios existed first and never changed. The hash proves priority. Keeping them unseen is a separate mechanism: the builder holds a credential that can ask for a run and read the verdict, and cannot read a scenario or an expected value. Both halves matter; we say both.

This is the answer to "an AI agent wrote 50,000 lines overnight: how do I know what it did?". A model that can see its checker learns to satisfy the checker. The builder can't game checks it never sees. And a verdict comes with its boundary: what was run, what the certificate proves and what it does not. And it is affordable: the independent tester costs the same order as the AI coding (see above).

The run

Run unseen, then adjudicated.

The runner sits next to the system under test, inside your environment, and nothing is mocked. It drives HTTP, the message broker, the database, external delivery, MCP tool calls, web pages in a real browser, permissions and rate limits, and gathers evidence by correlation id. During the build it reports only what happened — failing ids and observed reality, so your agent can fix things — never what was expected. The final run is made against a pinned artefact, and the control plane adjudicates it.

Between steps a check can read one row of the system's PostgreSQL database with a read-only query, or ask its log store (Loki) whether a line was written. A check can also make the system fail on purpose while it runs: stop, start or scale a deployment, or delay or cut one connection. Nothing can be made to fail unless the system's operator has listed it; OneDroid Argus undoes every fault it injected, and the report and the certificate say what was done and whether every undo succeeded.

The reveal

The verdict binds to a specific build, so it cannot be re-pointed at a later one. It comes with a certificate: proof without the tests, which anyone can check with the open CLI, with no OneDroid account and no contact with OneDroid: it reads the public chain through an RPC endpoint you choose. Because the runner is open source, a certificate proves what the runner reported and when, not that the runner was unmodified. When the tester chooses to reveal the set, every scenario is published with its trigger, expectation, evidence hash and verdict, and any scenario can be replayed by the runner against the same artefact — by you, by your auditor, by anyone. The ledger proves the order of events and that nothing was edited. Running it again is what proves the result is true.

Every scenario ends as passed, failed, errored or not_applicable (it could not run), and neither an error nor not_applicable is ever a pass. A broken driver, a missing fixture or an unreachable layer is reported as exactly that, so a run cannot go green because nothing ran. A load run has one more outcome, degraded. The verdict is a decision about one build, with the evidence attached. It is not a score: there is no number to optimise for and no “safe” label.

Mode two

Under load.

A scenario can declare a load: a number of users held for a duration, with the p95 latency and the error rate it must stay under. For message brokers there is more: a ramp of sessions in steps, up to 2,000 sessions a step by default, that finds the limit. Each step records the rates offered, sent, confirmed and delivered, the time from publish to confirm and to delivery, the errors by class, and any time the broker blocked. A ramp that crosses the limit at its top step has measured the limit, which is not a failure. An HTTP target can be ramped too: users are raised step by step against one named target, and the ramp stops at the first step that is not comfortable, so a system that has broken is not pushed harder. Under load, expectations are tolerances, and the report says so.

The limits, stated plainly: stepped ramps exist for AMQP brokers and for one HTTP target at a time, and none drives a web page in a browser. A target takes load only after its operator lists it as one that may, and a live system should never be listed. No load ramp sits under a certified verdict or on a schedule.

Mode three

Continuously.

Once a hand-run is green, or every red in it is one you have read and decided to keep, the reviewed scenario set goes on a monitor schedule: every 15 minutes at the shortest, with no one driving it. The web app answers one question first, “Is it OK?”, from the scheduled runs only: a failing run someone started by hand never turns it red, and a system no monitor has measured reads “not measured”, never green. What the system cannot fix by itself is listed under “Needs a person”, with who acts next.

New, in early use

One sealed set, two systems.

The same sealed checks can run against two systems, or two versions of one, and their recorded outputs are compared. The result is a table: rows are checks, columns are systems, and each cell reads same, differs, approved, noise, not measured or could not run. What may differ is declared before the run, with a tolerance for numbers. A difference a person accepts is pinned to the two outputs they were shown: if either output changes, the approval stops counting and the cell differs again.

This is the newest part and we say so: it ran end to end for the first time on 4 October 2026, on three systems. Expect it to change.

On 5 and 6 October it ran on two releases of an open source ticketing system, on one laptop. It found six differences between the releases. Read the case study, limits included.

Surfaces

Three ways in.

A CLI with machine-readable output for agents; skills your coding agent already knows how to load; and an MCP server with separate credentials for the tester and the builder.

The runner and the CLI are open source under MIT at github.com/OneDro1d/argus-runner. A run needs an account on the hosted control plane. Create one at argus-dev.onedroid.ai (e-mail, Google or Microsoft). It is the evaluation environment: for testing, with no promise that data is kept, so keep production data out of it. The steps after that are in the OneDroid Argus docs; for an environment of your own, talk to us.

Boundaries

What OneDroid Argus is not.

What it installs

Reference material.

The written method behind the gate is open source. Reference material lives at docs.onedroid.ai.