Agent · Planned

Adversarial Team

Puts a team of hostile reviewers on your finished work before a real reviewer gets to it. One focused workflow, with a clear result at the end.

Read docs

How it works

Adversarial Team takes work you already consider done and tries to break it. It builds a small team of reviewer agents, each hunting a different class of failure, and turns them loose on the change you point them at. They are not there to be helpful or to suggest improvements. They are there to find the case where the work is wrong, the input nobody considered, and the assumption that only holds in the one setup it was tested in.

What comes back is a list of objections rather than a list of suggestions. Every objection names the concrete scenario that produces the failure: the input, the state, or the ordering that makes the code do the wrong thing. That makes each one checkable in a minute, because it either reproduces or it does not. The reviewers read the whole repository, not a pasted diff, so an objection can point at the caller three files away that the change quietly broke.

It does not fix anything and it does not rewrite your work. The team's whole output is the case against the change, and deciding which objections matter stays with you. That boundary is deliberate, because a reviewer that also edits has a stake in its own edits and stops attacking them. Once you have fixed what it found, you can point the team at the fix and get a fresh attack on the new version.

runtime
local
one-time
adversarial
multi-agent
red-team
failure-scenarios
edge-cases
error-handling
failure-correction
assumption-testing
test-skepticism
blind-spots
objections
stress-testing
pre-merge
risk-weighting

Agent environment

Pricing

$0.25 per launch

runtime
local
one-time

Adversarial Team runs a group of read-only reviewers through a coding agent on your machine. Each reviewer checks the repository for a different kind of failure and returns specific cases to verify; the team does not edit your work. Your repository stays on your machine.

This agent is not available yet. Install vidbyte-cli, log in with your Vidbyte key, and use `vidbyte-cli runtime doctor` to check that a supported coding agent is installed. The setup prompt walks through those checks; the review command will work when the agent launches.

Run it from your own agent

Copy prompt

Paste this into the agent you already use and it will ask you what you need, then write the exact Adversarial Team invocation for your job.

You are helping me write the task text for Vidbyte's Adversarial Team, which puts several hostile reviewer agents on work I already consider finished and returns objections with concrete failure scenarios. Ask me these one at a time and wai…

Run it from the command line

Every agent starts with the same two setup commands: install vidbyte-cli, then log in with your Vidbyte key. After that, Adversarial Team is one command with one option for choosing which coding agent hosts the reviewers. Two read-only checks tell you whether your machine is ready and what the runtime is listed at; neither shows whether the agent has shipped, and the launch command still stops before running.

bash
pipx install vidbyte-cli
Installs vidbyte-cli from PyPI, the command line every Vidbyte agent is started and tracked from. pipx gives it its own environment and puts the `vidbyte-cli` command on your PATH; without pipx, run `python -m pip install vidbyte-cli` inside an activated virtual environment instead, and read the CLI repository README for the full installation notes. Run `vidbyte-cli --version` afterwards, and if it prints a version number the install worked.
View subcommands
--python
Picks the Python interpreter pipx builds the CLI's environment with, such as `--python python3.12`. vidbyte-cli needs Python 3.11 or newer, so set it when your default Python is older and the install refuses to resolve.
bash
vidbyte-cli login
Stores your Vidbyte API key, which is what identifies you and what every agent's charge is billed against. It reads the key at a hidden prompt, checks it against Vidbyte before saving anything, and then keeps it in your operating system's keyring. Run `vidbyte-cli whoami` afterwards to confirm which account the stored key belongs to.
View subcommands
--with-token
Reads the key from standard input instead of a hidden prompt, which is how you log in from a script or a CI job. Pipe it in from your secret store rather than typing it into the command. There is deliberately no --api-key flag, because anything in the command line leaks into process listings, shell history, and CI logs.
--allow-file-fallback
Approves storing the key in a permission-restricted file when the machine has no operating-system keyring, such as a bare Linux server. Without it, login asks before falling back, or refuses when there is no terminal to ask on. Anything running as your user can read that file, so use it only where a keyring genuinely is not available.
bash
vidbyte-cli runtime adversarial-team "<the work to attack>"
Launches the review team on the work you describe, in the current working directory. The task text should say what the change is supposed to do and what must never happen, because that is what the reviewers attack. In the current release it validates your host and directory and then stops before charging you or starting a reviewer, since the executor has not shipped.
View subcommands
--host
Names which installed coding agent hosts the reviewers: auto, codex, claude, or opencode. The default, auto, resolves a supported host from your PATH. Set it explicitly in scripts, so a machine without the expected host fails loudly instead of quietly using a different one.
bash
vidbyte-cli runtime doctor
Reports which supported coding-agent hosts this machine has and where each one lives on your PATH. Running it now tells you whether your setup will be ready when the executor lands. It reads nothing from the network and costs nothing.
bash
vidbyte-cli runtime list
Lists every runtime Vidbyte will admit, with the charge for each read from Vidbyte's catalog rather than hard-coded. Adversarial Team already appears there, because Vidbyte's side of it is ready. The missing half is the executor inside the CLI, so the launch command itself is what tells you it has shipped: it stops failing.

Use cases

Each example names the problem, the setup, the command to run, and the result you should expect.

Why use this agent

A general agent asked to review something is a bad reviewer for a structural reason: it is the same agent, in the same session, that just produced or approved the work. It has already committed to the framing, and asking it to critique that framing gets you a polite list of nitpicks that leaves the actual decision untouched. Even in a fresh session, a general agent is tuned toward being helpful, which in review means proposing improvements rather than finding failures. Those are different searches, and they return different things. This agent is instructed to attack, and its output is objections rather than suggestions.

The second difference is the shape of the finding. A helpful reviewer says a piece of code could be clearer, while an adversarial one says what input makes it produce the wrong answer. The second kind is the only kind you can act on with confidence, because it either reproduces or it does not. Requiring a concrete failure scenario is also what keeps a review from sliding into style commentary. That slide is what most automated review turns into once you stop reading it closely, and it is why people stop reading it.

The third difference is coverage. One reviewer, human or model, looks for the failures it habitually looks for, and its blind spots stay the same across every review it does. A team of reviewers, each hunting a different class of failure, covers more ground in the same wall-clock time. The reviewers also read the whole repository rather than a pasted diff, which is where the objections that matter tend to live. What you get is breadth of attack, not a second opinion.

Author blindness to own work
The team has not spent the last hour convincing itself the design was right. That is the whole reason a second reader finds things the author cannot. You cannot get the same effect by reading your own work more carefully.
Agents grading their homework
Asking the agent that wrote a change to review it returns nitpicks. It has already committed to the framing it would need to question. The review therefore never reaches the decision that matters.
Suggestions instead of failures
Reviewers instructed to attack search for the input that breaks the code. That is a different search from the one that produces a note about clarity. It returns a different kind of finding, and it is the kind you can act on.
Objections you cannot act on
Every finding is tied to a concrete scenario, so it either reproduces or it does not. An objection you can disprove in a minute costs you almost nothing to receive. That is what keeps the list worth reading to the end.
One reviewer's stable blind spots
Several reviewers hunting different failure classes cover ground a single reviewer misses. A single reviewer's misses are systematic rather than random. Adding more passes with the same reviewer therefore does not close them.
Diffs missing the real context
The reviewers read the whole repository, so they can follow the caller three files away or notice the migration that has not run. That is where the expensive objections usually live. A pasted diff cannot reach them.
Finding bugs in public
The objections arrive before the pull request instead of in its comments. The fix is then a commit rather than a review cycle. That is the difference between an hour and a day.
Misgivings you cannot name
Asking directly for the strongest case against a design turns a vague unease into a stated objection. You can then fix it or dismiss it on purpose. Dismissing it on purpose is not the same as ignoring it.
Tests green for wrong reasons
A hostile read of a suite asks what would still pass if the implementation were broken. Writing tests never asks that question. That is why a suite can be green and useless at the same time.
Risk nobody weighted
Naming the stakes in the task changes what the reviewers search for. An irreversible change gets looked at differently from a cosmetic one. That is what you would want from a human reviewer too.
Fixes that ship unattacked
A patch written in response to review rarely gets reviewed as hard as the original change. Running the team again on the fix gives the patch its own attack. High-stakes paths stop getting their weakest review on their last edit.
Reviews that forget their reasoning
The objection list is a written record of what was attacked and what survived. You can attach it to the change or cite it when someone asks whether a risk was considered. Most review leaves nothing behind but a green check.

When to use it

When you are the only reviewer available and you also wrote the change.
When an agent produced a large change and told you it was correct.
When the change touches money, permissions, or data you cannot restore.
When the work is about to go in front of reviewers whose time is expensive.
When the tests pass and you do not trust that they pass for the right reason.
When something about a design feels wrong and you cannot name it.
When the cost of being wrong is much higher than the cost of one more pass.
When you want objections rather than improvements.
When a finding has to be reproducible to be worth reading.
When the important failure modes need context from files the diff never touched.
When you would rather find the problem yourself than have it found in review.
When the change is finished and re-planning it is not what you need.
When you are handing work to someone who will assume it was checked.
When a previous version of this change already shipped a bug.
When a fix to a risky path needs to be attacked as hard as the original change.
When you need a written record that a specific risk was examined before release.
When every automated reviewer you have tried comments on style and misses behavior.

Adversarial Team

How it works

Agent environment

Run it from your own agent

Copy prompt

Run it from the command line

Use cases

Why use this agent

When to use it

Similar agents

Ensemble Agent

Persistent Agent

Persistent Researcher