agent-system-designlisted

# Agent System Design An agent system without explicit boundaries doesn't fail loudly — it fails by quietly running longer, costing more, or taking an action nobody would have approved if asked directly. This skill puts the boundaries in before that happens, not after an incident. ## Step 1 — Justify the architecture, don't default to it Decide single-agent-with-tools versus multi-agent orchestration based on an actual reason: genuine parallelism need, real specialization (different agents needing different tool access or context), or isolation (one agent's failure shouldn't corrupt another's state). Multi-agent orchestration adds real coordination complexity and failure modes — "it seemed like the more sophisticated choice" is not a justification, and a single well-scoped agent is often the right answer. ## Step 2 — Design memory/state explicitly State plainly: what's short-term (lives only in the current context window and disappears), what's long-term (persisted across sessions), what's shared across agents versus private to one, and — for shared state — what happens when two agents read stale or conflicting state. An agent system with no stated answer to "what does this agent remember and for how long" will produce behavior nobody can reason about after the fact. ## Step 3 — Scope tool access to least privilege, explicitly Every tool an agent can call should be an explicit allow-list decision, not blanket access to everything available. This is also the seam where