Wiring the fleet: tools, data and triggers

An agent is only as useful as the data it can reach and the event that fires it, so wiring is not the boring part of building a fleet; it is the part that turns five clever prompts into a system that runs without you.

You have the roster. Now you connect each agent to the apps and data it needs, decide what makes it fire, and make sure every agent reads from and writes to one shared source of truth rather than its own private copy. This is the bulk of the work, and it is mostly plumbing you can do in plain English with a visual builder.

What "wiring" actually means

Wiring is three connections per agent: an input it can fetch, an output it can deliver, and a trigger that starts it.

Think of each agent as a worker with an in-tray, an out-tray, and a bell. The in-tray is where it reads its input (a calendar, a CRM record, a folder, another agent's output). The out-tray is where it writes its result (a doc, a database row, a message to the next agent). The bell is the trigger that tells it to start. Get those three right for every agent and the fleet runs; get them vague and agents either never fire or fire on stale data.

The three trigger types

Every agent fires for one of three reasons, and naming which one keeps the fleet predictable.

1. Schedule. The agent runs at a fixed time: the research agent gathers Monday's market notes at 7am, the weekly-update drafter runs Friday at 4pm. Use schedule triggers for recurring work that does not depend on an external event.
2. Event. The agent fires when something happens elsewhere: a call ends, a form is submitted, a CRM deal changes stage. Use event triggers when the work must follow real-world activity, like a notetaker firing the moment a meeting finishes.
3. Hand-off. The agent fires because another agent finished and passed it the baton: the drafter completes, which triggers the reviewer. Hand-off triggers are how you chain the fleet, and they are the whole subject of the next chapter.

Decide a trigger type per agent before you build anything. An agent with no defined trigger is the most common reason a fleet sits idle.

The orchestration layer that holds it together

You do not wire agents to each other by hand; you put an orchestration layer between them that watches triggers, moves data, and calls each agent in turn.

For a visual, low-code approach, Make lets you draw the wiring as a flow of connected modules: a trigger module fires, a data module fetches the input, an action module calls the agent, and the next module routes the output onward. You can see the whole fleet on one canvas, which makes a broken connection obvious. For a self-hosted, more controllable option, n8n does the same with the data living on your own infrastructure, which matters when client data cannot leave your control. Both are mature orchestration tools, so you are composing proven plumbing rather than hand-coding webhooks.

The principle underneath both: the orchestration layer owns the wiring, not the agents. An agent should not know where its input came from or where its output goes; it just reads its in-tray and fills its out-tray. The orchestrator decides the routing. That separation means you can re-wire the fleet, swap an agent, or add a role without rewriting any agent's definition.

One source of truth, never per-agent copies

The fastest way to corrupt a fleet is to let each agent keep its own copy of the data.

When the researcher has one version of the client brief, the drafter another, and the scheduler a third, they drift within a day and the fleet starts producing work that contradicts itself. The fix is a single home for each kind of data that every agent reads from and writes to: one CRM record per client, one project folder per engagement, one task list. The orchestration layer points every agent at that shared home. If the drafter needs the brief, it reads the canonical brief, never a snapshot it cached last week.

This is the same discipline a real company runs on: one ledger, one CRM, one source for any given fact. Two copies guarantee drift, and drift in a client deliverable is how a fleet embarrasses you.

A worked example: one shared database ended an hour a day of copy-paste

Take a freelance web developer juggling six retainer clients, each with their own backlog, who was losing an hour a day just moving information between tools.

• Challenge. Tasks lived in client emails, project context lived in scattered docs, and status updates were copied by hand into each client's tool. Nothing fired automatically, so the developer was the manual wiring between every system.
• Approach. He stood up Make as the orchestration layer. An event trigger fired when a client emailed a request; a data module logged it into one shared task database; a scheduled trigger ran a weekly drafter that read that single database and produced each client's status update. Every agent pointed at the one task database, never a private copy. For the two clients whose contracts barred third-party data hosting, he ran the same flows on a self-hosted n8n instance so the data never left his server.
• Result. Manual information-shuffling dropped from about 5 hours a week to under 30 minutes, and status updates went out on the same schedule for every client instead of whenever he found time. Because all agents read one database, no two updates ever disagreed about a task's status again.

Pitfalls when wiring

• No trigger, so nothing fires. An agent you have to remember to run is still a tool. Assign every agent a schedule, event, or hand-off trigger.
• Per-agent data copies. Snapshots drift within a day. Point every agent at one canonical source for each fact.
• Wiring logic inside the agent prompt. If the agent knows where to fetch and send, you cannot re-route it without a rewrite. Keep routing in the orchestrator, in-tray and out-tray in the agent.
• Ignoring data residency. Some client contracts forbid third-party hosting. Use n8n self-hosted for those rather than breaching a contract to save setup time.

INTERVIEW EWOUD: Walk through the first real wiring you built between agents and a live data source. What broke first, the trigger, the data routing, or a copy that drifted, and how did you trace it?

With each agent connected to its data and a trigger, the fleet can run a single step end to end. The next move is to chain the steps so one agent's output becomes the next one's input. The next chapter covers hand-offs between agents.