Substructure vs. n8n for AI agents
Checked August 7, 2026
n8n is for whole-company automation on a canvas: an AI agent node, a chat model and tools wired in as sub-nodes, and 500+ integrations that people who are not developers can drag in. Substructure is for developers: an agent is a file in your repo, it lives in Slack, and every step of the loop is open to your code.
| Use n8n when | Use Substructure when |
|---|---|
| The builders are not all developers | Developers define the agent in git |
| The work is integration glue with some AI | The agent is the product |
| 500+ drag-in nodes beat writing tools | MCP servers reach your real systems |
What Substructure does that n8n does not
- Keeps the agent in git. In n8n the agent is workflow JSON in n8n's database, and version control is gated to the Business tier.
- Installs Slack in one command. In n8n you create the Slack app, wire OAuth scopes and events to a webhook, assemble trigger, agent, memory, and post-message nodes, and keep thread context in Redis or Postgres yourself.
- Continues a run mid-loop. If an n8n instance dies, the run is marked crashed, and retrying is a button or an error workflow you build.
- Charges nothing per message. n8n's cloud meters executions, and a chatbot spends one per message.
- Is open source. n8n is fair-code under the Sustainable Use License, free to self-host internally, but not open source by n8n's own description.
Side by side
Building the agent
| n8n | Substructure | |
|---|---|---|
| The agent is | Workflow JSON in n8n's database | A file in your repo |
| Built by | Dragging nodes on a canvas | Writing config, reviewed in git |
| Version control | Business tier and above | Git, from the start |
| Models | About 18 providers, bring your own key | Any provider, one line |
| MCP | Client and server | Client, with auth held by the engine |
Running it
| n8n | Substructure | |
|---|---|---|
| Unit of execution | One run of the whole workflow | One step of the loop |
| Crash mid-run | Marked crashed; you retry it | The step resumes |
| Scaling out | Queue mode, with Postgres and Redis | One binary and SQLite |
Surfaces and price
| n8n | Substructure | |
|---|---|---|
| Slack | Your own app, plus five nodes | One command |
| Thread memory | Redis or Postgres you run | The engine |
| Approval | A wait node you wire | An engine feature |
| Licence | Fair-code | Open source |
| Price | Metered executions | Flat, bring your own key |
What you write
[agent.oncall]
llm = "openrouter"
model = "moonshotai/kimi-k3"
system = "You are the on-call assistant."
mcp = [{ id = "sentry", tools = { read_only = true } }]
[agent.oncall.slack]
name = "Oncall"subs apply deploys it. There is no canvas, which is a real limit for
non-developers and a real feature for teams who want agents in code review. Add
a worker URL and the engine sends every decision to your endpoint as JSON, one
step at a time.
Where n8n is the better choice
- Non-developers who need to ship automations. Nothing here competes with the canvas and 10,000 templates.
- Integration glue: syncing systems, cron jobs, notification plumbing.
- One tool for all of a company's automation, not only the agents.
- A very large community, so most questions already have an answer.
Questions
Do I lose the 500+ integrations? You reach systems through MCP servers instead, and the engine authorizes them.
Can non-developers change the agent? They can edit the prompt in a pull request. There is no canvas.
Can I use both? Yes. An n8n workflow can call the agent's API, and a worker can call n8n.
The quick start takes about five minutes.