In a multi-agent design review system, architecture, security, and performance agents must critique each other’s findings without a permanent central boss for every message. The workflow still needs eventual aggregation for a final report. Which orchestration choice fits this collaboration style while remaining implementable?
Select an answer to reveal the explanation.
Short Explanation
You need peer-to-peer collaboration rounds for cross-critique, then an aggregation step to produce the final report under policy controls. That lets architecture, security, and performance agents challenge each other without a permanent central boss for every message. Rigid sequence blocks peer review, public social bus is insecure, and deleting memory kills collaboration.
Full Explanation
Peer-to-peer collaboration rounds for cross-critique, then an aggregation step under policy controls, is correct because multi-agent orchestration includes peer-to-peer, hub-and-spoke, and sequential patterns. Peer rounds enable cross-critique; final aggregation ensures coherent deliverable and policy enforcement. The rigid single-thread sequential pipeline with no peer critique paths is incorrect because pure sequence may underuse peer review. Unrestricted agents posting to public social network as the bus is incorrect because public networks are not enterprise control planes. One agent deleting the others’ memory after each token is incorrect because destroying memory prevents multi-agent reasoning. Define message schemas, auth, and termination conditions for peer rounds.