Introduction
Ask anyone using ChatGPT, Claude, or Gemini to build something non-trivial, and you’ll likely notice the same pattern: the first response sounds confident, the output looks plausible, and then the details fall apart. The instinct is to fix this through iterative prompting our prompt engineering. The user rewrites instructions until the model finally understands what they mean.
However, that approach treats the problem like a communication failure, and it’s actually a structural one. A single LLM call has no mechanism to question its own work, revisit assumptions, or iterate towards a better answer. It produces a draft and steadily moves on. Real knowledge work doesn’t happen this way — humans learn through iteration and friction, and the models we use should do the same.
To address the cognitive gap between what a user expects an AI to do and an LLM’s actual zero-shot capabilities, I constructed the OWA (Orchestrator, Worker, Antagonist) Agent Architecture. Today’s models have a staggering grasp of software engineering, audio and visual generation, and computer use, but human understanding is generally not held in zeroes and ones. We require systems that reflect the iterative nature of actual knowledge work.
OWA embeds that iterative cycle directly into the system: agents that produce the work, challenge that work, and manage the work plan effectively and iteratively until quality gates are met. OWA is framed around the idea that a stronger process matters more than the individual prompt.
The Problem with Sycophancy
I have had my fill of “yes-man” interactions. Statements like “You’re absolutely right!” do more to irritate me than correct my confidence or understanding. This tendency runs deep in almost all commercially available and open-source models today.
This is a well-documented architectural flaw. Research from Anthropic (Sharma et al., 2023, Towards Understanding Sycophancy in Language Models) highlights that LLMs are statistically predisposed to agree with a user’s stated beliefs or prematurely validate user-provided code, even when that code is objectively incorrect. The models are optimized for helpfulness and harmlessness, which often degrades into blind agreement.
Knowledge work is not done in a silo. Research cannot be successfully completed in a world where we are absolutely right all of the time. Humans learn through iteration and friction, and the models we use must do the same.
The OWA Framework Defined
In practice, most human interaction with AI occurs through chatbots or dedicated agents handling tasks. In a traditional environment, the human acts as an orchestrator of sorts and tasks a worker with a job. This falls apart when context is misunderstood, prompts are too broad, or specific guardrails must be met. LLMs are good at reading the beginning and end of a book, but are decisively bad at picking up the messy middle in long-running tasks involving large amounts of context.
OWA introduces a multi-agent adversarial loop to manage this exact problem.
The Orchestrator: Think of the Orchestrator as a project manager. They break down a user task into concrete requirements. The Orchestrator is the only agent permitted to communicate with the human user.
The Worker: The Worker might be developing code, generating an image, or summarizing research based entirely on the requirements passed down by the Orchestrator.
The Antagonist: The Antagonist happily guards the constraints. It is designed to give a matter-of-fact criticism or a simple “approved” in response to worker-generated content. It is explicitly instructed to never be positive, and thus, cannot be sycophantic.
Additionally, leveraging different foundational models among the three agents prevents any one organization’s self-bias or propensity to reaffirm its own ideas from affecting the final output. You might use an OpenAI model for orchestration, an Anthropic model for the worker, and a Google model as the antagonist to ensure true cognitive diversity.
Stateful Memory: Task-Lists and Lessons-Learned
The orchestration layer relies entirely on persistent state. Without stateful memory, an agentic loop will inevitably hallucinate or repeat the same mistakes infinitely. OWA manages this through two distinct memory structures bridging the Orchestrator and the central database.
The Task-List acts as the immediate queue. The Orchestrator uses this to track the lifecycle of every sub-task, ensuring nothing is dropped when the Worker’s context window is cleared between jobs.
The Lessons-Learned repository functions as the system’s long-term memory. When the Antagonist rejects a Worker’s output, the specific reason for failure is logged here. Before the Orchestrator sends the revised task back down to the Worker, it injects these documented constraints. This guarantees the system actually learns from the Antagonist’s feedback rather than simply guessing a different wrong answer.
The Utility Layer and Least Privilege
Beneath the active agents lies the Utility Layer, which contains the system’s tools: file systems, web browsers, external APIs, and secure databases.
A critical security and performance mechanism of the OWA architecture is its strict adherence to the principle of least privilege. Agents do not have blanket access to the Utility Layer. The Orchestrator provisions permissions dynamically. If the Worker is tasked with drafting a Python script, it is not granted database read/write access. If the Antagonist needs to run a unit test, it is granted access to a sandboxed execution environment, but nothing else. Agents have only the exact permissions required to access the utilities in flight for a given task, thereby heavily mitigating the risk of runaway executions or compromised data.
Coordination and Expansion: The Core Orchestrator
A single OWA triad is intended to address vertically sliced tasks like writing Python, testing Rust, image generation, or research retrieval. However, enterprise workflows require multiple specialized teams operating simultaneously. This architecture is designed to scale quadratically across these vertically sliced tasks, rather than a linear fashion, which would replicate the core problems addressed through the architecture.
In instances where multiple OWA teams operate, a Core Orchestrator maintains a directory of available specialized teams. This Core Orchestrator takes the initial context from the user, determines which domains are required to fulfill the request, and distributes the work to the respective team-level Orchestrators. Those local Orchestrators then break the work down into sub-tasks for their specific Workers and Antagonists.
This routing layer solves the “large-language problem” prevalent in generalist models. In a standard setup, the exact same model writing your backend services is also burdened with the parameter weights required to recite the entire Phylum Chordata family (that’s sharks, and yes - I googled it). No single worker or antagonist should be expected to have knowledge of the full depth of every subject. By focusing OWA teams on specific domain-organized tasks and equipping them only with the relevant tools, skills, and context, we force deep expertise over shallow generalism.
The Adversarial Loop in Action
The adversarial loop is the critical gap missing from traditional AI systems. As outlined by Dr. Andrew Ng in his framework for Agentic Design Patterns (Ng, 2024, DeepLearning.AI The Batch), systems relying on explicit reflection, planning, and multi-agent collaboration significantly outperform traditional zero-shot prompting. OWA natively automates this reflection phase.
The optimization of any LLM relies on speed, quality, and resources. In a traditional software project, raising any one of these areas requires a reduction or expansion of another. With LLMs, we move sprint cycles from weeks to minutes or hours. However, most environments involve the same interface as a chat window. If the user does not know what to look for when things go wrong, the output simply fails silently, while the LLM claims success.
OWA solves this through an asynchronous task queue.
Since the Antagonist cannot review until the Worker is completed, the task queue will send multiple tasks through this orchestration mechanism until all tasks are done. After the first task is handed off from Orchestrator to Worker, the Orchestrator begins defining the requirements for task 2. When context is cleared for the Worker, task 2 is passed on, while the Antagonist performs its critical analysis of task 1.
If the output does not pass the Antagonist’s critical review, feedback is sent directly to the Orchestrator. The Orchestrator reconstructs the task, adjusts it based on feedback via the Lessons-Learned memory, and places it back at the top of the queue for the Worker. This cycle continues until the job is right or a defined maximum of loops is reached.
From Concept to Production
Moving from concept to reality, my own projects enforce this loop.
Generally, users must rely on a bespoke tool to enforce this pattern in development through agent SDKs from the model provider or custom software. Agent skills on a local level can enforce the framing of different lenses for iterations, such as instructing Claude Code with subagent handoff instructions. In production, model gateways from cloud providers like Microsoft Azure, AWS, or Google Cloud provide a higher level of secure access to various model providers to truly enforce the OWA loop. Platforms like Vercel, Cloudflare, and GitHub also provide model gateways, while tools like PostHog, Sentry, and Pendo.io provide model and agent observability to help manage cost and monitor effectiveness.
The OWA pattern isn’t limited to software development. My thesis, The Effects of AI-Driven Adaptive Scaffolding vs. Static Worked Examples on Cognitive Load and Skill Acquisition, investigates whether AI-assisted scaffolding can outperform static faded examples in how people actually learn - think adaptive tutoring versus a textbook’s worked problems. The OWA loop operates on the AI-assistance side of that equation: rather than trusting a single model to generate the right scaffold for a learner, the adversarial cycle ensures the help itself is vetted before it reaches the user. In my own applications, such as Ember (www.ember-voice.com) and SpawnForge (www.spawnforge.ai), these loops reinforce quality across several domains: voice analysis, content aggregation, visual interaction, and performance. Locally, I leverage tools like Claude Code to enforce lightweight review cycles in developing software, along with an additional layer of observability, GitHub CoPilot, and Sentry Seer, to monitor agent outputs and ensure my prompt meets reality.
We need to graduate from hoping an LLM gets it right the first time. By constructing systems that inherently doubt and verify their own work, we can build AI that actually functions as a reliable tool.
For more: Follow me on LinkedIn, GitHub, or my personal site.