What Does an AI Agent Cost? What to Budget for Building and Running One
What an AI agent realistically costs: what drives the one-off build, what you pay each month to run it, and when building it yourself beats hiring out. With a worked example.
What Does an AI Agent Cost? What to Budget for Building and Running One
"So what does an agent like that cost us?" is usually the second question in a first conversation. The first is whether it even pays off for the process in question. And my honest answer to the cost question is unsatisfying at first: there is no price tag. An agent that pre-sorts incoming requests costs something different from one that pushes orders from an ERP into HubSpot while doing math and checks along the way.
The question can still be answered, though, once you break it apart. Most people think of "cost" as a single number, and that is exactly what leads them astray. An AI agent has two very different cost blocks, and one of them gets overlooked in almost every first conversation.
Build once, run every month
The first block is the build: the work until the agent is in place and does its job reliably. That is a one-off investment. The second block is the running cost, meaning what you pay every month for as long as the agent works. Software that processes requests around the clock has an operation, and operations cost money.
Look only at the build and you get a surprise three months in. Look only at the few cents per month for the language model and you underestimate the effort that comes before it. I will walk through both blocks separately, because they are driven by completely different things.
What makes the build expensive or cheap
For the build, you are paying for time at the core. How much time depends on a few factors I can usually judge well in the first conversation.
The biggest lever is the complexity of the task. An agent that reads a request, assigns it to a category and drafts a reply is manageable. An agent that plans across several steps, takes different paths depending on the intermediate result and ends with an action that costs money or reaches a customer is a different league. Not because of the model, but because of the guardrails something like that needs, and because of the cases you have to think through and test.
The second lever is the connections. An agent is only as good as its access to the right data. If it hangs off a system with a clean, documented API, the connection is done quickly. If it hangs off a legacy system without docs, a database someone built ten years ago, or a tool that was never meant to have an interface, that is exactly where the work sits. Which connections are genuinely needed and where it gets tricky is often the biggest difference between two quotes that promise the same thing on paper. It works the same way for classic interfaces, which I covered in more detail in the piece on custom APIs and middleware for HubSpot.
The third point is less obvious: how well the process is already defined. If it is clear what should happen for which request, you build the agent along those rules. But if that knowledge lives in the heads of three people and contradicts itself, half the project is about describing the process cleanly in the first place. That is well-spent time, but it is time.
What you pay each month to run it
Now for the block that tends to get forgotten. An agent that runs creates ongoing cost in three places.
First, there are the model costs. Every time the agent calls a language model to understand or decide something, that costs a fraction of a cent up to a few cents, depending on the model and the amount of text. At a few hundred runs a month, that sits in the single or low double-digit euro range. At tens of thousands of runs it becomes a line item you have to watch and steer through your choice of model. A simple sorting step does not need an expensive top-tier model.
Then there is hosting. I orchestrate the logic with n8n, and that runs on a server. A small instance for modest volumes sits in the low double-digit euros per month. Anyone already running an n8n server for other automations usually has this cost already and simply puts the agent on top. How I use n8n as a foundation is on the n8n agency page.
The third item is the one rarely talked about and the one that adds up most over time: maintenance and monitoring. An agent is not a device you switch on and forget. Source systems change, an API gets an update, a new edge case shows up that nobody knew about before. It is not a permanent project, but it is not zero either. Depending on how critical the agent's work is, you plan a few hours per quarter or a small fixed item per month for it.
A worked example
Concrete numbers are more honest than ranges, so here is a worked example. Important: this is a constructed calculation for illustration, not a quote. Your numbers will look different.
Suppose a sales team gets around 400 requests a month through forms and email. An agent should read each request, briefly research the company, assign the request to a category, create or update the right contact in HubSpot and prepare a draft reply. Sending the reply stays with a human.
For those 400 runs, model costs come to roughly a low double-digit euro amount per month depending on the model. On top of that comes n8n hosting, also low double-digit, unless it already exists. Maintenance takes a few hours per quarter. So the running cost stays modest here; the noticeable effort sits one-off in the build, mainly in the HubSpot connection and in cleanly defining the categories and reply building blocks.
That is the typical pattern: for a clearly scoped agent, the monthly cost is small next to what the manual handling costs in time. The effort sits in the build, and the build is one-off.
Build it yourself or hire out?
A fair question is whether you can build this yourself. You can. The tools are available, n8n is open, and models are accessible to anyone through an API. I built my own assistant exactly that way, connected via WhatsApp to my CRM, email and tasks.
Building it yourself only shifts the cost. Instead of a fee, you pay with your people's time and a learning curve. Building the first agent means getting to grips with the interplay of trigger, model, tools and limits. For a technical team with time, that is a good route, especially for an uncritical process you can learn on. But as soon as the agent works in important places, the topics come up that you do not learn from a tutorial: what happens on an abort mid-run, how you prevent duplicate records, how you keep access tight and traceable.
My advice is undramatic. For a small, harmless use case to learn on, building it yourself is a sensible option. When the agent sits in a process where mistakes reach customers or cost money, it is worth having someone who has already brought such agents into operation safely. Not because the building is so hard, but because the safeguarding is what makes the difference.
When the investment pays off
In the end, the cost question can only be answered against the benefit. An agent pays off when it takes over a task that happens often enough, is clear enough for rules, and noticeably eats time today. For a task that comes up twice a month, the build is out of all proportion. For one done by hand a hundred times a day, the question is more why it has not happened yet.
If you want a concrete number for your case, I only need a rough description: which process, how often, which systems are attached. From that I can estimate where the effort sits and what running it would cost. Take a look at how I build AI agents, or drop me a line through the contact form about what runs most by hand at your place. You get an honest assessment, even if it sometimes turns out an agent does not pay off here yet.
Written by Joshua Kresse. At Pipewave I build AI agents and automations on top of HubSpot and n8n.