VirtuProbe Studio
I am extremely lucky when it comes to the friends around me, whether it is the people who helped me kick off awesome UX or, as happened now, the new direction of this project towards the AI era. Last week a friend who runs engineering at an AI-first company spent thirty minutes describing how he works now, and put the question to me deliberately, because he could see where it landed.
He described 2026 in one sentence. On a fresh server he installs an agent first, before anything else, and after that he does not think about instrumentation, because the agent is the instrumentation. He does not write exporters. He does not write healthchecks. He does not write the glue scripts I have written a thousand of. He points an agent at a system and it works the interaction out as it goes.
None of that is speculative and none of it needed selling to me. So the question stands on its own:
If an agent can test anything, what is a testing tool for?
It is a fair question to put to anyone who builds a testing tool, and the wrong reflex is to go looking for something the machine cannot do. That reason does not exist, and hunting for it is how products die with their arms folded.
I knew what he was driving at while he was still talking. The week that followed did not go into working out the answer. It went into building it.
Here it is: determinism, repeatability and evidence are properties of the artifact, not of the actor.
Be careful about what that claims. Agents are already good enough to understand a system faster than I can, and that gap keeps widening. The claim is narrower than capability, and it survives the agent getting better, because capability was never what it turned on.
An agent run twice can come out differently, and that is what the thing is rather than a flaw waiting to be fixed: it reasons about the situation in front of it, and the situation is never quite the same twice. "Trust me, it was green" stays hearsay however capable the thing saying it, and however right it happens to be. Evidence is something a second person can check without rerunning your reasoning.
A hard, repeatable, auditable test comes into existence at exactly one moment: when the interaction is frozen into something that is no longer an agent. That frozen thing is what I build.
Which gives two modes rather than a competition. The agent is the mode of understanding and authorship. The tool is the mode of trust and repetition. You want both, and confusing one for the other is how you end up with a green pipeline that means nothing.
That splits the work into three layers, and they form a loop rather than a chain.
The agent authors. It points at the system, understands it, and crystallises the interaction into probes, chains and suites. This is the part it is genuinely better at than I am. Point it at a directory of ad hoc scripts nobody wants to own and let it turn them into something that runs the same way twice.
A person supervises, through a glass box. Review the work, accept it, change it. And later, when it breaks at three in the morning, the same surface is where you take it apart: open the step, look at the raw bytes that went out and came back, change a header, run that one step on its own, compare it against the run from last week, and freeze the fix back in. Supervision and debugging are two faces of one human layer, and the open cabinet is the shared surface for both.
The artifact runs deterministically, with evidence. Same result at three in the morning in CI as on your desk, and a record afterwards that somebody else can read.
Failures in the third layer come back to the second. Corrections in the second flow back to the first, so supervision teaches the author instead of just cleaning up after it. The three layers close on themselves.
The workbench had been filed as legacy. The editors, the step by step views, the raw request tab, the history and the diff: surface area to eventually tuck behind the assistant, on the theory that depth is what makes a tool hard to walk into.
That was wrong twice over. Depth was never the thing standing between somebody and their first request: the answer to a crowded screen is disclosure, showing the depth when it is asked for. And against a pure agent, which is a black box that reports its own results, and against a test framework written in code, which gives you nothing to look at until you add print statements, the open cabinet is the thing I have that they do not. So it is the part to sharpen, for the person sending their first request as much as for the one debugging a suite at three in the morning.
So the protocols, the hand written clients, the chaining and the fuzzing move out of the shop window and into the foundations. Nothing is deleted and nothing is deprecated. They are the reason an agent can point at almost anything here and have it verified deterministically, across protocols, in one flow. This is a reframing, and on the day I wrote it down not a line of code changed.
Supervision has to survive being boring. Every action approved by a human, forever, is a tax nobody pays twice.
So it is exception based. Running unattended is a first class mode of its own, and the glass box is what you drop into when something creaks, rather than a turnstile every action queues at.
But that raises the uncomfortable half. A deterministic run of a bad test is confidently wrong, which is worse than no test, because it buys false confidence at the price of real effort. So the question stops being "did it pass" and becomes "is this a good test". That needs help that is not another opinion from another model: a deterministic linter that asks whether a chain asserts anything at all, whether an extractor feeds something that is never read, whether a condition can ever fire. It is decision support for the person rather than a gate that decides on its own. The person still decides, which is better for trust and much better for anyone who has to explain the decision later.
This is the question I care most about getting right, because the honest failure mode of everything above is that it turns a tool you can open and use into a platform you have to adopt.
The person who just wants to send a request and look at the response is the ground floor of the same building, and it is a staircase up from there:
Two disciplines keep that honest, and I would rather write them down where you can hold me to them. Progressive disclosure taken seriously: the default surface stays a request workbench, and suites, coverage, agents and the rest appear when asked for. Zero ceremony on the simple path: sending a request must never begin with "first create a project, a suite and an environment".
There is a test I apply to every piece of the agent layer before it ships: does it appear when no agent is connected? The activity panel, the approval prompts, the connection notices. All of it asleep. If you never connect an agent, you should never have to learn any of those words.
Since that conversation, the runtime layer that was missing has shipped: suites with setup and teardown and one aggregated verdict, runs that stream back step by step instead of spinning until the end, and reports you can hand to CI. So has the front door: an agent connecting over MCP can do what you can do, inside your licence, without ever being handed a secret. So has the supervision surface: connected agents are listed with their runs as they happen, approval is scoped per project, and you can block one mid run. The linter is in the chain editor.
What is not done: coverage mapping, so you can see what an agent did not touch, and the outward direction, where this thing stops being something you drive and starts emitting signals of its own that something else can react to. Both are written up. Neither is built.
This did not come out of a planning session. It came out of thirty minutes with someone whose working day has changed shape faster than most people's, who was willing to describe it plainly. If you want to do me a favour, be that person. The tool is free to download, and I would rather hear the uncomfortable version now.
The HTTP workbench is free forever, the whole thing. Raw and structured requests, chaining, the built in assistant, no account and no cloud, on macOS, Linux and Windows. The wider protocol suite, suites, CI runs and the intercepting proxy are part of the Engineering tier; fuzzing and the offensive protocol suite are Security.