Single agents break in boring ways. You hit context limits, tools start interfering with each other, and the more capable you try to make one agent the worse it performs on any individual task. The solution most people reach for — just make the prompt bigger — is the wrong answer.

Multi-agent systems are the right answer, but they introduce a different class of problem: coordination, trust, and failure modes that are harder to debug than a bad prompt. This post is about the architecture patterns I’ve landed on after running multi-agent systems in a homelab environment where the stakes are real (it controls actual infrastructure) but forgiving enough to experiment.

Why Split Into Multiple Agents At All?

Before getting into patterns, it’s worth being honest about the tradeoffs. Multi-agent systems are more complex. They have more failure points. Debugging a chain of three agents is significantly harder than debugging one. You only pay that cost if you’re getting something back.

The things you get back:

Specialization compounds. An agent that only does Kubernetes operations can have a tightly scoped toolset, a precise system prompt tuned for that domain, and a shorter context because it’s not carrying around unrelated knowledge. It performs better on its job than a generalist agent would.

Context windows stop being a ceiling. Long-running tasks that would overflow a single agent’s context can be broken across agents that hand off summaries. An orchestrator can spawn sub-agents, collect their results, and synthesize without any one agent seeing the full problem.

Privacy routing becomes possible. This is underrated. If you have agents with different sensitivity levels — one handling ops metrics, another handling personal calendar and email — you can route them to different models. The ops agent can call an external API. The personal agent can run on a local model that never leaves the LAN. Single-agent designs make this impossible.

Blast radius shrinks. An agent that can only read Kubernetes state cannot accidentally delete a deployment. Least-privilege is easier to enforce when you have separate agents with separate toolsets than when you’re trying to gate everything behind one prompt.

Pattern 1: Orchestrator + Specialist Workers

This is the most common pattern and the one to default to. A routing agent receives user requests, determines which specialist should handle it, and delegates.

User → Orchestrator → [SRE Agent | Dev Agent | Life Agent | ...]
                           ↓
                     Task result
                           ↓
                     Orchestrator → User

The orchestrator itself does minimal work. It doesn’t need access to kubectl or shell commands. Its job is understanding intent and dispatching. The specialists have rich toolsets and domain-specific system prompts.

In practice, this means the orchestrator’s context is almost always short. It’s not accumulating tool call results — it’s reading summaries. The specialist agents can run with full context depth on their narrow domain.

One thing I’ve learned: resist the urge to make the orchestrator smart. Every behavior you add to the orchestrator is behavior that’s harder to test, harder to attribute errors to, and harder to swap out. Keep it thin. If you find the orchestrator doing complex reasoning, that reasoning belongs in a specialist.

Pattern 2: Peer Mesh with Shared Memory

Sometimes there’s no natural hierarchical decomposition. Tasks are overlapping, agents need to share context dynamically, and a fixed orchestrator would become a bottleneck.

In this pattern, agents share a memory store (vector database, key-value store, or a message bus) and can read each other’s observations.

# Example: agent writes observation to shared store
memory:
  key: "cluster/events/2026-03-22"
  value: "Node A showing elevated memory pressure (85%)"
  tags: [infrastructure, alert, node-a]
  ttl: 3600

A different agent doing capacity planning reads this observation without being explicitly told about it. It shows up as relevant context when it queries the store.

The risk here is coordination overhead. If every agent is reading everything every other agent wrote, you get noise. The solution is good tagging and TTLs — observations should expire when they’re no longer actionable, and tags should be specific enough that agents retrieve only what’s relevant to their current task.

I’ve found this pattern works well for monitoring scenarios where multiple agents are watching different subsystems and need loose awareness of each other’s state. It works poorly when you need deterministic handoffs or when the ordering of operations matters.

Pattern 3: Specialist Router with Tool-Level Delegation

This is a refinement of Pattern 1 where instead of routing entire requests, you route at the tool level. The “orchestrator” is really a tool-use layer that resolves which backend handles which capability.

From the model’s perspective, it sees a unified tool interface:

tools = [
    {"name": "check_cluster_health", "description": "..."},
    {"name": "check_vm_status", "description": "..."},
    {"name": "get_recent_deployments", "description": "..."},
]

But behind each tool, a different MCP server or agent is handling the call. check_cluster_health hits a Kubernetes MCP server. check_vm_status calls a Proxmox API. get_recent_deployments queries a git webhook store.

The model doesn’t know or care about this separation. It just calls tools. The routing is an infrastructure concern.

This is elegant but it has a cost: you can’t use agent-specific models this way. All tool calls go through the same model. If you need different models for different domains (privacy routing, capability differences), you need Pattern 1 or 2.

Handling Trust and Permissions

This is where most multi-agent designs go wrong.

The naive approach: each agent has the permissions it needs for the worst-case operation it might ever take. The SRE agent can delete pods because sometimes it needs to. The result is every agent being over-privileged for most of what it does.

The better approach: agents run at the lowest privilege tier that handles their routine work, with explicit escalation for destructive operations.

In practice, I split agents into read-only and elevated tiers:

  • Read-only agents handle monitoring, querying, and summarization. They can’t modify state. This is the right default for any agent that’s operating autonomously without human review.
  • Elevated agents handle restarts, scaling, and other state changes. They require explicit user confirmation before taking action.

The confirmation pattern matters. It’s not enough to put “always ask before deleting” in a system prompt — prompts can be overridden by a sufficiently convincing in-context argument. The safer approach is to require a specific --confirm flag or equivalent that the agent itself cannot provide unprompted.

# Agent cannot self-supply this flag — user must explicitly type it
./cluster-action.sh restart-pod my-api-pod --confirm

This creates a hard check that’s outside the model’s control. The model can draft the command and present it to the user, but execution requires a human keystroke.

Communication Patterns

How agents talk to each other matters as much as what they do.

Synchronous RPC (agent calls another agent directly and waits) is simple to implement and easy to debug. It’s appropriate when the sub-task needs to complete before the orchestrator can proceed. The downside: if the sub-agent is slow or fails, the orchestrator blocks.

Async with callbacks (agent dispatches a task and moves on, gets notified on completion) is better for long-running operations. An agent that kicks off a deployment check shouldn’t sit idle while it waits. It should move to other work and process the result when it arrives.

Event-driven (agents publish events, other agents subscribe) scales the best but is the hardest to reason about. Good for situations where the producer and consumer shouldn’t know about each other. Bad when you need predictable ordering or when debugging requires tracing causality through a chain of events.

For a homelab-scale system, synchronous RPC is usually the right choice. The coordination complexity of async messaging pays off at scale, and the debugging complexity is real. Start synchronous, add async only where you have a demonstrated need.

Failure Modes to Design For

Multi-agent systems fail in ways that single agents don’t.

Cascade failures: Agent A calls Agent B which calls Agent C. C times out, B returns an error, A receives an ambiguous result. Without explicit error propagation, the orchestrator has no idea what happened. Every agent-to-agent call needs to include structured error context that survives the chain.

Context poisoning: Agent A produces a plausible-but-wrong observation that gets stored in shared memory. Every subsequent agent that reads it makes decisions based on false premises. This is why TTLs on observations matter and why memory stores should track provenance.

Prompt injection through tool results: An agent queries an external source and that source contains instructions designed to hijack the agent’s behavior. This is the multi-agent equivalent of SQL injection. Treat tool results as untrusted data. An agent that summarizes a web page shouldn’t be able to override the system prompt it received from the orchestrator.

Runaway loops: Agent A asks Agent B to do X. Agent B asks Agent A to confirm. Agent A confirms and asks Agent B to do X again. Loop detection doesn’t exist natively in most frameworks. You need explicit cycle detection or depth limits on agent chains.

Model Selection Per Agent

Not every agent needs the most capable model. This matters for cost, latency, and privacy.

A rough heuristic I’ve landed on:

Agent typeModel tierWhy
Orchestrator / routerMid-tierRouting doesn’t need heavy reasoning
Domain specialistsMid-to-high tierComplex tool use needs more capability
Privacy-sensitive tasksLocal modelPersonal data never leaves the LAN
Simple lookup/retrievalSmall modelLatency matters, task is well-defined

Running a mix of local and remote models requires that your agent framework supports per-agent model configuration. Most do — it’s usually a one-line config change. But the architectural decision to route certain data to local inference should be made early, because it affects which agent handles which topics.

What I’d Do Differently

Start with the trust model, not the architecture. The first question should be: what can each agent do, and what requires human approval? Retrofitting permission boundaries onto an existing design is painful. Designing them in from the start is straightforward.

Invest in observability early. A single agent’s reasoning is visible in its context window. Three agents passing context between each other produces failures that are invisible without structured logging. Every agent-to-agent call should be logged with inputs, outputs, and timestamps. You will need this.

Resist the temptation to share everything. Shared memory feels like it reduces duplication. It also creates tight coupling between agents that were supposed to be independent. Before writing an observation to shared state, ask whether the consuming agent actually needs it or whether you could just pass it explicitly in the handoff.

Build the glass-break workflow before you need it. The “something is broken and I need an agent to take a destructive action right now” flow will happen. If your elevated-privilege path requires a three-step confirmation process that you haven’t tested, you will be copy-pasting commands manually at 2am. Test the whole path — including the confirmation UX — before you’re in an incident.

Multi-agent systems are worth the complexity, but the complexity is real. The patterns above aren’t theoretical — they’re the ones that held up when I actually needed them. The key insight is that agents should be as narrow as possible and as trusted as necessary: no more, no less.