n8n's new Agents let a model work out its own steps instead of following a fixed workflow, which is genuinely useful for open-ended jobs. But the thing that decides whether a business actually adopts an automation isn't how clever the agent is. It's whether the people entering data trust it, and whether the data stays somewhere they control.
n8n just shipped Agents: you describe a goal in plain language, give it tools and workflows to call, and it works out the steps itself instead of you laying them out on a canvas. It's a real shift in how you build with the tool, and I think it's a good one. But reading through it, the part that got me thinking wasn't the model deciding its own steps. It was everything underneath that: where the agent runs, what it's allowed to touch, and whether the people using it actually trust it.
The autonomy is the easy problem to solve
Give a current model a goal and the right tools and it's genuinely good at working out how to get there. That part of the announcement I believe without needing to see it myself. Models have been able to do this for a while now. The interesting question was never whether an agent could figure out the steps. It's whether a business is set up in a way where letting it do that is actually safe, and whether the team using it will go along with it.
n8n's answer to the safety half is sensible: you put your existing workflows in front of the agent as tools, so a workflow that adds a note to an account can only add a note to an account, no matter what the agent's instructions say. That's the right instinct. It's the same instinct I apply to every automation I build, just from a different angle. I don't ask what the agent can theoretically decide. I ask what happens if it decides wrong, and how far that mistake can travel before someone notices.
Where the data goes matters more than how clever the steps are
When I have to choose a workflow tool for a client, the first question I ask is not which one has more features. It's where the data goes. For one client who cared a lot about data privacy, I chose n8n specifically because it can run on their own server. The workflows run where the data already lives, and nothing passes through someone else's cloud to get processed.
That rules out a lot of convenient tools, and I think it's worth it every time. Once a business sends its customer data through a third party, it's very hard to take that back. Most businesses only realise what they agreed to when someone actually asks the question, and by then the data has already moved. An agent that's brilliant at working out its own steps doesn't help you if the first step it takes is sending a customer's details somewhere you didn't sign up for. That's not a criticism of n8n Agents specifically. Self-hosting is still an option here, which is exactly why I picked the tool in the first place. It's a reminder that the interesting decision in any of this is architectural, not conversational.
The team using it decides whether it works, not the model
I run a distribution business myself, serving a wide network of retailers across a large range of SKUs, so I get to be my own first client for anything I try. The first thing I automated there was the daily sales and stock report, because I wanted a clear picture every morning without asking someone to compile it by hand.
My team resisted it at first. Automating the report meant entering data in a new way, and to them that looked like extra work stacked on top of the old work. Nobody explained to them why it would be worth it, because I hadn't thought to. It only changed once they saw the report was actually saving them time, not adding to their list. That's the lesson I carry into every project since, and it applies just as much to an agent that can hold a conversation in Slack as it does to a fixed workflow. People don't resist automation because it's automation. They resist anything that looks like more work landing on them, so the benefit has to reach the person doing the data entry, not just the owner reading the report.
An n8n Agent that reads support tickets and drafts replies is a good example of where this matters. It's exciting because it can handle the odd cases a fixed workflow chokes on, someone asking why their usage dropped, where the next question depends on the last answer. But the team that has to live with it will judge it the same way my team judged the sales report: does this make my day easier, or does it just create a new thing to check on.
What I'd actually check before building on it
- Where the agent and its tools actually run, and whether that satisfies whatever you've promised your customers about their data
- Which tools are marked sensitive and require approval before the agent uses them, not just which tools it has access to
- Whether a workflow sits between the agent and anything that writes to a system of record, so the agent's mistake is bounded by what that workflow can do
- Whether the people who'll use it daily were shown what it saves them, before they were asked to change how they work
Say a clinic wanted an agent to triage inbound messages and decide whether to book, defer or flag a call to a nurse. The autonomy part, an agent reading a message and deciding which of three actions to take, is the bit n8n has just made easier to build. The part that decides whether it actually gets used is whether the receptionist trusts it enough to stop double checking every message it handles, and whether the clinic is comfortable with where that message data sits while the agent is reading it.
I don't think n8n Agents change any of that calculation. What they change is how much scaffolding you have to build yourself before you can test the idea. That's a genuine improvement. It just means the questions worth asking move even further away from what the model can figure out, and further towards what you're willing to let it touch, and who has to live with it once it's running.
