Agent Integration Architecture: Patterns That Scale

You have ten MCP servers running. CRM, Slack, Google Workspace, three internal APIs, a data warehouse, a project tracker, email, and a custom analytics platform. Agents need to use them: sometimes one at a time, sometimes five in a single workflow. How do you wire it all together without creating a spaghetti architecture that nobody can debug?

Three patterns answer this question. Each solves a different problem. Most production deployments use all three, layered by workflow type. Here’s how they work and when to reach for each.

Pattern 1: Hub-and-Spoke

Hub-and-spoke is the default architecture for multi-agent systems. A meta-agent (the orchestrator) sits at the center. MCP servers fan out as spokes. When a task arrives, the meta-agent decides which tools are needed, routes requests to the right servers, and assembles the results.

How It Works

The meta-agent receives a request: “Summarize this week’s pipeline changes and post the summary to #sales-updates.” It decomposes the task: read pipeline data from Salesforce (MCP server 1), compare against last week’s snapshot from the data warehouse (MCP server 2), generate a summary, and post it to Slack (MCP server 3). The meta-agent calls each server in sequence, passes context between steps, and handles failures at any point.

The meta-agent doesn’t do the tool-specific work. It orchestrates. Each MCP server handles its own authentication, rate limiting, and data formatting. The meta-agent reasons about what to do and in what order. The servers handle how.

Architecture

The structure maps cleanly to how Deep Agents operate in NimbleBrain deployments:

Meta-agent (orchestrator). Receives tasks from users, scheduled triggers, or other agents. Holds the conversation state. Decides which tools to invoke and in what sequence. Has access to Business-as-Code artifacts, schemas that define entities, skills that encode decision logic, context that provides background knowledge.

MCP servers (spokes). Each wraps one external tool or API. The meta-agent discovers available tools through MCP’s capability negotiation; it knows what each server can do, what inputs it expects, and what outputs it returns. Adding a new server expands the meta-agent’s capabilities without changing its code.

State layer. The meta-agent maintains task state: what’s been done, what’s pending, what failed. For long-running workflows (a lead qualification pipeline that runs over hours), state persistence ensures the agent can resume after interruptions.

When to Use It

Hub-and-spoke is the right choice when workflows cross multiple tools and require coordination. A lead qualification workflow that reads from HubSpot, enriches from an external data source, scores against business rules, and writes back to HubSpot, that’s a multi-tool workflow with dependencies between steps. The meta-agent manages those dependencies.

It’s also the right choice when you need centralized governance. The meta-agent is a single point where you can log every tool invocation, enforce access policies, and apply rate limits across the entire system. One audit trail, one policy engine, one place to answer “what did the agents do today?”

Hub-and-spoke is the pattern NimbleBrain deploys first in every client engagement. It handles 80% of enterprise workflows out of the box. The Recursive Loop: the BUILD, OPERATE, LEARN, BUILD cycle, naturally expands the spoke count over time, adding MCP servers as the agent’s domain grows.

Trade-offs

Hub-and-spoke introduces a single point of coordination. If the meta-agent fails, all workflows stop. Production deployments mitigate this with redundancy, multiple meta-agent instances behind a load balancer, each with access to the same MCP servers and state store. The meta-agent is stateless between tasks (state lives in the persistence layer), so any instance can pick up any task.

Latency is the other consideration. Every tool call routes through the meta-agent. For high-frequency, single-tool operations (checking a CRM record 200 times per hour), the orchestration overhead is unnecessary. That’s where direct-access comes in.

Pattern 2: Event-Driven

Event-driven architecture flips the control flow. Instead of an agent deciding when to act, events from MCP servers trigger agent workflows. A new Slack message, a CRM record update, a calendar event creation, a Jira ticket status change, each event can wake an agent and start a workflow.

How It Works

MCP servers subscribe to events from the tools they wrap. The Slack MCP server listens for new messages via Slack’s Events API. The Salesforce MCP server subscribes to Platform Events or Change Data Capture streams. The calendar MCP server polls for new events (or receives webhook notifications).

When an event arrives, the MCP server normalizes it into a standard format and publishes it to an event bus. Agents subscribe to event types they care about. A support agent subscribes to new messages in #support-requests. A pipeline agent subscribes to Salesforce Opportunity stage changes. A scheduling agent subscribes to calendar event cancellations.

The agent receives the event, loads relevant context (schemas, skills, prior state), processes it, and takes action, which might involve calling other MCP servers. A new support message in Slack triggers the support agent, which reads the customer’s CRM record (Salesforce MCP server), checks their contract tier (internal API MCP server), drafts a response, and posts it back to Slack (Slack MCP server).

Architecture

Event sources (MCP servers). Each server that supports events publishes them to a shared bus. Events include a type, a source identifier, a timestamp, and a payload. The MCP server does the translation work, converting a Salesforce Platform Event into a standardized event format that agents can consume without knowing Salesforce internals.

Event bus. A message queue or pub/sub system that routes events to subscribers. In NimbleBrain’s platform, this runs on the managed runtime. Smaller deployments use Redis Streams or a lightweight message broker.

Subscriber agents. Each agent registers interest in specific event types. The subscription is declarative: “wake me when a message arrives in channels X, Y, Z” or “wake me when an Opportunity changes to stage Closed-Won.” The agent processes the event and goes back to sleep.

When to Use It

Event-driven is the right choice for reactive workflows, things that should happen immediately when something changes. Customer support triage (respond to questions within seconds). Pipeline monitoring (alert when a deal moves to a risk stage). Compliance checking (validate new records against business rules as they’re created). Meeting prep (pull context when a calendar event is 15 minutes away).

The key characteristic: the agent doesn’t know when it’ll be needed. It waits for the trigger. This is fundamentally different from hub-and-spoke, where the meta-agent initiates all workflows.

Event-driven patterns are the second layer NimbleBrain adds to client deployments, typically in weeks 3-4 after the hub-and-spoke foundation is running. Common first event-driven workflows: Slack monitoring for support requests, CRM event alerting for pipeline changes, and calendar-triggered meeting preparation.

Trade-offs

Event storms are the primary risk. A batch import into Salesforce that creates 10,000 records fires 10,000 events. Without throttling and deduplication at the event bus layer, the subscribing agent tries to process all 10,000 simultaneously. The event bus needs configurable rate limiting and batch aggregation ,“if more than 50 events arrive in 10 seconds, batch them into a single processing request.”

Debugging is harder than hub-and-spoke. A hub-and-spoke workflow has a clear request-response chain. An event-driven workflow has an event, a subscriber, a processing chain, and side effects, tracing the full path requires distributed tracing infrastructure. Log correlation IDs at every step.

Pattern 3: Direct-Access

Direct-access is the simplest pattern. One agent, one MCP server, no orchestration layer. The agent calls the server directly for focused, single-tool operations.

How It Works

A specialist agent owns one domain and one tool. A CRM enrichment agent calls the CRM MCP server to read records, enrich them from an external source, and write back. A report generator reads from the data warehouse MCP server and produces formatted output. A document drafter reads context from Google Drive and creates new documents.

No meta-agent. No event bus. The agent has a direct connection to the MCP server it needs and does its work.

Architecture

Specialist agent. Defined with a narrow scope, one job, one tool, clear inputs and outputs. The agent’s skills are focused: “enrich lead records,” “generate weekly pipeline report,” “draft client update emails.”

MCP server. The same server used in hub-and-spoke or event-driven patterns. The difference is who calls it, a direct agent call instead of an orchestrated or event-triggered one.

Trigger. Scheduled (cron), manual (human invocation), or API-driven (another system calls the agent). The trigger is simple because the workflow is simple.

When to Use It

Direct-access is the right choice for high-volume, single-tool operations where orchestration overhead isn’t justified. An enrichment agent that processes 500 lead records per hour doesn’t need a meta-agent to decide what to do ;it knows exactly what to do, every time.

It’s also right for prototype and early-stage deployments. Before building a full hub-and-spoke architecture, start with a direct-access agent that proves value on one workflow. NimbleBrain’s first deployment at a new client is often a direct-access agent: one agent, one MCP server, one valuable workflow. Prove value first, then compose.

Trade-offs

Direct-access agents are isolated. They can’t coordinate with other agents or use tools outside their direct connection. If the workflow evolves to need multiple tools (it usually does), you either add MCP servers to the direct connection (making it less “direct”) or promote it to a hub-and-spoke workflow.

Governance is distributed. Each direct-access agent manages its own audit logging and access policies. With ten direct-access agents, you have ten places to check when something goes wrong. Hub-and-spoke centralizes this. Direct-access trades centralized visibility for simplicity.

How the Patterns Compose

Production deployments aren’t purely one pattern. They layer all three based on workflow characteristics.

Hub-and-spoke for cross-tool workflows. The meta-agent handles lead qualification (CRM + enrichment + scoring), customer onboarding (CRM + email + project management), and report generation (data warehouse + documents + communication). Any workflow that touches 2+ MCP servers routes through the orchestrator.

Event-driven for reactive triggers. New Slack messages wake the support agent. CRM changes wake the pipeline monitor. Calendar events wake the meeting prep agent. Events trigger workflows; the workflows themselves may use hub-and-spoke internally.

Direct-access for specialist operations. High-volume enrichment runs direct. Scheduled report generation runs direct. Single-tool maintenance tasks (archive old records, clean up stale data) run direct.

A typical NimbleBrain deployment at month 6 looks like this: one meta-agent orchestrating 8-12 MCP servers for complex workflows, three event-driven triggers (Slack, CRM events, calendar), and two direct-access specialist agents (data enrichment, report generation). The architecture evolved through Recursive Loop cycles, starting with a single hub-and-spoke agent in week 1 and adding patterns as the workflows demanded them.

Scaling Considerations

MCP server count. 5-15 MCP servers in the first year is typical. Each Recursive Loop cycle adds 1-2 as the agent’s domain expands. The registry at mpak.dev provides pre-built, security-scanned servers that skip the build step for common tools. Custom internal tools need custom servers, budget 1-3 days per server for well-documented APIs, more for undocumented or legacy systems.

Agent count. Start with one meta-agent and zero-to-two specialists. Add agents as workflow complexity demands it, not before. Every new agent adds governance overhead, state management complexity, and inter-agent coordination costs. Three well-configured agents accomplish more than ten poorly-scoped ones.

Infrastructure. MCP servers are lightweight, each runs as a single process with minimal resource requirements. The meta-agent is the heaviest component (LLM API calls, state management, context loading). The event bus adds infrastructure if you adopt event-driven patterns. NimbleBrain’s platform runs all of this on Kubernetes, but smaller deployments can run on a single server.

Failure handling. Every pattern needs a degradation strategy. Hub-and-spoke: the meta-agent detects unavailable servers and routes around them or escalates. Event-driven: the event bus retries failed deliveries with exponential backoff. Direct-access: the agent retries with backoff and alerts after N failures. The common principle: agents adapt to tool unavailability instead of crashing. This is the operational resilience that separates production deployments from demos.

Starting Point

Don’t design the full architecture upfront. Start with one hub-and-spoke agent, three MCP servers (CRM, communication, one internal tool), and a single workflow that proves value. Run it for two weeks. The Recursive Loop will tell you what’s missing: the second MCP server you need, the event-driven trigger that would save time, the specialist agent that should run independently.

The architecture emerges from operational reality, not from a whiteboard session. NimbleBrain’s Business-as-Code methodology encodes this emergence: schemas expand, skills refine, context deepens, and the integration architecture grows to match the expanding agent capabilities.

For the specifics of connecting to CRMs and productivity tools that these patterns depend on, see connecting to CRM and connecting to productivity tools.