Running Agents in an Adversarial Loop
- Context
- Four agent roles in an adversarial loop
- Role
- Fractional CPO. Led product and engineering
- Type
- Agent architecture, delivery systems, tooling
- Impact
- Three applications. Under a year. Autonomous


The problem
How does someone who is not an engineer build software in a mission critical environment and trust the output? People building MVPs and POCs ask this constantly. I had the same challenge with my own work. We were shipping at a velocity and volume far beyond my technical ability to verify every line.
An agent instance will not consistently check its own work. At one point, I had the same agent writing unit tests for its own output. The result was simply tests written to pass the existing code rather than code that failed tests. Its win condition was passing its own work.
What I did
I split the work across separate instances and gave each one a win condition that had nothing to do with the work it was checking. Research, design, dev and QA, each in its own working directory with its own protocol, hooks, memory and skills. I did not call it adversarial at the time. I told each one the work was not its own and to review it critically.
The agents pass work between each other in a loop. They make use of Trello via MCP. Each agent has their own column which holds the cards that contain context for a unit of work. Each card is used to carry the persistent work unit context. The outcomes, results and changes to that unit structured so any agent can pick it up cold. All agents use Playwright via MCP to verify the work the same way a person would. Telegram carried the inter-agent messaging, now replaced by Claude native inter-agent communication. Sometimes we flip back to Telegram on larger projects so I have better observability as to how the agents are collaborating.
It worked, and it kept working as I added layers. More layers meant more throughput at a higher quality.
What it produced
Most recently, three mission critical administration applications on one data spine. Covering everything from first contact to quoting, to administration and billing, in a federally regulated market. The data processes were architected HIPAA compliant from the ground up and hold up to SOC 2 scrutiny.
The team was data engineering, QA and QC, and myself on product, architecture and design. It was ambitious and nearly impossible to think that I could do this as a team of three in the timeline available. Yet we did.
For the last few months the loop has run autonomously 40 to 50 cards at a time. We shipped higher quality with fewer bugs, and the output holds up under actual human testing.
What I learned
- Today, with AI in the mix, the delivery system is everything. Designing the framework used to build a thing is now the primary skill. Getting this right or not, makes life easy or difficult.
- I found the key is to separate the roles to allow for specialization and focus, and in the end, adversarial win conditions. Natural, healthy friction makes for higher quality output.
- Almost everything I rearranged turned out to be a win condition pointing at the wrong thing. The models are so good now, high quality output comes down to us knowing what good looks like.