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 and Infographic
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. Duplicated effort in multi-agent systems happens when task decomposition leaves overlapping scope. The fix is precise domain ownership: one agent, one clearly bounded responsibility, with shared artifacts for any common inputs.
Full explanation below image
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.
Why B is correct: The root cause is that the task descriptions given to Agent A and Agent B were not mutually exclusive — both were scoped to include OWASP vulnerability checking. The correct fix is twofold: (1) rewrite the task decomposition so scopes are clearly separated — Agent A handles SAST and CVE identification, Agent B handles code style, complexity, and maintainability; and (2) produce shared artifacts (e.g., 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.
Why A is wrong: 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.
Why C is wrong: 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.
Why D is wrong: 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.