← Reddit

I run a paper-trading bot where Claude Opus is the Lead Engineer with veto power over a Gemini "Strategist." 270+ entry audit log of every disagreement. Sharing the architecture.

Reddit · Vortextgamer · April 30, 2026
A developer has built an autonomous paper-trading bot using a multi-LLM architecture where Claude Opus serves as Lead Engineer with veto power over a Gemini strategist, while a human commander retains final authority on deployments. Every disagreement between the two AI agents is logged in a "Strategist Codex" document containing 270+ entries, creating a friction-based design intended to replicate a real engineering review process rather than allowing unchecked agreement. The system proved valuable in practice, with Claude detecting actual implementation issues such as an assumed broker SDK field that did not exist and proposing alternative solutions.

Detailed Analysis

A solo developer's paper-trading bot project, shared to the r/ClaudeAI subreddit, has drawn attention not for its financial application but for its unusually rigorous multi-agent architecture — one that assigns Claude Opus 4 the role of Lead Engineer with explicit veto authority over a Gemini Pro "Strategist," while the human builder retains final capital authority as Commander. The system runs on Alpaca's paper-trading infrastructure and comprises roughly 4,900 lines of Python across five modules. What distinguishes the project is its enforcement of hard role boundaries: Gemini is confined strictly to thesis adjudication and cannot make implementation decisions, while Claude is responsible for writing code and auditing Strategist directives against engineering reality. Every disagreement between the two models is logged in a "Strategist Codex" document now exceeding 270 entries, with no entry ever deleted — including superseded positions, which remain in the file alongside their replacements and timestamps.

The practical value of this architecture is illustrated by a concrete example the builder shares: Gemini issued a directive to anchor a 14-day position-decay clock to a `Position.created_at` field in the Alpaca broker SDK. Claude, acting as engineer, inspected the live SDK via `dir(Position)`, confirmed the field did not exist, and implemented a state-side ledger instead — logging the doctrine update with an explicit rationale. In a subsequent architect review pass, Claude further refactored the implementation because the initial solution held a state lock across multiple broker calls. Both revision passes were recorded in the Codex. This sequence demonstrates the system's core thesis: friction between bounded agents surfaces integration failures during the design phase rather than in post-deployment debugging, replicating at least some properties of a formal engineering review process without requiring human reviewers at each cycle.

The architecture maps onto documented strengths of Claude Opus in agentic roles. Claude Opus 4 and its successors have been positioned by Anthropic as capable orchestrators in multi-agent pipelines — systems where a lead model must validate sub-agent outputs, enforce business logic, and maintain coherent state across extended autonomous workflows. The builder's choice to assign veto authority specifically to the engineering layer reflects a reasonable risk calculus: strategy errors that survive into implementation tend to be more expensive than implementation approaches that push back on strategy, and a model with deep code-execution capability is better positioned to detect the former. The extended reasoning durability attributed to Opus-class models makes them particularly suited to supervisory roles in long-running cycles like market analysis, where a single session may span many sequential decisions.

More broadly, the project represents an emergent pattern in advanced LLM usage: deliberate multi-vendor agent architectures designed to exploit the fact that two models from different organizations, trained on different data with different inductive biases, are less likely to share the same blind spots than a single model used in multiple roles. The builder explicitly frames this as the point — "a single LLM has no incentive to disagree with itself" — and the 270-entry disagreement log is offered as empirical evidence that the friction is real and productive rather than ceremonial. This mirrors a broader industry conversation about how to introduce genuine adversarial review into AI-assisted engineering workflows, a problem that single-model approaches structurally cannot solve regardless of model capability. The "bounded scope" principle the builder describes — where neither agent can override the other's designated domain — also echoes patterns in traditional software engineering, where separation of concerns between architecture, implementation, and business logic is enforced precisely because cross-domain authority tends to produce unreviewed decisions.

The project raises a design question the builder himself flags as unresolved: the "agreed too quickly" failure mode, in which both models converge on a flawed approach without generating a logged disagreement. This is arguably the harder problem. The Codex captures what the system knows it got wrong; it cannot, by construction, capture the cases where both agents were confidently wrong in the same direction. Addressing this likely requires either synthetic adversarial prompting — deliberately tasking one agent with finding fault in the other's output even when no disagreement arose organically — or periodic human audit of agreement clusters, where alignment without challenge becomes a signal of potential groupthink rather than correctness. The project's public documentation, including a nine-page architecture whitepaper on GitHub, positions it as a reference implementation for builders exploring similar multi-agent coordination patterns, and the questions the builder poses suggest an active interest in stress-testing the architecture's limits rather than merely demonstrating its successes.

Read original article →