A team designs a single 'super-agent' that, when triggered, reads the full repository, generates an implementation plan, writes all required code changes, runs the test suite, reviews its own output for quality, and opens a PR — all within one agentic loop. After three months, the team observes frequent mid-run failures, inconsistent PR quality, and difficulty diagnosing which step failed. Which architectural principle does this design MOST violate?
Select an answer to reveal the explanation.
Short Explanation
You built one mega-agent that plans, writes, reviews, and opens PRs, and that collapses separate failure modes into one opaque loop. You can't isolate what broke, and self-review isn't independent. Split the stages into specialized agents so each has its own feedback loop.
Full Explanation
The mega-agent anti-pattern is one of the most common architectural mistakes teams make when first adopting agentic systems. It feels efficient to chain everything together, but it violates single-responsibility in ways that compound over time.
The claim that the agent should not have write access to the repository is wrong. Write access is appropriate for an agent that creates code; the problem is architectural, not permissions-based. Removing write access would prevent the agent from doing its job.
The single-responsibility principle is the correct answer. When planning, implementation, self-review, and PR creation all occur in one loop, several problems emerge. Failure isolation is impossible: if the implementation step generates bad code, the self-review step is reviewing output from the same model with the same biases, so it cannot provide an independent quality signal. Mid-run failures discard all completed work, requiring a full restart. Observability collapses: you cannot tell whether the PR quality problem originates in planning, implementation, or review. Iteration is painful: improving the review step requires testing the entire pipeline. Specialized agents for each stage enable independent evaluation, parallel development, and targeted remediation.
The suggestion to use a smaller context window to avoid processing the full repository addresses a symptom but not the cause. Even with a focused context window, a single agent combining all roles will still have self-review blind spots and opaque failure modes.
The requirement that the agent must not open PRs autonomously and that all PR creation should remain human-driven is wrong because autonomous PR creation is a legitimate and useful capability. The problem is not PR creation autonomy; it is the architectural decision to combine all roles into one agent. A specialized PR-creation agent that receives reviewed, validated output from upstream agents is a sound design.