On our team we split the flow into six agents: scraper, classifier, context builder, summary writer, responder, and post-monitor. They never share a conversation; each pulls jobs tagged for it from a Postgres queue, locks the row with `SELECT ... FOR UPDATE`, hits a shared vector store for context, writes the result, and lets the orchestrator (n8n flow) enqueue the next job. We keep the prompts tiny and deterministic, so the only state is the job row and the vector hash. This async job-as-library + policy layer is the only architecture that scales; the thing that fails spectacularly is when we let them all talk on a single Slack channel, because they start racing to be decision-maker and race for tool calls. The trick was to treat every tool as a service call with capacity controls plus a watcher that unpicks deadlocks.