A subagent is designed to maintain a running summary across multiple invocations by storing state in a shared session object accessible to both the coordinator and the subagent. What is the primary risk of this design?
Answer: Shared state couples the coordinator and subagent, making the subagent non-idempotent and harder to retry or parallelize
Shared state between a coordinator and subagent destroys a key property of the hub-and-spoke pattern: subagent statelessness. A stateless subagent can be retried, parallelized, and replaced without side effects. A subagent with shared state may produce different results on retry (because the state changed), cannot be parallelized safely, and creates debugging complexity when failures occur.