8 min Read
Building Custom AI Agents with n8n and OpenAI
What it takes to wire an agent into the systems a business already runs, and why the integrations cost more than the model.
Nikhil Sharma
Key takeaways
- The model is the cheap part, both to run and to replace; what costs money is everything it has to touch
- An agent with no ability to fail loudly is a liability, because silent wrong answers are worse than visible outages
- n8n is excellent for orchestration and a poor place to put business logic that matters
- Give an agent the narrowest possible set of permissions, then widen deliberately, because the blast radius of a confused agent is whatever you granted it
The interesting part of an AI agent is never the AI. It is what the agent is allowed to touch, what happens when it is wrong, and how anyone finds out.
Almost every disappointing deployment I have been asked to look at got the model part right and the rest of it wrong.
Where the money actually goes
Model usage for a typical business agent runs to a few cents per interaction. Hosting n8n is modest. If someone is worried about the running costs of an agent that handles a few hundred interactions a day, they are worrying about the wrong number by an order of magnitude.
The cost is the integration surface. Every system the agent reads from or writes to is an authentication story, an error handling story, a rate limit story and a data mapping story. Adding a capability is cheap. Adding a system is not.
This is why a description of what an agent should do is not enough to price it. Two agents doing identical work cost wildly different amounts depending on whether the systems they touch have decent APIs or a login page and hope.
Orchestration in n8n, decisions in code
n8n is genuinely good at what it is for: connecting services, scheduling, retrying, moving data between things that were not designed to talk. Using it for that is a straightforwardly good decision.
The failure mode is gradual. A condition gets added to a node. Then a branch. Then a calculation. Eventually the rules that decide whether a customer is eligible for something live inside a visual workflow with forty nodes that nobody can review, test, or reason about after the person who built it moves on.
The line I hold is simple. If getting it wrong costs money, breaks a commitment, or has a regulator interested, it belongs in code with tests around it. n8n calls that code. It does not contain it.
Permissions before prompts
There is a lot of attention paid to prompt design as a safety measure. It matters, and it is the second line of defence, not the first.
The first is what the agent can reach. An agent with read access to three endpoints and write access to one queue has a bounded blast radius regardless of how badly it misunderstands a request. An agent with broad credentials because that was easier to set up is one confident misreading away from a genuinely bad day.
Start narrow. Widen when something specific requires it, deliberately, with someone thinking about the consequence. This is ordinary security practice and it gets skipped constantly in agent projects because the thing feels like a helpful colleague rather than a service account.
Silent failure is the real risk
When a normal service breaks, it stops, and monitoring notices. When an agent breaks, it usually keeps going and produces plausible nonsense, which looks identical to correct output until somebody downstream notices something odd.
That changes what you build first. Before adding capability, add:
- Full action logging. What it did, on what input, with what result, retrievable later.
- Confidence routing. An explicit path for I am not sure, ending at a person rather than a guess.
- Sampling. A human reviewing a slice of output regularly, forever, not just during launch week.
- A stop. One switch that halts it, known to more than one person.
If those are not in place, you do not have an agent in production. You have an agent in an unmonitored experiment that happens to be touching real customers.
Start with something boring
The best first agent is unglamorous: a task that is high volume, low stakes, currently done by a person who resents it, and easy to check. Categorising inbound messages. Extracting fields from documents. Drafting a response for review rather than sending it.
You learn how your data actually behaves, where the edge cases hide, and how much oversight is genuinely needed, all while the cost of being wrong is a person correcting something. Then you widen.
Teams that start with the impressive high-stakes use case tend to discover all of the same lessons in a much more expensive setting.
Where to start
Pick the task, map the systems it touches honestly, decide what happens when it fails, and only then think about the model. If you want that mapped properly against your operation, with a real number attached, that is an MVP Roadmap.
FAQ
Quick answers to the most common questions about this topic.
Running costs are the cheap part. Model usage is typically a few cents per interaction and n8n hosting is modest. The build is what varies, because an agent is only worth having if it is wired into how your business actually runs, and that is set by the systems it has to reach rather than by the model behind it. I scope that in a paid MVP Roadmap engagement and give you a real number, credited against the build if you proceed.
How the MVP Roadmap worksUse n8n for orchestration, scheduling, retries and connecting services, which is what it is genuinely good at. Put decisions that matter, particularly anything involving money, eligibility or compliance, in code that can be tested and reviewed. A sprawling visual workflow encoding critical business rules is very hard to reason about six months later.
Constrain permissions first and prompts second. An agent that can only read from three endpoints and write to one queue has a small blast radius no matter how confused it gets. An agent with broad write access is one bad interpretation away from a bad afternoon, however carefully worded its instructions are.
Build the observability before the capability. Every action logged with its inputs, its reasoning where available, and its result. Confidence thresholds that route uncertain cases to a person. Silent failure is the characteristic risk here, because unlike a crashed service, a wrong answer looks exactly like a right one.
Usually not. These are integration and workflow problems with a model in the middle. Someone who understands your systems and has built reliable automation will get further than someone who knows a great deal about models and nothing about your stack.
Written by
Nikhil Sharma
Founder, DigiBenders
Twelve years shipping software, five of them leading a studio in New Brunswick. I build the software and run the marketing around it, which is an unusual combination and the reason most of my work arrives by referral. One person accountable, and everything ends up in your name.
You read the thinking
Now tell me what you are actually building.
If this was useful, the call usually is too. You describe the problem, I tell you what it takes and whether I am the right person for it.
Thirty minutes, no pitch
Honest read, including when the answer is no
Replies within one business day
Keep reading
