Your AI Agents Are Fighting Each Other. Here's How to Actually Orchestrate Them

Three AI Tools. Zero Coordination. Total Mess.

Here's situation we see more often now. A business has built or bought several AI-powered tools over the past year. One agent handles customer support queries on the website. Another does data extraction from incoming emails and PDFs. A third drafts outgoing emails and proposals. All three cost money. All three sort of work.

But they don't talk to each other. A customer sends a support message, the support agent handles it, but the CRM doesn't update. Meanwhile the extraction agent is processing an email from the same customer and doesn't know there's already an open support thread. The drafting agent has no idea what the customer's recent history looks like. Nobody told it.

The result: duplicated effort, inconsistent context, and more manual cleanup than if you'd done it with no AI at all. The tools aren't bad. They're just running in isolation.

This is the state a lot of businesses are in right now. They've added AI point solutions without adding a layer to coordinate them.

Why Agents Without Shared State Break Down

Think about how a good human team works. A support ticket comes in. The support rep checks the CRM for context before responding. They log the outcome. The sales rep sees it the next morning before a call. Everything is in one place.

When AI agents operate without shared state, none of that happens. Each agent sees only what it was given at the moment it was invoked. It doesn't know what the other agents have done. It can't pass outputs forward. It can't receive context from a prior step.

So you get the support agent writing a response with no knowledge that this customer complained three times last month. You get the extraction agent pulling data from a document that the support agent already referenced in a thread the extraction agent doesn't know exists. You get the drafting agent writing a proposal email that contradicts something the support agent said earlier in the week.

None of this is the agents failing. It's an architecture problem. Agents need a layer above them that handles routing, state, and context passing.

What an Orchestration Layer Does

An orchestration layer is the coordinator. It sits above all your agents and does three things:

First: it receives events. Something happens (a form submission, an email arrives, a Slack message, a webhook from your booking tool) and the orchestration layer is the thing that gets notified.

Second: it routes. Based on what the event looks like, it decides which agent should handle it. Not all events need to go to the same agent.

Third: it passes outputs forward and logs everything to a central store. When an agent finishes its work, its output goes back to the orchestrator, which decides what to do with it (log it, pass it to another agent, trigger a human notification, update a shared record).

The tools for this: n8n and Make are both excellent. n8n is better if you want to self-host and have fine-grained control. Make is better if you prefer a visual interface and want faster setup. Either works. You're using them as the orchestration layer that all your agents report to and receive instructions from.

A Concrete Example: One Lead, Three Agents, One System

Here's how a coordinated setup looks in practice.

A lead submits a web form. They wrote: "Hi, we have a problem with our invoicing software and need help, also we're interested in your enterprise plan."

That message contains two things: a support request and a sales signal. Without orchestration, you pick one queue and deal with it, or you don't notice the sales signal at all.

With n8n as the orchestrator:

Step 1: The form webhook fires. n8n receives the submission.

Step 2: n8n routes. The workflow passes the message text to a classifier (a quick LLM call: "Does this contain a support request, a sales enquiry, or both? Return: support / sales / both"). The classifier returns "both."

Step 3: n8n spawns two parallel paths. One goes to the support agent (which has access to the help desk system, checks for prior tickets, drafts a response). The other goes to the sales intelligence agent (which looks up the company, checks their current plan, flags them to the sales rep with context).

Step 4: Both agents complete their tasks. Their outputs come back to n8n.

Step 5: n8n logs everything centrally. The lead's name, company, the message content, the support ticket created, the sales flag raised, and the timestamp all get written to a single row in a Google Sheet. That sheet is the shared state. Every agent reads from it and writes to it via n8n.

Step 6: n8n sends a summary. One Slack message to the relevant people: "New lead from Acme Corp: support ticket #4471 created, sales team flagged, history logged."

The human reads one notification and knows the full picture. Neither agent duplicated work. Both had access to the same final record. The shared Google Sheet means tomorrow, when the drafting agent goes to write a follow-up proposal for Acme Corp, it can read that row first.

The Shared State Layer

The shared Google Sheet is doing important work in this architecture and it's worth thinking about deliberately.

Every agent that runs should write its key output back to the central sheet. Not a wall of text but structured data: status, timestamp, what was done, any flags or scores produced. Think of it as the single source of truth that every agent reads before acting and writes to when done.

At 2:17pm on a Tuesday (actual time a client's workflow first ran in production), when the support agent checks the sheet before responding to a customer, it sees three prior interactions from the past month. Two were complaints. One was a refund request. The support agent now writes a response that's appropriately careful about tone, because it had context.

That context comes from the shared sheet, not from the agent's own memory. Agents have no persistent memory by default. The shared data store is what gives your multi-agent setup continuity.

What About the Agents Themselves

Some people reading this have built their own agents on OpenAI, Anthropic, or other platforms. Some have bought SaaS AI tools with APIs. Both work.

For custom agents: n8n calls them via HTTP request with the relevant context pulled from your central sheet. The agent does its work, returns a response, n8n writes the output back to the sheet.

For SaaS AI tools with APIs: same pattern. You're using n8n to coordinate when they're called, what context they get, and where their outputs land.

For SaaS tools with no API (things that only have a UI and no programmatic access): this is where the architecture breaks. If you can't call the tool via API, n8n can't orchestrate it. This is worth checking before you buy more tools. "Does this have a webhook or API?" is the key question.

The Routing Decision

The routing step in n8n is often the most interesting part to build, because you're essentially writing the decision logic that would otherwise live in a manager's head.

Simple routing: classify by keyword. If the message contains "invoice" or "payment," route to billing agent. If it contains "demo" or "pricing," route to sales agent.

Better routing: send the full message text to an LLM with a classification prompt. This handles nuance that keyword matching misses. Someone saying "I'm having trouble with my account and was wondering about upgrading" gets classified correctly as "both support and sales" rather than landing in neither queue.

The classification call costs fractions of a cent and adds maybe 3 to 5 seconds to the overall workflow. Worth it.

Common Failure Modes After You Build This

Agents that don't write back to the central store. You built the orchestration layer but the agents just return outputs to n8n and n8n doesn't log them properly. Weeks later, nothing has accumulated in the shared sheet. Fix this in the initial build, not retrospectively.

Orchestrator workflows that get too complex. You started with two agents. Now there are seven. The n8n workflow has 40 nodes. Nobody remembers how it works. Keep orchestration workflows modular. One main router workflow, separate child workflows for each agent integration. Link them via n8n's "Execute Workflow" node.

No fallback for low-confidence routing. The classifier isn't certain. It returns "unclear." The workflow doesn't know what to do so it drops the event. Build a fallback: anything with unclear classification goes to a Slack channel for human review. Don't let unrouted events silently disappear.

Stale context. The central sheet has data from 6 months ago. Agents are using old context to make decisions. Add a timestamp filter. When an agent reads context, it should only look at events from the last 90 days (or whatever window is relevant) unless there's a reason to look further back.

What to Build First

If you have two or more AI agents running independently right now, the highest-value thing you can add is the shared state layer. Start there. Set up the Google Sheet with consistent column definitions. Define what each agent needs to write and what it needs to read.

Then add the orchestrator workflow in n8n. Even a simple one: trigger fires, classifier runs, single agent is called, output logged. That's the pattern. You can extend it once it's working.

The orchestration layer doesn't make your agents smarter. It makes them coherent. And coherent is worth more.

If you want us to build this for you, book a free workflow audit at airtective.com