Building a Multi-Agent Orchestration System

Problem Statement

A growing SaaS company needed to automate their customer onboarding pipeline. The process involved document analysis, CRM updates, email sequences, and personalized setup workflows. Each step required different AI capabilities. No single model could handle the full chain reliably.

Context & Constraints

The client was processing 200+ new signups per week manually. Three full-time staff members spent their entire day on onboarding tasks that were repetitive but required judgment calls at each step. Budget was limited: they needed the system live within 6 weeks at under $5k total build cost. Existing no-code tools had been tried and failed at the document analysis step.

Approach & Architecture

We designed a multi-agent architecture where specialized agents handled discrete tasks: a Document Agent for intake analysis, a CRM Agent for data enrichment and routing, a Communication Agent for personalized outreach, and an Orchestrator Agent that coordinated the workflow and handled error recovery. Each agent connected to the relevant tools via MCP servers, giving them native access without middleware.

Implementation

The Orchestrator was built as a state machine with clearly defined transitions. Each agent received its context through structured handoffs, not raw conversation threading. MCP servers were built for Supabase (CRM data), Resend (email), and the client's proprietary document store. RAG was implemented for the Document Agent to reference the client's knowledge base when classifying incoming materials. The whole system deployed on Railway with environment-based configuration.

Results & Metrics

Onboarding time dropped from 45 minutes per customer to under 3 minutes. The three staff members were reassigned to higher-value work. Error rate on document classification was 2.3% (compared to 8% human error rate on the same task). Monthly cost: approximately $180 in API calls.

What Broke

The first version of the Communication Agent hallucinated product features that didn't exist. The Document Agent struggled with scanned PDFs that had poor OCR quality. The Orchestrator's retry logic was too aggressive and caused duplicate CRM entries during the first week.

What We'd Do Differently

We'd implement output validation on the Communication Agent from day one instead of adding it after the hallucination incidents. The OCR preprocessing step should have been a dedicated pipeline stage rather than embedded in the Document Agent. And the Orchestrator needed idempotency keys on every CRM write operation.

Key Takeaways

• Multi-agent systems need explicit handoff contracts between agents, not implicit context sharing
• MCP servers eliminate an entire category of integration bugs by giving agents native tool access
• Output validation is not optional for any agent that generates customer-facing content
• Idempotency in orchestration is a day-one requirement, not a nice-to-have