Drive your n8n workflows from your Operator agent

People treat n8n and Operator.io as rivals because both get filed under workflow automation, but they sit at different layers and are better together than apart. n8n is a workflow engine. You draw a flow of nodes on a canvas, each node is a deterministic step, and the workflow runs the same way every time it fires. Operator, built on the open source OpenClaw framework, is an agent you talk to in plain language. The useful move is to point one at the other: keep your reliable plumbing in n8n and let the agent decide when to run it, what to feed it, and what to do with what comes back.

What n8n is good at

n8n is a node based workflow tool with hundreds of prebuilt integrations and a visual editor for chaining them. Its real strength is determinism. A published workflow does exactly what its nodes say, you get a run history of every execution, and you can build in retries and error branches. There is a large template library to start from, and because the workflow is a fixed graph, it is easy to reason about and audit when something needs to fire identically thousands of times.

It is also yours to run. n8n is source available under a fair code license, the Sustainable Use License, and the Community Edition is free to run on your own server for internal use with no cap on executions.

If you would rather not host it, n8n Cloud is a paid managed option: Starter runs about €20 a month for 2,500 executions, Pro about €50 for 10,000. Cloud bills per execution, meaning one full workflow run from trigger to finish counts as one unit regardless of how many nodes it passes through. Either way the workflows you build are the durable, repeatable backbone, the part you want to behave the same on Tuesday as it did on Monday.

If you have not built in n8n yet, Jono Catliff's beginner course covers the canvas, the node model, and putting together a first workflow, which is the layer your agent ends up calling.

What the agent adds on top

What n8n does not do is decide. A workflow waits for its trigger and then runs its fixed path. Operator is the part that reads a messy input, works out which workflow applies, fills in the inputs, fires it, and then interprets the result instead of just dumping it somewhere. You ask in a sentence and the model handles the judgment around the deterministic core.

Operator also keeps state in a real workspace of plain files. A job that needs to remember what it did last week reads its own CSV rather than depending on a record sitting inside one of your apps. The agent can hold context across runs while n8n handles the execution of each individual one. n8n's own AI Agent node can call models inside a workflow, but that reasoning lives inside the graph. Connecting Operator over MCP puts the agent outside the graph, where it can pick between several workflows, read your files, and message you on Telegram or Slack when something looks off.

How they fit together

The clean mental model is that each n8n workflow becomes a tool the agent can call. n8n stays the execution layer, the place where the reliable, repeatable steps live. Operator becomes the decision layer that chooses which of those tools to invoke and when. You are not rebuilding your workflows inside the agent, and you are not trying to make n8n reason. The agent reasons; n8n runs.

Connect n8n to Operator

Both sides speak the Model Context Protocol, an open standard for connecting AI clients to external tools. There are four ways to wire them together, and the right one depends on how many workflows you want to expose and how much control you want over the surface:

n8n ships MCP support in two of those forms, and the sections below take each method in turn.

Instance level MCP (recommended for most setups)

n8n's instance level MCP server is the path to reach for when you want the agent to discover and run workflows across your whole instance. Enable it under Settings, Instance level MCP, then toggle MCP access on for each workflow you want visible. Workflows with webhook, chat, form, or schedule triggers are eligible. The agent can search your enabled workflows, read their descriptions, and execute the one that fits.

In your Operator dashboard, open the MCPs page, click Custom Server, Add by URL, and paste the MCP connection URL from n8n's settings. Operator connects over streamable HTTP and registers each enabled workflow as a tool. As of early 2026, the built in MCP server can also create and update workflows from an AI client, though most Operator setups start with execution only. The n8n blog post on the MCP server walks through what that looks like in practice.

The difference between those two modes is worth being clear on, because it sets how much you are handing over. Execute only means the agent fires workflows you already built and proved, passing inputs and reading results, while the graph stays exactly as you drew it.

Letting it create and update workflows means it can change that graph, and a workflow is where your credentials live inside nodes and where an HTTP node can reach into your own network. That is a lot of reach to give a model that sometimes guesses.

The setup most people settle on keeps the agent on execution, exposes only the workflows you toggle on rather than the whole instance, and pairs that with an API key scoped to just what it needs. If you do want the agent authoring workflows, point it at a copy or a non production instance, read the change before you activate it, and keep your proven production flows out of its writable reach. n8n's run history still records every execution either way, which is the trail you check when something fires that you did not expect.

MCP Server Trigger (single workflow)

If you only need one workflow exposed, or you want to craft a specific MCP server inside a single graph, add an MCP Server Trigger node to that workflow. Attach the sub workflows you want as tools, set an authentication header so the endpoint is not open, activate the workflow, and copy its production MCP URL. Add that URL as a custom MCP server in Operator the same way. This approach keeps the MCP surface limited to one workflow, which is useful when you want tight control over exactly what the agent can call.

Webhook trigger (simplest single workflow path)

For a single workflow with no MCP setup, add a Webhook trigger instead. Copy its production URL, protect it with a header secret, and tell the agent to send a POST request with a JSON payload when it needs to kick off the run. The secret is what keeps that URL yours, since a production webhook with no header check runs for anyone who learns the address, not only your agent. This works well when there is one workflow and one button to press, and you do not need the agent to browse a catalog of options.

REST API (backend to backend)

n8n also exposes a public REST endpoint to execute a workflow by ID: POST /api/v1/workflows/{id}/execute with an X-N8N-API-KEY header and optional inputData in the body. The call returns an executionId immediately while the workflow runs asynchronously. This path suits a trusted backend that already holds an API key with workflow:execute scope. The API reference documents the full request shape. For agent driven use, MCP is usually simpler because the agent sees workflows as named tools rather than opaque IDs.

Put it to work

Once the workflows show up as tools, you talk to the agent and it does the dispatching. Start with something where you can check the result:

Run my "weekly-sales-report" n8n workflow for last week and summarize what it returned in three lines.

Then let it choose inputs and route between workflows on its own:

When I forward an invoice, pull the vendor and amount, run my "file-invoice" n8n workflow with those values, and tell me what it logged.

A common pattern is threshold monitoring. Your n8n workflow pulls a number from Stripe, Postgres, or a Google Sheet every morning and returns the result. The agent runs that workflow on a schedule, reads the output, compares it to a limit you set in a workspace file, and messages you only when the number crosses the line. The workflow stays deterministic; the decision about whether to bother you stays with the agent.

Another pattern is routing messy input. Someone forwards a support email, a screenshot of a receipt, or a Slack thread. The agent extracts the structured fields, picks the right n8n workflow from the MCP catalog based on the description, passes the values, and replies with what the workflow logged. n8n handles the CRM update, the Slack notification, or the database write. Operator handles the read of the situation.

Because Operator can run on a schedule and hold context in its files, the same setup becomes standing automation without you retyping instructions. The prompts library has starting points you can adapt for this kind of orchestration.

Splitting the work

Keep anything that must run identically, at volume, and with a clean audit trail inside n8n, where the run history and error handling already exist. Hand the agent the parts that need a read of the situation: which workflow fits this input, whether the result looks wrong, what to send you and when. Run a quick read only test first, confirm the agent is calling the workflow you expect with the inputs you expect, and only then let it act on its own. The split that works is n8n for the steps you have already proven and Operator for the call about when to take them.