INPUT — Use case: Workflow automation for client onboarding | ASYNC | PERSISTENT | HIGH | Databases + APIs + External Tools 1. AGENT ROLE DEFINITIONS • Intake Agent — collects and validates client data from forms and email. Authority: read/write to intake records only. Cannot create accounts or send communications. • Verification Agent — validates identity documents and business details against external registries. Authority: flag/approve intake records. Cannot modify client data. • Provisioning Agent — creates accounts, workspaces, and permissions across internal systems. Authority: write to provisioning APIs only. Cannot communicate with the client. • Communications Agent — sends welcome materials and schedules the kickoff call. Authority: outbound email/calendar only. Cannot alter account state. • Orchestrator Agent — decomposes the onboarding workflow, routes tasks, tracks state. Authority: task assignment and escalation. Cannot execute any end task itself. 2. COMMUNICATION PROTOCOL Message format: {Task_ID, Parent_Task_ID, Source_Agent, Target_Agent, State_Object, Confidence_Score, Timestamp}. State passes as immutable snapshots; each agent appends a delta rather than mutating shared state. Failure path: soft retry (same agent, 2 attempts) → re-check by Verification Agent → re-decompose by Orchestrator → human escalation to the onboarding manager queue. 3. TASK ROUTING LOGIC Decision tree: new record → Intake; validated record → Verification; verified → Provisioning; provisioned → Communications. Priority rules: contract-signed clients > trial conversions > inbound enquiries. Load balancing: queue-depth-based assignment with a 10-task per-agent ceiling before backpressure. 4. MEMORY ARCHITECTURE Short-term: per-client session cache holding the active onboarding state, cleared on completion. Long-term: client master records in PostgreSQL plus a vector index of onboarding interactions for semantic lookup ("has this client asked about SSO before?"). Retrieval triggers: Intake reads long-term memory on duplicate-client detection; Communications reads interaction history before drafting messages. 5. CONTROL AND GOVERNANCE Error detection: JSON schema validation on every message, checksum on state snapshots, SLA timers per stage. Retry logic: soft retry → hard retry (reassign to standby agent instance) → re-plan. Human-in-the-loop triggers: identity verification confidence < 0.8, any payment data handling, third consecutive stage failure. 6. LATENCY AND PERFORMANCE Parallel: document verification and workspace provisioning run concurrently once intake completes. Sequential: communications strictly follow provisioning success. Bottleneck risk: external registry API rate limits — mitigated with request caching and batch windows. Throughput target: 50 concurrent onboardings. 7. RISK AND STABILITY Cascade scenario: a malformed intake record propagating downstream — prevented by schema gates at every hop. Single point of failure: the Orchestrator — mitigated with a hot standby and persisted task ledger. Circuit breakers on all external APIs: open after 5 consecutive failures, half-open probe at 60s. 8. SCALABILITY ROADMAP Phase 1 (MVP): Intake + Provisioning + Communications, manual verification. Phase 2 (Scale): automated Verification Agent, parallel execution, monitoring dashboard. Phase 3 (Enterprise): multi-region queues, per-client SLA tiers, audit-grade logging. 9. OBSERVABILITY AND MONITORING Agent KPIs: tasks completed/hour, first-pass success rate, escalation rate. Failure metrics: error rate per stage, mean retries per task. Latency benchmarks: intake-to-provisioned < 4h, end-to-end onboarding < 24h. 10. EXECUTIVE SUMMARY Five specialised agents under one orchestrator turn client onboarding into a fault-isolated async pipeline. The critical risk is orchestrator failure, mitigated by a persisted task ledger with hot standby. The optimisation priority is automating identity verification, the slowest human-dependent stage.