Agent · Planned

Adversarial Team

Puts a team of hostile reviewers on your finished work before a real reviewer gets to it.

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

Use cases

01
You open a pull request, it looks fine to you, and a reviewer finds three real problems in the first ten minutes. None of them were subtle; you just could not see them, because you had spent the whole afternoon convincing yourself the approach was right. Now the fixes happen in a review cycle with an audience instead of in a quiet commit. Every round trip costs a day of someone else's attention, and the next pull request starts from a little less trust.
How the agent solves it
Run the team on the branch before the pull request exists, so the first hostile read happens while fixing is still cheap. Describe what the change is supposed to do in intent terms, because the reviewers hunt for the gap between that intent and what the code actually does. Each reviewer takes a different failure class, so the objections you get back are not five versions of the same nitpick. Read the list, reproduce the ones that look real, and fix them as ordinary commits. The pull request you then open has already survived the first attack.
What to run
1. Prompt
  Paste this page's copy prompt into your coding agent, answer its four questions about the change, and keep the task text it writes.
2. Command
```
vidbyte-cli runtime adversarial-team "<task text from the prompt>" --host codex
```
What you get
An objection list you can clear before anyone else reads the branch.
- Each objection names a concrete input or state that breaks the change, so you can reproduce it in a minute.
- Real failures become commits on the branch instead of comments on a pull request.
- Objections that do not reproduce are dismissed on purpose, not left as a nagging doubt.
- The reviewer's first ten minutes go to the design instead of to the bugs you could have found.
02
A coding agent wrote a large change, told you it was correct, and handed it back with a confident summary. The only independent check you have on that claim is reading every line yourself, which is the exact work you delegated. Asking the same agent to review its own output returns polite nitpicks, because it has already committed to the framing it would need to question. So the change either sits unreviewed or eats the afternoon you were trying to save.
How the agent solves it
Point the team at the change and describe what it was supposed to do, not what the agent says it does. Reviewers that did not write the code have no stake in its framing, so they search the space between the request and the result. Name the parts you care about most, such as the error paths or the data migration, so the team weights its search toward them. You then read a short list of specific failures instead of the whole diff. The agent's claim becomes something you checked, not something you trusted.
What to run
1. Command
```
vidbyte-cli runtime adversarial-team "The agent changed the billing retry logic. It was asked to retry only idempotent calls and never double-charge. Attack that claim." --host auto
```
What you get
An independent read of the agent's work that does not require you to reread it.
- Every place the change drifted from the original request, with the input that shows the drift.
- Error paths the agent never exercised, listed with the state that reaches them.
- A clear answer on whether the confident summary held up.
03
You are about to ship something that touches money, permissions, or data you cannot restore, and the cost of being wrong is far higher than usual. Your normal review habits were built for ordinary changes, so they give an irreversible migration the same attention as a copy fix. Nobody on the team has said out loud what must never happen. That silence is how an unweighted risk makes it to production.
How the agent solves it
Put the stakes directly in the task text: what must never happen, what is irreversible, and what runs against production data. The reviewers weight their search by what you tell them is expensive, so an explicit blast radius changes where they look. Ask for the failure that would be hardest to detect after the fact, not just the failure most likely to occur. Run it again after you fix what it found, because a fix to a high-stakes path deserves its own attack. Keep the objection list with the change as a record of what was checked.
What to run
1. Prompt
  Ask your coding agent: "List every irreversible effect of this branch and every place it touches money or permissions. Write it as one paragraph of stakes."
2. Command
```
vidbyte-cli runtime adversarial-team "<the change> Stakes: <the paragraph>. Find the failure that would be hardest to detect after it ships." --host codex
```
What you get
A review weighted by what is actually expensive, with a record you can point at later.
- Objections ranked around the irreversible paths instead of spread evenly across the diff.
- The silent-failure cases that would not show up in an error log.
- A second pass on the fixes, so the patch to a risky path is attacked too.
04
Your tests pass, but you suspect they pass for the wrong reason and you cannot say why. Maybe they mock the one thing that matters, or they depend on the order they run in, or they assert on a value that would be the same even if the code were broken. Writing more tests will not answer the question, because writing tests is not the same activity as doubting them. A suite can be completely green and still prove nothing about the behavior you care about.
How the agent solves it
Aim the team at the tests instead of the implementation. Ask what would still pass if the implementation were wrong, which assertions check incidental values, and which tests only pass because of ordering or shared state. A hostile read of a test suite is a different job from writing one, and giving it its own run keeps it from being an afterthought. Take each objection and try to break the code in the way it describes while the suite stays green. Every objection that survives that check is a test worth rewriting.
What to run
1. Command
```
vidbyte-cli runtime adversarial-team "Attack the test suite in tests/billing/. For each test, find a broken implementation it would still pass." --host codex
```
2. Prompt
  Paste each objection into your coding agent with: "Change the implementation so this test still passes but the behavior is wrong, then show me the diff."
What you get
A list of tests that were green for the wrong reason, with proof.
- Tests that would pass against a broken implementation, each with the breakage that slips through.
- Order-dependent and shared-state tests named explicitly.
- Assertions rewritten to check the behavior you care about instead of an incidental value.
05
You are the only reviewer available, and you also wrote the change. Whatever review happens is going to find what you already believe, because you are reading your own reasoning back to yourself. Rereading more slowly does not help, since the blind spot is in the framing, not in the reading speed. The change ships with exactly one perspective behind it.
How the agent solves it
Run the team before you review your own work, and read its objections first. The value is not that every objection is right; it is that none of them came from someone who spent two hours convincing themselves the design was good. Treat the list as the second reviewer you do not have. Go through it one objection at a time and either reproduce it or write down why it does not apply. By the end, the change has faced a perspective other than yours.
What to run
1. Command
```
vidbyte-cli runtime adversarial-team "I wrote this change alone and am its only reviewer. Attack the design decisions, not just the code." --host auto
```
What you get
A second perspective on work that otherwise would have had one.
- Objections to the design choices you made early and stopped questioning.
- A short written reason for each objection you dismissed.
- A change that has been argued with at least once before it ships.
06
A design decision keeps feeling wrong and you cannot name the objection. You have circled it for a day, and every time you try to write it down it comes out as a vague unease. You cannot fix something you cannot state, and you cannot dismiss it either, so it just sits there slowing every related decision. Asking a helpful agent gets you reassurance, which is not what you need.
How the agent solves it
Describe the design and ask the team for the strongest case against it. Reviewers instructed to attack rather than to help will name the objection you have been circling, usually as a specific scenario where the design produces the wrong result. Read the objections and look for the one that matches the unease. Once it is stated, you can decide on purpose: fix the design, or accept the risk and write down why. Either way the decision stops being a drag on the next one.
What to run
1. Command
```
vidbyte-cli runtime adversarial-team "Here is the design for the job queue: <design>. Give the strongest case against it as concrete failure scenarios." --host codex
```
What you get
A vague misgiving turned into a stated objection you can act on.
- The failure scenario behind the unease, in one sentence.
- Two or three weaker objections that are easy to dismiss on the record.
- A decision you made deliberately instead of one you kept postponing.

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.

Agent environment

Pricing

$0.25 per launch

runtime
local
one-time

Adversarial Team is a runtime: it runs on your machine, through a coding agent you already installed, against your own model account, so the reviewers see your real repository and nothing is uploaded to be reviewed. Vidbyte charges a one-time flat $0.25 per launch for the orchestration, which is more than the other runtimes because a review team is several agents rather than one session. Your model usage is separate and lands on your own provider account as usual. The charge is taken only after the CLI has confirmed your task, your host, and your working directory, so a missing host never costs you anything.

This agent is not live yet. The command already exists in vidbyte-cli and validates your setup, but the executor behind it has not shipped, so today it stops before it charges you or starts a reviewer. Setup is the same as for every other agent: install vidbyte-cli, log in with your Vidbyte key, add balance at the usage page, and run `vidbyte-cli runtime doctor` to confirm a supported host is on your PATH. The install prompt below walks your own coding agent through exactly those checks, and the launch command itself is what tells you the executor has shipped: it stops failing.

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 whether the agent has gone live.

```
git clone https://github.com/cerredz/Vidbyte-cli
cd Vidbyte-cli
python -m venv .venv && source .venv/bin/activate
python -m pip install -e ".[dev,codex]"
```
Installs vidbyte-cli, the command line every Vidbyte agent is started and tracked from. It is at version 0.1.0 and is not published to PyPI yet, so it installs from source into a virtual environment rather than with a bare pip install. Run `vidbyte-cli --version` afterwards, and if it prints a version number the install worked and the command is on your PATH.
Subcommands
-e
Installs the package in editable mode, pointing at the folder you cloned instead of copying it somewhere else. A later `git pull` in that folder updates the CLI without a reinstall. This is the install mode the CLI's own README documents.
".[dev,codex]"
Adds the optional extras on top of the base package. The codex extra carries the Vidbyte SDK's Codex integration, which every agent that drives Codex needs, and dev carries the build and lint tools from the README's development install. Git has to be installed, because the SDK revision is fetched from source.
```
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.
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.
```
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.
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.
```
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.
```
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.

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 wait for each answer: (1) what the change is supposed to do, stated as intent rather than as a description of the code, (2) what must never happen — the irreversible, the expensive, the thing that would page someone, (3) what I already checked myself, so the team does not spend its passes re-confirming it, and (4) what I suspect is weak, even if I cannot articulate why. Then write me the task text as one paragraph that instructs the team to attack rather than improve, and to report only findings that name the input or state that produces the failure. Give me the finished command as `vidbyte-cli runtime adversarial-team "<task text>" --host <host>`, and note that this agent's executor has not shipped yet, so the text is ready for the day it does.

Copy install prompt

Paste this into your own agent and it will check what is already installed and logged in, then walk you through only what is missing.

Set me up to use Vidbyte's Adversarial Team. Run the checks below yourself, in order, before you ask me anything, and let each result decide the next thing you say. Never ask me to paste an API key into this conversation.

1. Run `vidbyte-cli --version`.
   - If it prints a version, say so in one line and go to step 2.
   - If the command is not found, say: "It looks like vidbyte-cli isn't installed yet. Do you want me to install it for you?"
     - Yes: it is at 0.1.0 and not on PyPI, so install from source: clone https://github.com/cerredz/Vidbyte-cli, create a virtualenv, run `python -m pip install -e ".[dev,codex]"`, then re-run `vidbyte-cli --version`.
     - No: tell me the install is the one thing every agent needs, and stop.

2. Run `vidbyte-cli whoami`.
   - If it prints "Authenticated as", I am logged in. Go to step 3.
   - If it prints "Authentication is required.", ask: "You're not logged in yet. Do you already have a Vidbyte API key?"
     - Yes: ask me to run `vidbyte-cli login` in my own terminal. It takes the key at a hidden prompt and checks it before storing it in my keyring. Re-run `vidbyte-cli whoami` when I say it is done.
     - No: these two steps are browser-only, so give me one link at a time and wait. First https://vidbyte.pro/login, where Google sign-in creates the account. Then https://vidbyte.pro/settings/api, where I create a key that is shown once. Then have me run `vidbyte-cli login` myself.

3. Ask: "Have you already added balance to your Vidbyte account?" The CLI cannot read a balance, so ask rather than guess.
   - No or not sure: send me to https://vidbyte.pro/usage to add balance, and wait for me to confirm.

4. Run `vidbyte-cli runtime doctor`.
   - If the codex line says "not found", say: "Adversarial Team runs through the Codex CLI and this machine does not have it. Do you want me to install Codex?" Install it only if I say yes.
   - Then run `vidbyte-cli provider whoami openai`. If it fails, say: "Codex needs an OpenAI key and none is stored. Please run `vidbyte-cli provider login openai` in your own terminal, so the key never passes through this conversation." Wait for me, then re-run it.

5. Tell me: "You're set up for Adversarial Team. Vidbyte already lists it in `vidbyte-cli runtime list`, but the executor inside the CLI has not shipped, so the command stops before it charges you or starts a reviewer." Then stop, because setup is done and there is nothing to launch yet.

When every check passes, tell me what each one returned in one short list, then give me this command to start: `vidbyte-cli runtime adversarial-team "<the work to attack>" --host auto`.

Similar agents

Ensemble Agent
Pick this one instead when the work does not exist yet and the question is how to approach it.
Open agent page →
Persistent Agent
Pick this one instead when you already know what is wrong and want it actually fixed rather than catalogued.
Open agent page →
Persistent Researcher
Pick this one instead when the objection you need is about the outside world rather than about your code.
Open agent page →

Agents

One job, one workflow, one deliverable. See how Adversarial Team compares to the rest of the lineup.

Browse all agents →