A node-based workflow tool as an agent runtime

I’ve been surprised — repeatedly — by how far a node-based workflow tool goes as an agent runtime. Not “workflow tool that agents happen to trigger.” Actually the substrate the agent runs on. Sub-workflows become tools. The visual editor becomes the agent’s capability surface. Changing what an agent can do stops being a code change and starts being a workflow edit.

This is about that pattern, using n8n as the concrete example.

What n8n is doing in the platform

Two roles at once, and the two roles matter equally:

1. Integration workhorse

A webhook-triggered workflow is the concrete implementation of what the orchestrator thinks of as “an agent.” The chat orchestrator POSTs {chatInput, sessionId, email, ...} to a webhook URL. The workflow validates the JWT, hydrates the user profile, picks a system prompt, wires up chat memory (Postgres or Mongo), and hands off to an in-workflow LLM node with a set of tools attached.

Along the way it calls the notification service for progress updates, persists session state (mapped ticket numbers, active-agent hints), and handles escalation branches — “if the user needs a real ticket, create it here” — entirely inside the workflow.

The interesting move is that the orchestrator doesn’t know it’s talking to n8n. It’s just POSTing to an HTTPS endpoint that speaks the tool-invocation contract.

2. Tool provider for LLM agents

Some workflows are themselves MCP servers, via n8n’s mcpTrigger node. They expose sub-workflows as callable tools. Badging, passwordless enrollment, MFA exception, licensing, Zoom operations, PTO, Slack channel management — each is a sub-workflow reachable via executeWorkflowTrigger. Its description field is what the LLM reads to decide when to call it.

You end up with a graph of graphs: an in-workflow agent whose tools are other workflows.

The tool-call flow, end to end

Reading top-down:

user chat
  ↓
orchestrator (classifies intent)
  ↓  POSTs to a JWT-authenticated webhook
n8n workflow (the "agent")
  ↓  executes sub-workflows as tools
  ↓  or calls external SaaS through HTTP nodes
  ↓  or forwards to a downstream MCP server via mcpClientTool
  ↓  posts progress + completion to the notification service
notification service
  ↓  fans out to Slack / ticketing / email
user sees the result

Chat memory nodes (Postgres or Mongo) give the agent conversational continuity, keyed by sessionId. From the outside, this is indistinguishable from a hand-coded Python agent.

Why the pattern works

Three properties, in order of importance:

1. Non-engineers can extend the agent

This is the one I keep underselling. If you want to add a new tool — “book a conference room,” “look up a warehouse SKU,” “kick off a compliance workflow” — the change is a workflow edit. The engineer isn’t in the loop. The domain expert who knows how the process should work builds it directly.

There are limits — you don’t want a business analyst writing your authentication layer — but the surface area of “new tool for the agent” is exactly the surface area n8n is best at.

2. The plug-in ABI is a JWT-authenticated webhook

The orchestrator doesn’t care whether the thing behind a webhook is Python, an LLM chain, or a node graph. It sends a payload, it reads a response. Same contract everywhere.

Concretely: every workflow that plays the “agent” role validates the incoming JWT with a shared library node, extracts identity, and proceeds. Adding a new agent-type is a new webhook URL and a workflow. It’s the closest thing I’ve seen to an agent marketplace inside a single company.

3. Custom nodes wrap house concerns

Where you don’t want the workflow author to make security decisions, encode those decisions as custom nodes. CUSTOM.gateTool for permission gating. CUSTOM.textEncryptor for anything sensitive. CUSTOM.startWorkflowNodeTool for the “sub-workflow as tool” idiom.

The visual editor now enforces a policy: you can’t accidentally call an unencrypted endpoint, because the node that speaks to it is the encryption node. The security-critical code lives in a small number of well-tested nodes; the business logic lives in the workflow graph. That separation is more valuable than any code review.

The trade-offs — and there are some

I don’t want to oversell this. Real friction, in the order it bit me:

Debugging graphs is not debugging code. When a step fails, you’re staring at a node’s stdout tab, not a stack trace. It’s fine. It is not what a Python debugger is.
Version control is awkward. n8n workflows are JSON. They diff badly. Reviewing a workflow change in a PR is worse than reviewing a Python change. Best practice is small, isolated workflows; monolithic ones become unmergeable.
Testing is manual by default. You can write test workflows. In practice, most workflow authors don’t. If the workflow is doing something load-bearing, it wants proper tests, and the ergonomics push you away from writing them.
Performance ceiling. For light integration and fan-out, throughput is fine. For a hot path that fires thousands of times a minute per user, you don’t want a workflow engine — you want a service.

The right rule I’ve landed on: the workflow engine is for capabilities that change often and don’t fire often. The orchestrator itself is Python. The tools it calls are workflows. The line runs through change-frequency and QPS, not through “cool vs uncool.”

The underrated part

The most valuable thing about this pattern isn’t the visual editor or the ecosystem of pre-built nodes. It’s that the agent’s capabilities become a first-class artifact you can inspect, version, and share.

A workflow is a document. Someone can point at it and ask “what does this agent do, exactly?” and get a real answer. A hand-coded agent hides its capabilities inside if/else branches across three services. A workflow-based agent puts them in a diagram.

That readability compounds. New teammates can see how the agent works. Product managers can see the shape of a feature. Security reviewers can see what data flows where. That’s not a nice-to-have — it’s how a platform stays comprehensible as it grows.