The thing worth noticing about n8n is not the visual canvas or the 1500+ integrations everyone screenshots. It is that the project treats "prototype to production" as the actual problem for AI agents, and spends its design budget on the parts that decide whether an agent survives contact with real work.
Most agent demos stop at the point where the model returns something plausible. n8n starts there and keeps going.
n8n's README makes one promise that matters more than it sounds: connect to OpenAI, Anthropic, Google, or open-source models and switch providers without changing your architecture. In practice that is the difference between an agent you can maintain and one you rewrite every time a vendor changes pricing or a better model ships.
If you have built anything real on a single model API, you know the coupling that creeps in. Prompt formats, tool-call schemas, token limits, and quirks leak into your code until the provider is load-bearing. Treating the model as a swappable node instead of a hard dependency is an architecture decision, and n8n makes it the default rather than an afterthought. The capability list is honest about where the work actually is. n8n calls out logic, tool use, human approvals, and full observability as first-class pieces of a multi-step workflow. Those four are what separate a notebook that worked once from a system you can put in front of a customer.
Human approvals are the tell. An agent that can , hand a decision to a person, and resume is admitting the thing most demos hide: you do not want a fully autonomous loop touching anything that matters until you have watched it behave. Building that into the workflow engine, rather than bolting it on later, is a choice you only make after running automation in production and getting burned.
The same goes for self-hosting with role-based access and audit trails. If your agent reads sensitive data, "just call the hosted API" stops being an option. n8n lets you run the whole thing on your own infrastructure, which is less exciting than a cloud demo and far more useful when compliance is in the room.
You can also drop into code when the visual layer runs out. JavaScript, Python, and npm packages are available inside a workflow, so the canvas is a starting point, not a ceiling. That matters because the last ten percent of any real integration is always the part no pre-built node covers.
n8n is not open source, and it does not pretend to be. It is fair-code under the Sustainable Use License: the source is always visible, you can self-host, and you can extend it with your own nodes, while commercial use has limits the license spells out. That is a deliberate tradeoff, and naming it plainly is more useful than the usual dance around the word "open."
For a builder the calculus is simple. You get source you can read, infrastructure you control, and a large library of existing integrations and templates to start from, in exchange for licensing terms you should read before building a business on top. Knowing that up front is worth more than a permissive badge that turns out to have fine print anyway.
Try it with one line, npx n8n, or a single Docker command, and you are looking at the editor in a minute. The interesting question is not whether the canvas is pretty. It is whether treating production concerns as the main event, instead of a follow-up, is how more agent tooling should be built. n8n is a large, well-supported argument that it is.
**GitHub:** [https://github.com/n8n-io/n8n](https://github.com/n8n-io/n8n)