AI agent costs: compare the complete project, not just the subscription

An AI agent quote is meaningful only when you know what the amount buys. One proposal may include configuration, another may include usage and a third may assume that your team will prepare the documents, review every result and handle incidents. Comparing headline figures can reward the proposal that leaves the most work unpriced.

Start with a shared workload and a clear definition of an acceptable result. Then compare setup, operation and the human effort that remains. This guide uses invented currency units, abbreviated CU, so the calculations are not mistaken for market rates, salaries or an Edeverse offer.

The worked example concerns a fictional membership organisation preparing replies to administrative enquiries. The method also applies to a personal assistant, an independent professional's workflow or a small internal team.

Define a unit of work that someone can price

“Handle member support” is too broad. A more useful specification is: read an eligible enquiry, retrieve the applicable approved policy, prepare a reply in the required language and place it in a review queue.

State what is excluded. Complaints, payment disputes and requests needing confidential individual records may follow another route. Explain whether attachments must be read and whether the task ends with a draft or includes sending.

Add expected monthly volume, busy periods, the number of connected accounts and the required turnaround. A system for one user and one document set has different work from a shared service with distinct permissions and several languages.

Define acceptance before asking for a price. The reply should answer the request from the approved source, preserve relevant conditions, avoid unsupported commitments and be easy to review. “The agent produces a response” is not a sufficient acceptance criterion.

Give each supplier the same representative enquiry and expected output. This makes their assumptions visible and creates a common basis for later testing.

Separate setup, running costs and internal work

Setup can include process definition, document preparation, integrations, instructions, workflow construction, testing and handover. Ask which of those activities are included and which remain yours.

Running costs may include the platform, model usage, connected services, storage, monitoring and maintenance. Some are fixed, some depend on volume and some change in steps when a plan threshold is crossed.

Internal work includes preparing inputs, reviewing outputs, correcting errors, handling exceptions and maintaining approved information. It belongs in a complete comparison even when it does not appear on a supplier invoice.

Keep cash expenditure separate from a monetary value assigned to staff time. Releasing time can improve service or capacity without reducing payroll. A business case should not describe all valued time as money that will automatically leave the bank account less often.

For personal use, the same distinction applies. A tool may make a recurring task less tiring without creating an income increase or cash saving. That benefit can be worthwhile without being presented as a guaranteed financial return.

Use a common quotation checklist

Ask every supplier to address the following:

Area	Question to resolve
Source preparation	Who removes duplicates, identifies approved versions and sets access boundaries?
Delivered functions	Which outputs and operations are included?
Connections	Which accounts and exact read/write operations are covered?
Usage	What is the billable unit, and do retries count?
Operations	Who receives failures and restores the service?
Changes	What is a defect correction versus a paid enhancement?
Handover	Which instructions, workflows, code and documentation can be retained?
Exit	What can be exported, in which format and with what transition work?

Also request currency, taxes, billing period, commitment length and cancellation conditions. “Maintenance included” is incomplete without the covered incidents, service hours and limits.

Do not fill an “included” box from a demonstration. A capability shown during sales may not be part of the quoted deliverable. Ask for a written scope and an acceptance procedure that can establish what was delivered.

Work through a complete monthly example

Our fictional organisation receives 400 eligible enquiries each month. After the agent's configured processing, including retries, 320 drafts are accepted. The remaining 80 require manual rework. All 400 enquiries are eventually handled.

These are invented assumptions for the calculation:

• Setup: 2,400 CU, allocated over 12 months for comparison, or 200 CU per month.
• Fixed services: 120 CU per month.
• Usage: 400 first attempts plus 80 retries, at 0.10 CU each, or 48 CU.
• Review: two minutes for every enquiry, or 800 minutes.
• Rework: six additional minutes for each of the 80 rejected drafts, or 480 minutes.
• Internal time value: 24 CU per hour, an assumption rather than a salary benchmark.

Human work totals 1,280 minutes, or 21 hours and 20 minutes. At the assumed rate, that is 512 CU. The complete monthly comparison cost is therefore:

200 CU setup allocation + 120 CU fixed services + 48 CU usage + 512 CU human work = 880 CU.

The model bill is only one part of the total. Excluding review and rework would make this example appear much cheaper without changing the work the organisation must actually do.

Choose the denominator that answers your question

Two ratios are useful, but they answer different questions.

The total cost divided by accepted agent drafts is 880 ÷ 320 = 2.75 CU. This allocates the whole workflow cost across the drafts accepted from the agent, including the burden of unsuccessful cases.

The total cost divided by all enquiries eventually handled is 880 ÷ 400 = 2.20 CU. This includes cases completed through manual rework.

Neither is a universal “price per answer”. Label the denominator whenever you compare proposals or reports. A supplier counting generated responses and a team counting accepted results may produce very different numbers for the same workload.

Also distinguish unique requests from operations. A single request can involve a search, several model calls and a retry. Those operations may be billed differently. Ask for an example billable journey through a normal request and through one that initially fails.

Compare with a realistic manual baseline

Assume, for illustration, that handling an enquiry manually takes seven minutes. For 400 enquiries, that is 2,800 minutes, or 46 hours and 40 minutes. At 24 CU per hour, the valued manual baseline is 1,120 CU per month.

Against the 880 CU assisted comparison cost, the difference is 240 CU per month. Human time falls by 1,520 minutes, or 25 hours and 20 minutes, under these assumptions.

That is a modelled difference, not a demonstrated saving. It assumes that the workloads are comparable, that the review timings hold and that no uncounted work has been transferred elsewhere.

Over 12 identical months, the assisted comparison totals 10,560 CU, including the full 2,400 CU setup allocation. The manual baseline totals 13,440 CU. Real adoption may involve ramp-up, lower early volumes and additional changes, so a forecast should model those rather than simply multiplying an optimistic month by 12.

Keep cash timing separate from cost allocation

Allocating setup over 12 months helps compare alternatives. It does not imply that the supplier accepts 12 monthly payments.

If the invented setup amount is paid upfront, first-month technical expenditure is 2,400 + 120 + 48 = 2,568 CU, before any applicable taxes. The 200 CU monthly allocation in the comparison is not an additional payment on top of that upfront amount.

Human time remains a separate budget question. Some may be an existing salary cost; some may require paid external review; some may displace other work. Explain which applies instead of presenting one universal cash-flow figure.

For subscriptions, check whether the advertised monthly equivalent requires annual payment. For a usage allowance, check what happens when the limit is exceeded. A low monthly headline can hide a larger commitment or an important variable cost.

Use a simple timeline showing when money is due and when useful output is expected. This can reveal a practical affordability problem even when the long-term comparison looks favourable.

Test the assumptions that could reverse the decision

Now change the fictional example. Suppose only 240 drafts are accepted and 160 require manual rework. Assume 160 retries rather than 80, while initial review still takes two minutes per enquiry.

Usage becomes 560 operations × 0.10 CU = 56 CU. Review remains 800 minutes, while rework becomes 960 minutes. Total human work is 1,760 minutes, valued at 704 CU. Adding setup allocation and fixed services gives 200 + 120 + 56 + 704 = 1,080 CU.

The difference from the 1,120 CU manual baseline is now only 40 CU per month. The technical workflow may still function, but the value case is much weaker.

Vary other assumptions too: request volume, attachment length, languages, review time, incident frequency and the number of connected accounts. For high volume, check whether a pricing threshold causes a step change rather than a smooth increase.

Use ranges until the pilot provides credible measurements. A precise-looking spreadsheet built from uncertain assumptions is still uncertain.

Understand what the provider actually counts

A “request” may mean a user question, model call, search operation or workflow execution. “Credit” may refer to something else entirely. Ask the provider to define each unit in the plan you are considering.

As a concrete current example, n8n's pricing page checked on 21 October 2026 distinguishes monthly workflow executions from Assistant credits. Those are not interchangeable measures of consumption. This example illustrates how to read a pricing structure; it is not a recommendation or a lasting price quote. Source: n8n pricing.

For model services, confirm how the chosen offer handles input, output, long documents, cached material or other applicable units. Do not assume that two products advertising “AI messages” count them the same way.

Check whether development usage is included. Testing, evaluation and fixing failures can consume resources before the service produces useful live results. The pilot budget should include that work rather than treating it as free preparation.

MCP, an API connection or a no-code builder does not determine a universal operating price. The actual hosting, services and operations behind the integration still need to be priced.

Normalise proposals before comparing their totals

Imagine two fictional offers without attaching invented commercial prices. Offer A produces answers in its own chat interface and expects your team to prepare the documents. Offer B creates drafts in your existing tool and includes preparation of a limited source set.

Before comparing, ask what it would take to reach the same accepted outcome. Does Offer A need another integration? Does Offer B include only a small source volume? Who maintains both connections? Is human review priced in either case?

Use a gap column rather than immediately declaring a winner. A cheaper offer may be suitable if you do not need the additional functions. A more complete offer may still omit an important ongoing responsibility.

Ask suppliers to identify assumptions explicitly. “One connected account” may not include a shared mailbox. “Multilingual” may mean generation in several languages without translated approved source material. “Monitoring” may mean an alert, not investigation and recovery.

Comparability comes from a shared scope and evidence, not from forcing different services into the same marketing label.

Distinguish prototype, pilot and daily operation

A prototype demonstrates that an idea can work on selected examples. A pilot tests a bounded real-world scope with representative cases and measurable effort. Daily operation adds responsibility for continuity, changes and failures.

Ask which stage the quotation covers and what is required to move to the next. A prototype price may not include difficult attachments, user-specific permissions, duplicate handling or a recovery procedure.

You can structure the project around concrete deliverables: task definition and test set, first end-to-end route, representative pilot and an expansion decision. This does not guarantee lower cost, but it makes each commitment easier to evaluate.

Clarify rights to the work produced. Instructions, workflows, code, configuration and documentation may be important if you later change supplier. A working demonstration inside one provider's account is not the same deliverable as a maintainable system your organisation can operate.

Calculate an illustrative break-even point carefully

In the original example, recurring technical costs excluding setup are 120 + 48 = 168 CU per month. Valued human effort falls from 1,120 to 512 CU. The modelled difference before allocating setup is therefore 1,120 − 512 − 168 = 440 CU per month.

Dividing the 2,400 CU setup cost by 440 gives approximately 5.45 months to offset that setup cost in this valuation model, if every assumption remains constant.

This is not guaranteed cash payback. It values time that may not represent avoidable spending and assumes immediate stable usage with no further costs. If initial months are spent on adjustment or the freed time has little practical use, the result changes.

Use the calculation to identify which assumptions matter, not to manufacture certainty. A pilot should establish the acceptance rate, complete review effort and actual volume needed to improve the model.

Price maintenance against the changes you expect

List likely changes over the next year: new source documents, revised categories, staff departures, account permission changes, integration updates and new reporting needs.

Ask which are included in maintenance and which require a new estimate. A defect correction is different from adding a new language or channel. A supplier should be able to explain how that distinction is made.

Identify the internal owner as well. Even when technical maintenance is outsourced, someone must approve source changes and decide whether outputs remain correct. That responsibility cannot be priced away by calling the system autonomous.

Agree on a spending boundary and a review process for additional work. Unexpected costs are easier to control when the team knows which changes require a new decision before implementation.

Make the purchasing decision from pilot evidence

At the end of the pilot, compare the same workload, accepted outcome and complete cost across options. Include a narrower or manual alternative. The right decision may be to automate only the routine categories and keep exceptions with people.

Retain the assumptions and the measurements that replaced them. Review costs when volume, quality or the service scope materially changes. A subscription that was economical for one task mix may be less suitable after the work changes.

The useful question is not whether an AI agent has a low headline price. It is whether the complete arrangement produces an acceptable result at an understood cost, with responsibilities you can maintain.

Frequently asked questions

Is there a standard price for a custom AI agent?

No single price covers every scope. Sources, integrations, permissions, volume, review and ongoing support all affect the project. Define a representative task and acceptance criteria before comparing quotations.

Does the setup price include usage?

Not necessarily. Ask separately about platform fees, model consumption, connected services, testing and maintenance. Check any allowances and overage terms in the current offer rather than assuming they are included.

Which cost metric is most useful for comparing proposals?

Use complete cost per clearly defined acceptable result, alongside total expenditure and remaining human effort. State the denominator and assumptions. Generated responses, accepted drafts and finally resolved requests are different units.