TL;DR
An owner buying an AI agent pays for three things: the build, the model and API usage it runs on, and the changes it needs after launch. Each moves for a different reason, so no single price fits all three. A fair arrangement fixes the fee for build work with written acceptance checks, passes usage through at cost where both sides can see it, names what a monthly fee covers, and prices changes one by one. Per-task and per-outcome prices fit only outcomes that are measurable and hard to game.
In this article
- An agent has three costs that move for different reasons
- One public brief drew quotes from $800 to $32,000
- Each pricing model hands a different risk to one side
- Model usage is the cost neither side controls
- Per-outcome pricing needs an outcome nobody can game
- What to agree before you sign
- Frequently Asked Questions
8 min read
Price each cost where the party that controls it can see it. Once the goal and acceptance checks are written down, the builder controls most of the build effort, so a fixed fee for that phase is reasonable. Nobody fully controls model usage, so it belongs on the bill at cost, with a cap and a monthly report. Most change after launch comes from the business and from vendors, so it is priced per change or from a named block of hours, and never hidden inside a flat fee that claims to cover everything.
An agent has three costs that move for different reasons
Here is one agent with its assumptions written out.
The build range is a little over two to one. Usage spans four to one, and it can move further without anyone touching the agent. Change spans sixteen to one. A price that is fair at the bottom of each range can be ruinous for one side at the top. That is the worry underneath both questions this article answers: in September 2026 a builder asked on the n8n subreddit how others add a margin on top of hosting, API and build hours, and whether maintenance belongs in the upfront fee or in a retainer.
One public brief drew quotes from $800 to $32,000
The buyer’s side of the same question is public. In May 2026 a physician who runs a small consulting practice posted a phased build on the n8n community forum: a self-hosted n8n and Postgres platform meant to run for years, with a daily canary test, an audit trail and documentation good enough for another developer to take over. They asked for a rough quote for the first two phases and whether builders preferred a monthly retainer, per-engagement fees or a hybrid.
By late September the thread held 90 posts. Replies that gave figures priced the same two phases at anything from $800 to $32,000. Most replies that named a model proposed a fixed price per phase plus a monthly retainer for monitoring and small fixes, at 300 to 1,250 dollars or euros a month where a figure was given. Several asked for a small paid discovery or architecture milestone first, some of them credited toward the build.
These are self-selected answers to one post, not market rates. What they show is that the number says less than the assumptions behind it. The reply with the highest range was also the one that listed backup and recovery, retry handling, the daily canary and handover documentation inside its first phase. Before comparing totals, a buyer has to compare scopes.
Each pricing model hands a different risk to one side
Public procurement rules state the trade-off plainly. The US Federal Acquisition Regulation says a firm-fixed-price contract “places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss”, while a time-and-materials contract “provides no positive profit incentive to the contractor for cost control or labor efficiency”, which is why it requires the buyer to monitor the work and set a ceiling price. Agent pricing inherits both problems and adds two of its own.
Who carries which risk
| Model | Build overrun | Usage swing | Change volume | Watch for |
|---|---|---|---|---|
| Fixed build fee | Builder | Not covered | Disputed unless scope is written | Padding, or a narrowed scope |
| Hours or time and materials | Buyer | Buyer | Buyer | No cap, no hours log |
| Flat monthly fee | Not covered | Whoever the contract names | Builder, until it quietly does less | Duties nobody listed |
| Per task | Builder | Builder | Builder | Fewer checks per task |
| Per outcome | Builder | Builder | Builder | A loose definition of the outcome |
| Usage passed through at cost | Not covered | Buyer, visibly | Not covered | No cap or alert |
Vendors already sell agents on per-task and per-outcome terms. Salesforce introduced Agentforce pricing at $0.10 per action in May 2025, for an exchange it said had cost $2 under per-conversation billing (Salesforce blog, “Flex Credits”, 23 May 2025). Intercom’s pricing page, checked 9 October 2026, charges $0.99 per outcome for its Fin agent and counts an outcome when a customer confirms the issue is resolved, does not ask for more help, or Fin completes a workflow, including handoffs (Intercom pricing). Those are products sold to many customers; a one-off agent has no such volume to average out bad months.
Model usage is the cost neither side controls
Usage and its price move for reasons outside the agent. Anthropic’s pricing page notes that its newer models use a tokenizer producing approximately 30% more tokens for the same text, with the exact increase depending on the workload (Anthropic pricing, checked 13 October 2026). Models also retire: Anthropic gives at least 60 days’ notice, after which requests to a retired model fail (model deprecations). One retirement in the agent’s first year would mean a migration, a rerun of the evaluations and possibly a different cost per run.
A builder who absorbs that inside a per-task price has to add a margin for the worst case, which the buyer pays even in good months. A buyer who pays usage at cost sees the true number and carries the swing. The second is usually fairer if three things come with it: the buyer’s own account or an itemised pass-through invoice, a monthly cap with an alert before it is reached, and a report of runs, tokens and cost per run. Choosing a cheaper model for simple steps is a design decision with its own quality trade-off; the article on evaluating quality, cost, latency and risk by task covers that choice.
Per-outcome pricing needs an outcome nobody can game
Paying only for results sounds like the fairest model, and it can be. The risk is what the builder is then paid to avoid. A UK Department for Work and Pensions evidence review of payment-by-results contracts found that a higher weighting on outcome payments can encourage gaming, and that providers tend to favour the easier cases (DWP, 7 October 2024). In an agent, the easy cases are the ones it resolves alone. If a hand-over to a person does not count, or a skipped check makes a run cheaper, the price rewards exactly the corners you hired someone not to cut.
Per-outcome pricing becomes reasonable when three conditions hold: a baseline of how the work performs today, a written definition of the outcome that both sides can check from records, and hand-overs and refusals counted as correct behaviour rather than lost revenue.
What to agree before you sign
- The goal, the success criteria and the acceptance checks for the build, in writing, before the build price is fixed.
- What the monthly fee covers by name: monitoring, incident response, dependency and model updates, small fixes, and the hours or count each includes.
- How a change request is estimated, approved and recorded before work starts.
- Who holds the model and API accounts, and the monthly cap and alert.
- What happens to the code, prompts, evaluations and documentation when the arrangement ends.
The questions to ask a consultant before you sign are written for coding-agent work, but most apply to an agent build too.
Eliyce publishes no prices for building or managing agents; scope, hosting, support and fees are agreed in writing per agent. What it does publish is the method: a written goal and acceptance checks before the build, and every later prompt, model or tool change specified, reviewed, tested against the same evaluations and recorded. Whatever the price model, that record is what lets both sides check it. If you are weighing an agent build and its upkeep, talk about your agent.
Frequently Asked Questions
How should building and then managing an AI agent be priced?
As separate costs. Build work with written acceptance checks can carry a fixed fee, usage can pass through at cost, management can be a monthly fee for named duties, and changes can be priced one by one. A single all-in number usually hides which of these it has guessed.
Which costs in an agent are fixed, which grow with usage, and which come from changes we cannot foresee?
Hosting and the management duties are roughly fixed per month. Model tokens, paid API calls and per-run services such as browser sessions grow with runs and with retries. Change comes from the business asking for more, from data and documents changing, and from vendors changing models or APIs. Some changes have advance notice; others are discovered through monitoring, so the contract needs a way to handle both.
Who should carry the risk of model and API usage swinging month to month?
Usually the buyer, at cost, because a builder who carries it has to price in the worst month. Keep it visible: itemised usage, a cap agreed in advance, and an alert at a set share of the cap, so a spike is a conversation before it is an invoice.
What should a monthly management fee cover, and where do per-task or per-outcome prices invite corner-cutting?
It should list duties, not promise “support”: who watches failures and cost, how fast incidents are looked at, which updates are included and how many hours of small fixes. Per-task and per-outcome prices invite cutting where a check, a retry or a hand-over to a person costs the builder money and earns nothing.
After six months, what record shows whether the price was fair to both sides?
Hours spent by type (build, incidents, changes, updates), every change with its estimate and actual effort, incidents with their cause, and monthly runs, tokens and cost per run. Compare them with what the fee assumed; if one side has consistently absorbed the gap, renegotiate the part that drifted rather than the whole arrangement.
