A team reports that their multi-agent code review pipeline is taking twice as long as expected. Investigation shows that Agent A (assigned to 'security review') and Agent B (assigned to 'code quality review') are both independently scanning the same set of files for the same OWASP Top 10 vulnerability patterns and producing nearly identical reports. What orchestration failure is occurring and what is the correct fix?
Select an answer to reveal the explanation.
Short Explanation
It's like sending two different painters to paint the same room — both finish and hand you a bill, but the room only needed one coat. You've got duplicated effort because the task decomposition left overlapping scope. The fix is precise domain ownership: one agent, one clearly bounded responsibility, with shared artifacts for any common inputs.
Full Explanation
Duplicated effort is an orchestration planning failure, not a runtime execution failure. It occurs when the orchestrator assigns tasks to multiple agents without clearly delineating their boundaries, resulting in multiple agents performing the same work independently.
The option that identifies insufficiently specific task decomposition is the right one because the security-review agent and the code-quality agent were both scoped to include OWASP vulnerability checking, so their responsibilities overlapped. The correct fix is twofold: rewrite the task decomposition so scopes are clearly separated — the security-review agent handles SAST and CVE identification, while the code-quality agent handles code style, complexity, and maintainability — and produce shared artifacts, such as a single SAST scan output uploaded as a job artifact, that can be referenced by multiple downstream agents rather than triggering redundant full scans. This is the principle of agent isolation with shared read-only artifacts.
The under-powered runners option is wrong because runner size affects execution speed but does not eliminate duplicated work. Faster duplicated work is still waste. The total work performed is the same; it just completes sooner — and the reports still contradict or duplicate each other.
The GitHub Actions job caching option is wrong because job caching in GitHub Actions caches dependencies and build outputs between runs, across pipeline executions, not between concurrent agents within the same run. It does not prevent two agents in the same run from independently executing the same scan.
The merge-into-a-single-sequential-agent option is wrong because merging agents into a single sequential agent is an overcorrection that sacrifices the parallelism benefits of multi-agent architecture. The problem is overlapping scope, not the existence of multiple agents. Redefining scope preserves the parallel structure while eliminating the duplication.
The exam takeaway: when designing multi-agent task decomposition, each agent must have a clearly bounded, mutually exclusive domain. Shared inputs should be produced once and consumed by reference, not reproduced independently by every agent that needs them.