A Second Agent Is Not Independent Proof

A software agent can write a change, open the application, exercise the interface, inspect what happened, and return evidence to the builder. That closes a gap that has kept autonomous delivery stuck at code generation. The work no longer has to wait for a person to notice that the screen is wrong, reproduce the failure, and explain it in another message.

That matters because manual testing is often a coordination queue disguised as judgment. A person waits for a build, reconstructs the intended behavior, clicks through a path, captures the failure, and hands it back. When the expected behavior and the environment are defined, an agent can perform that repeatable loop continuously and preserve what it saw.

Our position is that this work will move to agents quickly. Roles built around carrying predictable checks between builders and reviewers will shrink with it. Human judgment still decides which outcomes matter and which failures are unacceptable, but it does not need to perform every click to own that decision.

Calling one agent the builder and another the tester creates a useful division of labor. It does not automatically create independence. If both receive the builder's explanation, use the same friendly environment, inherit the same mistaken requirement, and optimize for closing the task, the second agent is another participant in the same story.

Real separation changes what the verifier can see and what it is allowed to change. The verifier should begin from the accepted requirement, not the builder's defense. It should run in an environment the builder did not arrange, use credentials the builder cannot borrow, and preserve failures the builder cannot erase. Most importantly, it must not be able to lower the standard until the candidate passes.

This is an authority design, not a prompt trick. You can ask an agent to be skeptical, careful, or adversarial. Those words may improve a response. They do not stop the system from rewriting a test, skipping an awkward path, or accepting an explanation when the evidence is weak. Independence exists only when the machinery enforces it.

An agent can operate a browser perfectly and still test the wrong thing. It can confirm that a button responds without knowing whether the action was permitted. It can verify that a page rendered without knowing whether the underlying record was corrupted. It can celebrate a smooth path that violates the business consequence the change was supposed to protect.

The missing piece is an executable contract. Name the starting state, the action, the observable result, and the conditions that must remain true around it. Include the failures that matter: stale permissions, partial data, retries, interrupted writes, and rollback. A testing agent becomes valuable when it can compare reality with that contract, not when it can produce a polished account of its tour through the product.

People own that answer key. They decide what the business means by correct and which tradeoffs it will accept. But if the answer lives only in a reviewer's head, the factory cannot use it. Judgment has to become a requirement, a boundary, or an escalation rule that survives the person who first stated it.

A tester's conclusion is not enough. The factory needs the inputs, environment, actions, observations, and artifacts that produced it. That record lets another gate reproduce the claim, lets a later failure challenge it, and lets the next run inherit more than a green label.

This is where agent-run testing can outperform the human process it replaces. Machines can capture every step as a byproduct of execution. They can attach the state before and after an action, retain failed attempts, and rerun the same contract after the code changes. The evidence does not depend on someone remembering to write a careful summary at the end of a long day.

Do not confuse volume with proof. A thousand screenshots can hide the one missing assertion. A long trace can document activity without establishing correctness. Keep the evidence tied to a claim: this condition existed, this action occurred, this result followed, and this independent gate accepted it under bounded conditions.

The impressive moment is watching an agent find a bug in another agent's work. The useful system begins after that moment. It routes the failure back, blocks promotion, preserves the evidence, and tightens the next attempt without waiting for a person to reconstruct what happened.

That loop changes the economics of delivery. Builders can run continuously because verification can run with them. Human attention moves to new risks, disputed requirements, and consequences the existing contracts do not cover. Repeatable inspection becomes machinery instead of a job queue, and the factory retains what each rejection taught it.

Use the second agent. Just do not grant it trust because it has a different name or model. Give it separate authority, a durable answer key, hostile conditions, and evidence that another gate can reproduce. The builder produces a candidate. The proof line decides whether the business should live with it.