Every multi-agent system I'd seen before VORTEX had the same problem: the agents were smart, but the wiring between them was custom code that nobody wanted to maintain. HTTP calls between services, retry logic scattered across files, error handling that was really just console.log with extra steps. I built VORTEX's seven agents entirely in n8n — no glue code, no custom orchestration layer, no message broker. The connections between agents are just webhook calls declared in the workflow graph, and the failure handling comes for free.

Why n8n for Agent Orchestration

The alternative was building the orchestration layer in code — a Node.js service that received webhook events, called Groq, wrote to Firestore, and triggered downstream agents. I built a prototype of this. It was about 400 lines and immediately became the thing nobody wanted to touch.

The problems:

• Retry logic for Groq API calls had to be written manually
• Adding a new downstream step meant modifying the orchestrator and redeploying
• There was no visual representation of what the pipeline actually did
• Debugging a failed run meant reading logs, not looking at a graph

n8n solves all of these. Each agent is a workflow. Each workflow is a graph of nodes. Adding a step means dragging a node onto the canvas and connecting it. Retries are a checkbox on the HTTP node. The entire flow is visible without opening a file.

The Agent Structure

Each of the seven agents follows the same basic pattern:

1. Trigger node — either a Webhook node (Agents 1, 2, 3, 7) or a Schedule node (Agents 4, 5, 6)
2. Processing nodes — Code nodes for transformation, HTTP Request nodes for external API calls
3. Output node — either a Firestore write, a Respond to Webhook node, or both

Here's Agent 1 — the Behavioral Scout — which is the simplest and most important because everything flows through it:

Webhook Trigger
      ↓
Normalize Activity Atom (Code node)
      ↓
Write to Firestore (HTTP Request → Firestore REST API)
      ↓
Respond to Webhook (200 OK + atom_id)

The Code node does the normalization:

// Agent 1 — Normalize Activity Atom
const payload = $input.first().json;

const atom = {
  user_id:           payload.user_id,
  event_type:        payload.event || payload.event_type,
  feature:           payload.feature || payload.feature_name,
  session_mins:      payload.session_duration_mins ?? payload.session_mins ?? 0,
  teammates_invited: payload.teammates_invited ?? 0,
  api_calls_today:   payload.api_calls_today ?? 0,
  call_consent:      payload.call_consent === true,
  email_consent:     payload.email_consent !== false,
  plan:              payload.plan ?? 'unknown',
  timestamp:         new Date().toISOString(),
};

return [{ json: atom }];

After normalization, Agent 1 fires Agent 7's webhook URL synchronously and waits for the response before returning. Agent 7 handles all downstream routing.

Agent 7 — The Router

Agent 7 is the most complex workflow in the system. It's the only agent that calls other agents.

Webhook Trigger (from Agent 1)
      ↓
Decision Logic (Code node)
      ↓
      ├─ HOT_LEAD ──→ Call Agent 2 (HTTP Request)
      │               Call Agent 3 (HTTP Request)
      │               Fire Slack Alert (HTTP Request → Slack API)
      │               [if call_consent + HIGH urgency]
      │               Write VAPI flag to Firestore
      │
      └─ WARM_LEAD ─→ Call Agent 3 (HTTP Request)

      ↓ (both paths)
Update Lead in Firestore (HTTP Request)

The Decision Logic node reads intent_score and urgency from the atom, assigns a tier, and sets flags for which downstream agents to call. n8n's IF nodes handle the branching — one branch for HOT_LEAD, one for WARM_LEAD, the rest falls through to a simple Firestore status update.

One thing worth knowing about this pattern: Agent 7 calls Agents 2 and 3 via their webhook URLs synchronously. It waits for each response before continuing. This means the total pipeline latency is Agent 2 latency + Agent 3 latency + Firestore write time. With Groq running llama3-70b-8192, each LLM call takes roughly 1–1.5 seconds. Total pipeline time is around 4 seconds for a HOT lead.

The Scheduled Agents

Agents 4, 5, and 6 are structurally different from the webhook-triggered agents. They don't receive input — they pull data from Firestore on a timer, process it, and write results back.

Agent 4 — VAPI Voice Caller:

Schedule Trigger (every 30 minutes)
      ↓
Fetch Leads from Firestore (HTTP Request)
      ↓
Filter Eligible (Code node)
  - status: HOT_LEAD
  - call_consent: true
  - call_status: not 'called'
  - intent_score ≥ 80
      ↓
Fire VAPI Call (HTTP Request → api.vapi.ai)
      ↓
Outcome Webhook (waits for VAPI callback)
      ↓
Parse Outcome (Code node)
      ↓
Update Firestore (call_status + disposition notes)

The VAPI integration requires a call_consent: true flag in the Firestore lead document. Agent 7 sets this based on whether the original webhook payload included consent. If it's not set, Agent 4's filter step drops the lead silently — no call fires.

Agent 5 — Data Custodian — is the simplest workflow in the system:

TTL Cron (daily at 02:00 UTC)
      ↓
Fetch All Leads from Firestore
      ↓
Filter Expired (Code node — created_at > 30 days)
      ↓
Delete Lead (HTTP Request → Firestore DELETE)

It runs once per day, touches nothing else, and has no output other than the deletes. Agent 5 never interacts with Agent 4 or Agent 6 — all three scheduled agents are completely independent of each other.

Agent 6 — Social Intel Scraper

Agent 6 is the most interesting scheduled agent because it uses two external APIs in sequence:

Scraper Cron (every 6 hours)
      ↓
Build Jina URLs (Code node)
  - reddit.com/r/[product] search
  - youtube.com search results
      ↓
Jina Fetch (HTTP Request → r.jina.ai)
  Jina returns clean markdown from the scraped pages
      ↓
Groq Sentiment Analysis (HTTP Request → Groq API)
  llama3-70b-8192 extracts complaints, praise, feature requests
      ↓
Save to Firestore (product_intelligence collection)

Jina AI is doing the heavy lifting on the scraping side — it takes a URL and returns clean, LLM-ready markdown without any HTML parsing. The Groq node then runs sentiment extraction on that markdown. The output lands in a separate product_intelligence Firestore collection that the React dashboard reads independently of the leads data.

What Cascadeflow Added

Managing seven n8n workflows across a shared environment creates a specific problem: the webhook URLs that agents use to call each other are environment-specific. In development, Agent 1's webhook URL for Agent 7 is different from what it is in production. Keeping those in sync manually is how you end up with Agent 1 calling the production Agent 7 from a development environment.

Cascadeflow handles this by treating the agent graph as a first-class artifact. The connections between agents — which agent calls which, on what trigger — are declared in the Cascadeflow graph definition rather than hardcoded into individual workflow nodes. When you promote from dev to prod, the URLs resolve correctly for the target environment without touching the individual workflows.

It also enforces the topology constraint that keeps the system debuggable: leaf agents cannot have outbound edges to sibling agents in the same graph. If I accidentally wired Agent 2 to call Agent 3 directly, Cascadeflow would flag it before it ran.

The n8n Webhook Response Pattern

One non-obvious n8n behavior: when Agent 7 calls Agent 2 via HTTP Request and waits for the response, Agent 2 must use a "Respond to Webhook" node to return data synchronously. Without it, n8n returns a 200 immediately when the webhook fires, before any processing has happened. Agent 7 would then continue routing before Agent 2 had produced a classification.

// Agent 2 — must end with Respond to Webhook
Webhook Trigger
      ↓
Groq Intent Classification (HTTP Request)
      ↓
Parse Intent (Code node)
      ↓
Respond to Webhook   ← this is the critical node
  { intent_score, tier, urgency, primary_pain }

Every leaf agent that's called synchronously by Agent 7 ends with a Respond to Webhook node. Agents that run on schedule have no response node — they just write to Firestore and stop.

Takeaways

n8n eliminates orchestration glue code. Every HTTP call between agents, every retry, every conditional branch is handled by the workflow graph. The alternative — a custom orchestration service — is 400 lines of code that becomes the system's weakest point.

Scheduled agents should be fully independent. Agents 4, 5, and 6 share nothing with each other. They read from and write to Firestore, and that's their only coupling to the rest of the system. If Agent 5 fails, Agent 4 keeps running.

Consent flags belong in the data, not the calling agent. Agent 7 doesn't check call consent — it writes it to Firestore when it receives it from Agent 1. Agent 4 checks it when it's ready to call. This separation means consent logic is enforced at the point of action, not at the point of routing.

Respond to Webhook is not optional for synchronous chains. If any agent in a synchronous chain returns before processing is complete, the caller gets stale or empty data and the pipeline silently produces wrong outputs.

Closing

Seven agents, zero custom orchestration code. The wiring lives in the workflow graphs, the topology is enforced by Cascadeflow, and adding a new step means dragging a node, not editing a service. The thing I thought would be the hard part — connecting the agents — turned out to be the part that required the least code.