The Real Cost of Building an AI Agent for Your Business

Ask five agencies what an AI agent costs and you'll get five different numbers, often for what sounds like the same project. That's not because anyone is being dishonest about pricing — it's because "AI agent" describes a huge range of builds, and the part most people assume is expensive, the AI model itself, is usually the smallest line item in the budget. A single call to a frontier language model typically costs a fraction of a cent to a few cents. What actually drives the price of building an agent is everything around that model call: the tools it needs access to, the business logic that has to be encoded into its decisions, and how much testing it takes before anyone trusts it running without a person checking every output.

Where the Money Actually Goes

If you strip a project quote down to its components, model API usage is rarely more than a few percent of the total. The rest is engineering: designing the prompts and decision logic that tell the agent what to do and when to stop, building the tools it calls (a function that looks up an order, one that drafts an email, one that checks a calendar), and integrating those tools with your actual systems — your CRM, your helpdesk, your database, your calendar provider. Each integration means authentication, error handling, and a plan for what happens when the system you're connecting to is slow, down, or returns something unexpected.

Then there's testing. A chatbot that gives a wrong answer is embarrassing. An agent that takes a wrong action — issuing a refund it shouldn't have, sending an email to the wrong person, updating a record incorrectly — is a different category of problem. Most of the time we spend on an agent build after the initial version works is spent finding the edge cases where it doesn't, and deciding whether the fix is a better prompt, a stricter tool definition, or a rule that routes that specific case to a human instead of letting the agent handle it.

The Three Variables That Actually Move the Price

Three things determine whether an agent project lands at the low end or the high end of a quote, and none of them is "which AI model you use."

• Number of tools and integrations. An agent with one or two tools — say, searching an internal document set and drafting a reply — is a fundamentally smaller build than one coordinating across a CRM, a support desk, a payment system, and internal databases. Each additional system is its own authentication, its own failure modes, and its own testing surface.
• Complexity of the judgment required. An agent that classifies an incoming message into one of five categories is simple. An agent that decides whether a refund request is legitimate, checks it against order history and a policy, and decides whether to approve it automatically or escalate it is a materially harder problem, even though both might be described as "customer support automation."
• Level of autonomy versus oversight. An agent that drafts something for a human to approve is lower-stakes and cheaper to build safely than one that acts immediately and irreversibly. Building in review queues, confidence thresholds, and audit trails adds real engineering time — but it's usually the right trade for anything with financial or customer-facing consequences.

Mapping Real Projects to Realistic Ranges

Rather than talk in the abstract, it helps to map these variables to real project shapes. At Scult, most agent projects fall into one of our standard tiers depending on shape and scope, though every quote is scoped to the specific business logic involved.

An Essential project (starting around $1,000) is typically a single-purpose agent with one or two tools and one integration — an internal assistant that answers questions from a defined knowledge base, or a drafting agent that writes first-pass email replies for a human to send. The logic is narrow, the integration surface is small, and the testing scope is manageable.

A Growth project (starting around $2,000) usually involves an agent integrated with two to four systems and a decision layer with real branching logic — a support triage agent that reads an incoming ticket, checks order status in one system, checks a knowledge base in another, and either resolves the issue or routes it with context attached to the right person.

An Enterprise project ($4,000 and up) is where multiple departments or systems need to be coordinated, where approval workflows have several stages, or where the agent needs ongoing tuning against real production data after launch. These projects often include a review dashboard, audit logging, and a longer testing phase before the agent is trusted with anything higher-stakes.

What Isn't Included in the Build Price

A build quote covers getting the agent designed, built, and tested. It typically does not cover three ongoing costs that are worth budgeting for separately.

The first is model API usage after launch — this scales with how many times the agent runs per month, and for most small-to-mid-size businesses it's a genuinely small monthly number, often less than the cost of a single software subscription. The second is a maintenance retainer, which covers updates when the systems the agent integrates with change their APIs, when your business logic changes, or when you want to expand what the agent handles. The third is the cost of the underlying tools the agent connects to — your CRM or helpdesk licensing isn't part of an agent build quote, since you're presumably already paying for those systems independently.

Off-the-Shelf Tools vs. a Custom-Built Agent

Before scoping a custom build, it's worth being honest about whether you need one at all. A wave of no-code and low-code agent platforms now let a business wire up a basic assistant — connected to a handful of common tools like a calendar or a shared inbox — without any custom engineering. For a genuinely simple, generic use case, one of these can be the right answer, and no agency should talk you out of the cheaper option if it actually covers what you need.

Where these platforms hit their limit is anything that touches your specific business logic: your particular approval rules, your specific data model, an integration with a system that doesn't have a pre-built connector, or a decision process that doesn't map cleanly onto a generic template. That's the point where custom development starts earning its cost — not because custom is inherently better, but because the generic tool can't express the actual rules your business runs on without workarounds that tend to break in exactly the situations that matter most. A useful gut check: if you find yourself contorting a no-code tool's generic workflow to approximate your actual process, that contortion is a sign the project has outgrown the platform, and a custom build will likely cost less over its lifetime than continuing to patch around a tool's limitations.

A Worked Comparison: Two Businesses, Two Very Different Numbers

It helps to see the variables applied to real shapes. Consider a small consultancy that wants an internal assistant to answer employee questions about HR policy from an existing document set, with no external integrations beyond reading that document store. One tool, low judgment complexity, fully advisory (a person still acts on the answer) — this is a straightforward Essential-tier project, often built and tested within a couple of weeks.

Now consider a retailer that wants an agent to handle return requests: checking order history in an e-commerce platform, checking a return-eligibility policy, checking inventory to decide whether a replacement or refund is more appropriate, and only auto-approving requests under a certain value while routing everything else to a person. That's three to four integrations, real branching judgment, and a deliberate autonomy boundary that needs its own testing — a Growth-to-Enterprise project depending on how many edge cases the policy actually has, and one that will need a longer testing phase before the auto-approval path is trusted with real money.

The gap between these two isn't about which one uses a "better" AI model — both would likely use comparable underlying models. The gap is entirely in tool count, decision complexity, and the stakes of getting it wrong.

Why the Cheapest Quote Is Often the Most Expensive Choice

The fastest way to make an AI agent project cheap upfront is to skip the testing phase and ship the first version that technically works in a demo. The problem shows up a few weeks later, when the agent encounters a case nobody tested for — an order number formatted slightly differently, a customer message with an intent nobody anticipated, a tool that returns an error instead of data — and either fails visibly or, worse, does something wrong quietly. Fixing that after launch, with real customers already affected, usually costs more in engineering time and reputational cost than the testing would have cost upfront.

This is the pattern behind most "we tried an AI agent and it didn't work" stories: not that the underlying technology failed, but that the project was scoped and tested like a demo rather than a piece of production software making real decisions.

Questions Worth Asking Before You Accept a Quote

A few questions tend to separate a quote that reflects the real scope of work from one that will need renegotiating halfway through the project:

• How many tools and integrations are actually included, and what happens if we need to add one later?
• What does the agent do when it encounters a case it wasn't designed for — does it guess, fail silently, or escalate to a person?
• Is there a review step for anything with financial or customer-facing consequences, and who owns that review process day to day?
• What's the plan for monitoring the agent in production, and who gets notified if it starts behaving unexpectedly?
• Is ongoing model usage cost and maintenance a separate, predictable line item, or a surprise later?

The Practical Takeaway

The real cost of an AI agent has almost nothing to do with which language model sits underneath it and almost everything to do with how many systems it touches, how much judgment its decisions require, and how much oversight is appropriate given the stakes. A narrow, well-scoped agent with clear boundaries is a genuinely affordable project. A sprawling one that tries to automate judgment across your whole business on day one is not — and shouldn't be priced, or built, as if it were simple. The most useful exercise before requesting a quote isn't estimating what AI "should" cost — it's writing down exactly which systems the agent needs to touch and which decisions it needs to make, because that list is what actually determines the number.