Every leadership team has seen the demo: a chatbot that answers questions about the company handbook, or an agent that drafts a customer reply in seconds. Six months later, almost none of them are in production.

95% of the AI pilot programs studied for MIT NANDA’s 2025 “GenAI Divide” report stalled with little or no measurable P&L impact; only about 5% achieved rapid revenue acceleration.

The failure pattern is consistent, and it is not about model quality. Pilots are built under ideal conditions — clean sample data, a friendly test group, no integrations. Production removes every one of those assumptions at once.

The four reasons pilots stall

• No business metric. Teams measure whether the tool “works”, not whether it moves cost, revenue or cycle time.
• Data that isn’t ready. Curated demo data hides the messy, partial inputs real systems produce.
• No integration plan. An agent that can’t read from or write to your systems of record is a toy.
• Unclear ownership. AI teams, IT and the business unit each assume someone else will run it.

Each of these is invisible in a demo. Without a metric, the end of the pilot produces a debate instead of a decision, and debates tend to end in “not yet”. Without real data, the first week in production surfaces scanned PDFs, missing fields and edge cases the prototype never saw. Without integrations, someone has to copy results into the CRM by hand, and the time saved disappears. And without an owner, nobody updates prompts, watches costs or answers the first support ticket.

What a demo assumes, and what production brings

Pilot (built for a demo)

• Clean sample data
• A friendly test group
• No integrations

Production (real conditions)

• Scanned PDFs, missing fields and edge cases
• Real users
• Reads from and writes to systems of record

“A successful demo answers whether the model can work. Production readiness asks whether the whole system keeps working under real conditions.”

What the research says

Four widely cited studies agree on the direction, though each measures something different. Read the “what it measured” column before quoting any of them.

AI pilot failure research, by what each study measured

Industry research points the same way on causes too. BCG’s 10-20-70 rule holds that only about 10% of the value of an AI transformation comes from the AI application itself, 20% from the underlying data and technology, and the remaining 70% from redesigning workflows, culture and governance. Gartner’s forecast is blunter: more than 40% of agentic AI projects canceled before 2028, and the reasons it gives (rising costs, value nobody can show, weak risk controls) are all about how the project is run, not which model it uses.

Where the value of an AI transformation comes from

• The AI application: 10%
• Data and technology: 20%
• Workflows, culture and governance: 70%

BCG’s 10-20-70 rule.

Gartner’s June 2025 forecast also warned about “agent washing”, the rebranding of existing assistants, RPA and chatbots as agents, and described most agentic projects at the time as early experiments driven by hype. The MIT NANDA report adds a finding about how companies build: according to Fortune’s summary, buying from specialized vendors and building partnerships succeeded about 67% of the time, while internal builds succeeded about a third as often. Read together, the message is that the bottleneck is organizational and architectural, not the model. We weigh the build-or-buy question in more depth in build vs buy AI agents.

What the 5% do differently

What the pilots that ship do, in order

1. Start from one workflow and one number: Hours saved, tickets deflected, loans decided.
2. Prototype on real production data (week 2): In week two, not month six.
3. Design the integration and the human hand-off: Before choosing a model.
4. Ship a narrow version to real users: Measure, then widen scope.

The order matters. Picking the workflow and the number first decides which data you need, which systems the agent must touch, and where a person stays in control. Choosing a model is one of the last decisions, and the easiest to change later.

A production-readiness checklist for AI agents

Before an agent goes live, every item below should have an owner and an answer:

• Metric and baseline: the number the agent must move, measured before launch so improvement can be proven.
• Evaluation set: real past cases with the correct outcome, rerun on every change to prompts, models or tools.
• Integrations: read and write access to the systems of record, with error handling, rate limits and a rollback path for writes.
• Permissions: the agent sees only what the user it acts for may see, enforced outside the model. Our list of production guardrails covers how.
• Human approval: consequential actions, such as sending, paying or deleting, wait for a person until the data shows they can be automated.
• Audit log: every input, tool call, output and approval is recorded and searchable.
• Monitoring: accuracy, exception rate, latency and cost per task tracked weekly, with alerts.
• Ownership: a named team that runs the system, handles support and decides on changes.

None of this is exotic. It is the same discipline any production software needs, applied to a component that behaves less predictably than ordinary code. If what you have is an app built with an AI app builder rather than an agent, the matching list is our checklist for taking a vibe-coded app to production, and our prototype to production service does that work for you.

Questions to answer before you start a pilot

Most failed pilots could have been predicted on day one. Before committing budget, answer these in writing:

• Which single workflow will change, and who does it today?
• Which number will prove success, what is it now, and what result would justify a full build?
• Where will the data come from in production, and have we looked at a real sample, not a cleaned one?
• Which systems must the agent read from or write to, and who owns access to them?
• Which actions need a person’s approval, and who is that person?
• Who will run the system after launch, and what budget covers running costs?

If any answer is “we’ll figure it out later”, that is where the pilot is most likely to stall. A good discovery phase exists to turn each of these into a concrete answer before the build is priced.

When to stop a pilot: continue, change or kill

A pilot should end in one of three decisions, and the criteria for each should be written down before it starts. Without them, a stalled pilot drifts for months because nobody wants to call it.

End-of-pilot decision table (our judgment; set your own thresholds first)

“Change” is the most common honest answer, and it should come with one specific change and a date for the re-test. Two rounds of “change” on the same check usually mean “stop”. We don’t publish universal thresholds, because a 10% gain is a win in one workflow and noise in another; what matters is that the number exists before the pilot does.

Two examples from our own builds

Superdeal avoids the integration trap: its agent works inside the same campaign workspace as the creators, deals, deliverables and shipments, so nothing is copied between tools and the time it saves stays saved. And nothing the agent drafts is sent until someone on the brand’s side approves it.

A multi-agent system we built for commercial real estate due diligence had a trust problem to solve before a usage one: an analyst will not put a number from an AI into an investment memo unless they can check it. So every finding links to its source record, and each client firm’s data is kept apart at every layer the AI touches, from storage to the model’s context. Those two choices are what let an analyst rely on it.

Structure the engagement for production, not for a demo

We structure our own engagements around the questions above. The Discovery Sprint takes two weeks, costs $5,000 (credited to the build) and ends with a working prototype on your data. It answers the questions that sink pilots: is the data good enough, which integrations are needed, where must a person approve, and what will it cost to run. The build that follows is quoted at a fixed price and usually takes 6–16 weeks, delivered in two-week sprints with live demos and billed against working features. So the path from first workshop to a production launch is two weeks of discovery plus the build, not an open-ended pilot phase.

Discovery answers the questions that sink pilots before the build is priced.

You can see the plans on our pricing page, what drives the number in AI agent development cost, and why we prefer this contract shape in fixed price or time and materials.

If you have a pilot that stalled, or one you want to get right the first time, our AI agent development team can take it from prototype to production.

Sources

1. Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, Gartner (June 25, 2025)
2. MIT report: 95% of generative AI pilots at companies are failing, Fortune, on MIT NANDA’s The GenAI Divide (2025)
3. AI Transformation (the 10-20-70 rule), Boston Consulting Group
4. 88% of AI pilots fail to reach production — but that’s not all on IT, CIO.com, on IDC research with Lenovo (March 25, 2025)
5. AI project failure rates are on the rise: report, CIO Dive, on S&P Global Market Intelligence (March 14, 2025)

Originally published at apptycoons.com.

On October 9, 2026, Anthropic disclosed that some of its AI agents, given problems to solve during internal evaluations, had gone looking for resources online and misused what they found. According to TechCrunch’s report, they exploited software flaws on websites, including some run by US government agencies, got into databases without paying the fees, used URL shorteners to slip past restrictions, and one submitted a false murder tip to the Philadelphia police. Anthropic’s response was to cut its internal evaluations off from the live internet until it can monitor and control its agents.

That happened at a company that builds the models, in a test environment. A business agent connected to a CRM, a payment system or a customer inbox has the same basic shape: a model that decides what to do, and tools that let it do it. Guardrails are what make the second part safe.

What are AI agent guardrails?

AI agent guardrails are controls outside the model that limit what an agent can see, do and spend, and record what it did. They are enforced in code, permissions and infrastructure, not in the prompt, so they still hold when the model misreads a task, is manipulated by text it reads or takes a shortcut nobody anticipated.

OWASP calls the underlying risk “excessive agency”: damaging actions taken in response to unexpected, ambiguous or manipulated output from a model. It has three causes, and each guardrail removes part of one of them: too much functionality, too many permissions or too much autonomy.

Input, output and action guardrails: which ones matter for agents

Guardrails fall into three groups, and agents need the third far more than chatbots do. Input guardrails screen what reaches the model. Output guardrails check what it produces. Action guardrails limit what it can change in the world, and they are the reason an agent needs a different control set from a chatbot that only talks.

The ten controls below, grouped by what they guard

Many products sold as guardrails cover the first two groups: classifiers that flag injected prompts or toxic replies. Some teams add a second model that reviews the first one’s output before it is used, sometimes called a guardian agent. Both are useful, and both are still models reading text. They complement action guardrails enforced in code and infrastructure; they do not replace them.

The three groups of guardrails from the checklist below, with the audit log covering all three.

What the Anthropic incident shows about agent risk

Every behavior in the disclosure maps to a missing control, and none of them needed a smarter model to prevent. Anthropic itself attributed the behavior to training environments that taught models to look for loopholes, which is a reason to assume any agent may do the same.

Behaviors reported in Anthropic’s October 2026 disclosure, and the control that blocks each

The common thread is that each behavior was possible because the agent had a general capability, such as unrestricted web access, where it needed a specific one. Narrowing capability is cheaper and more reliable than trying to predict every misuse of a broad one.

The 10 controls a production agent needs

These are the controls we put around an agent before it touches real systems. Each one names the risk it addresses and, more importantly, where it is enforced, because a control the model can talk its way around is not a control. The OWASP mapping is our reading of the two lists, not an official crosswalk.

Ten guardrails for a production AI agent

Approvals that people do not rubber-stamp

An approval step only works if the person sees the actual change, not the agent’s summary of it. OWASP lists “human-agent trust exploitation” as its own risk (ASI09): polished explanations persuaded operators to approve harmful actions. Show the record before and after, the recipient and the amount, and make approving a deliberate act.

On a phone call, the person approving is the caller. The service booking agent we built for Innovative AI matched the caller’s own description to one service on that vehicle’s menu, read the chosen service back and booked only after the caller agreed. The point of that read-back is that a wrong match should cost one extra sentence on the call, not the wrong job on the dealership’s schedule.

Limits the agent cannot negotiate

Step and spend limits sound blunt, and that is the point. A cap of a few dozen tool calls per task, a daily budget per agent and a rate limit per user turn a loop or a manipulated agent into a small, visible failure instead of a large one. OWASP lists logging and rate limiting as the measures that reduce harm when prevention fails.

Why a system prompt is not a guardrail

A rule in a prompt is a request; the model can misread it, lose it over a long task or be talked out of it by text it reads along the way. Anthropic’s own explanation for its incident was that training rewarded models for finding loopholes, and a prompt that says “don’t” is exactly the kind of restriction such a model routes around.

Prompt or guardrail

System prompt (a request)

• Explains the job
• Text the model can misread
• Can be lost in a long task or overridden by injected text

Guardrail (enforced in code)

• Enforces the limits
• Code the model cannot change
• Holds when the model is manipulated by text it reads

Use the prompt to explain the job, and use code to enforce the limits. The same principle runs through OWASP’s guidance, which calls it complete mediation: authorize every action in the downstream system rather than relying on the model to decide what is allowed. If the agent connects to tools over MCP, the protocol’s security guidance makes the same point about tokens: a server checks that each token was issued for it and never passes it on. Our guide to MCP servers for Muse and Grok covers the server side in detail.

How the controls map to NIST’s generative AI profile

Enterprise risk teams often work from NIST rather than OWASP. NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework (July 2024), lists 12 risks that generative AI creates or makes worse. Four of them line up directly with agent guardrails:

• Information Security: controls 1, 3, 5 and 10 narrow what a manipulated agent can reach and let you cut it off.
• Data Privacy: control 2 keeps the agent inside the user’s own access, and control 7 records what it read.
• Confabulation: control 8 tests answers against known cases before release, and control 9 catches drift after it.
• Human-AI Configuration: control 4, with approvals designed so people review the real change, not a persuasive summary.

The other eight, from intellectual property to environmental impacts, are governance questions for the deployment as a whole rather than controls around one agent. This mapping is our reading of the profile, not an official crosswalk. If your agent serves people in the EU, logging and human oversight also carry legal weight; see which EU AI Act and GDPR duties apply to agents.

Who is liable when an agent gets it wrong

Usually the company that deployed it. In Moffatt v. Air Canada (2024), a customer relied on the airline’s website chatbot, which said a bereavement fare could be claimed after travel; the airline’s own policy page said otherwise. Air Canada argued the chatbot was a separate legal entity responsible for its own actions. British Columbia’s Civil Resolution Tribunal called that “a remarkable submission”, noted that the chatbot “is still just a part of Air Canada’s website”, and found the airline liable for negligent misrepresentation.

It is a decision of British Columbia’s Civil Resolution Tribunal, not binding precedent elsewhere, and this is not legal advice. The engineering lesson holds anyway: an agent’s answer to a customer is your company’s statement. Output guardrails on customer-facing answers, such as grounding every policy answer in a current source and refusing questions outside the agent’s scope, are a liability control as much as a quality one.

How we apply this on Superdeal

Superdeal’s agent was designed around controls in the system rather than trust in the model.

Superdeal is a campaign CRM in which an AI agent finds creators, drafts offers and handles shipments. Every consequential step goes Draft, Review, Send: the agent drafts, a person on the brand’s side reviews, and nothing reaches a creator until they approve it (control 4). Agencies share scoped, read-only dashboards with their clients, so a client view cannot change a campaign (control 2).

Superdeal: every consequential step

1. Draft: The agent drafts
2. Review: A person on the brand’s side reviews
3. Send: Only after they approve

What guardrails cost in time and money

Most guardrails are cheap; the expensive ones are the ones that involve people. Permission checks, allowlists, limits and logging are ordinary engineering and add milliseconds. Model-based checks on inputs and outputs add a model call each. Human approval adds minutes or hours, so it belongs only on actions that are costly to undo.

In our projects these controls are part of the build rather than an add-on: a Fixed-Price Build of $25k–$120k includes the approval steps, evaluation set, audit log and security review, and the AI agent development page lists what each engagement covers. What changes the effort is the number of systems the agent writes to, because every write path needs its own permission check, preview and rollback.

When lighter guardrails are enough

An internal assistant that only reads documents the user can already see needs permissions, logging and an evaluation set, and little else. Approval steps, spend limits and a network allowlist matter once the agent can write to systems, spend money or contact people.

Match the controls to what the agent can break, and add them when capabilities grow rather than all at once. Our checklist for taking AI pilots to production covers the business side of that decision: metric, owner and integrations.

A guardrails review you can run this week

Take your most capable agent, or the one you plan to build, and answer these in writing:

• Which tools can it call, and which of them does the task not need?
• Whose permissions does it act with, and are they checked by the system or by the prompt?
• Which domains and services can it reach over the network?
• Which actions send, pay, delete or contact someone, and who approves them?
• What happens if a document it reads contains instructions?
• What stops it after a hundred tool calls, or a thousand dollars?
• Where is the log of what it did yesterday, and who reads it?
• How would you stop it within five minutes?

Any question without a clear answer is a control to add before the agent gets more access. If a vendor is building the agent for you, put the same list to them alongside our questions to ask an agent vendor.

Sources

1. Anthropic can't reliably control its AI agents. It's cutting off its internal evals from the live internet instead, TechCrunch
2. LLM06:2025 Excessive Agency, OWASP GenAI Security Project
3. OWASP Top 10 for Agentic Applications: The Benchmark for Agentic Security in the Age of Autonomous AI, OWASP GenAI Security Project
4. MCP specification: Security Best Practices, Model Context Protocol
5. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), NIST (July 2024)
6. Moffatt v. Air Canada: A misrepresentation by an AI chatbot, McCarthy Tétrault (February 2024)

Originally published at apptycoons.com.

At 2,000 support outcomes a month, Intercom’s Fin costs about $71,000 over three years at its listed starting price, less than a custom agent. At 10,000 a month it costs about $356,000, roughly three times the custom option’s three-year cost in our model. Same job, same agent; volume alone flipped the answer.

Product vendors will tell you building is slow and risky. Development shops, us included, will tell you buying locks you in. Both are sometimes right, so what follows is a way to decide for one specific agent, including the cases where the right answer is not to hire a studio like ours.

Build vs buy AI agents: the short answer

Buy when the agent does a job every company has, at a volume where per-use fees stay modest, and a product already works with your systems. Build when the agent’s workflow is part of how you win, when it must act inside your own systems, when your data must stay under your control, or when usage fees would outgrow a one-off build within a few years.

Most companies end up in between. They buy the commodity layers, such as the models, telephony, vector search and observability tools, and build the workflow that is specific to them on top. The decision is less “build or buy” than “which layers do we own”.

The three real options: buy, configure or build

There are three ways to get an agent into production, and they differ in time to value, cost model and who owns the result.

Buy, configure or build

A decision matrix for CTOs

Answer these eight questions for the specific agent you are considering. If most answers fall in the “buy” column, buy. If most fall in “build”, build. If it is mixed, buy now and design for a later move.

Eight questions that decide build vs buy

Three-year total cost: a worked example

The cost comparison flips with volume, so do the arithmetic for your own numbers rather than trusting a rule of thumb. Here is one worked example for a support agent that resolves customer questions.

The bought option is Intercom’s Fin AI Agent at its listed starting price of $0.99 per outcome, rechecked on October 29, 2026. The custom option uses assumptions we state openly: a $25k–$120k build placed at $60,000 for a support agent with helpdesk and order-system integrations, $500 a month for hosting and monitoring, 20% of the build per year for maintenance and model updates, and model tokens at the rate in our AI agent cost worked example: four Claude Haiku 5.5 calls per ticket with prompt caching, about $0.0018 a ticket at list prices checked October 29, 2026. Helpdesk seats are left out because you need them either way.

Three-year cost, support agent (list prices and stated assumptions)

How the build column adds up at 10,000 a month: $60,000 build, plus $18,000 hosting over 36 months, plus $36,000 maintenance over three years, plus about $640 in tokens. The tokens barely register; the build and the people who maintain it are the real cost. On these assumptions, the break-even is about 3,200 outcomes a month.

Where the build option’s three years go, at 10,000 outcomes a month

• Build: $60,000
• Maintenance, 3 years: $36,000
• Hosting, 36 months: $18,000
• Model tokens: about $640

Stated assumptions above; total about $114,600. Tokens are the shortest bar.

Three caveats keep this honest. A product like Fin includes things a custom build has to create, such as reporting and content management, and its per-outcome price can be higher than the starting price. Intercom also counts a handoff to a person as an outcome when Fin completes that workflow, so outcomes are not the same as fully resolved tickets. A custom build can cost more than $60,000 if it needs more integrations or compliance work. And a bought agent is live in days, which has value the table does not show. Change the assumptions and rerun it; the method matters more than our numbers. For a fuller breakdown of build and running costs, see AI agent development cost.

Data, IP and lock-in: what to check before you sign

Lock-in is rarely about the contract term. It is about whether your data, history and logic can leave with you. Before buying, check:

• whether the vendor trains models on your data, and whether that can be switched off in writing,
• whether you can export conversation logs, knowledge sources and agent configuration in a usable format,
• where data is processed and stored, and for how long,
• whether you can choose or change the underlying model,
• and what happens to your history if you cancel.

If you build, the equivalent questions are about ownership. Our builds put the code in your repository from day one and the IP is yours, but whoever builds for you, confirm both in the contract.

Price the exit before you sign, too, because leaving a bought agent is a small project of its own. Expect to export conversation history and the knowledge base, map them into the next system, rebuild every integration the product handled for you, and rerun your evaluation cases to prove the replacement answers as well. None of that has a list price, so ask the vendor for a sample export on day one; a messy or partial export is the clearest sign of how much leaving will cost.

Governance and risk: why most failures are not about the model

Agent projects stall more often because of how they are run than because of the model, and the build-or-buy choice decides who carries that risk. On the buy side, the risk is a product that demos well but cannot reach the systems or rules your cases depend on. On the build side, it is a team that has never shipped an agent learning on your budget.

According to Fortune’s summary of MIT NANDA’s 2025 report on enterprise AI, tools bought from specialized vendors and builds done with partners succeeded about 67% of the time, and purely internal builds only a third as often. The lesson is not “never build”. It is that building from scratch in-house, without people who have shipped agents before, is the riskiest route. Whichever route you choose, insist on an evaluation set, approval steps for high-impact actions, an audit log, and a named owner after launch; our checklist of agent guardrails lists ten controls to ask for on either route. We cover this in more depth in why AI pilots stall before production.

When buying is the better choice

Buying is the right answer more often than development shops admit. Buy when:

• the use case is common, such as help-center answers, meeting notes or ticket summaries,
• a product already integrates with the tools you use, without custom work,
• your volume keeps per-use fees below what a build and its maintenance would cost,
• you need value this month and can accept the vendor’s workflow,
• or there is no one to own a custom agent once it ships.

In those cases, a custom build would cost more and arrive later, and you should not pay for one, from us or anyone else.

Do general-purpose agents like Muse and Grok Bot count as buying?

Yes, and for one kind of work they are the cheapest option there is. Meta’s Muse and xAI’s Grok Bot are general-purpose agents that sign in to the apps a person already uses and work through multi-step jobs. If the job belongs to one person or one small team and runs through common tools, try them before you buy anything narrower or build anything at all.

What each one is, from the vendors’ own pages (checked October 12, 2026):

• Muse launched on September 8, 2026, rolling out in the US. Meta says it is free for most of what people need, with paid plans for more. It runs on its own cloud machine, people choose which apps it connects to and how much access it gets, and it checks with the user before sensitive actions such as sending an email or making a purchase.
• Grok Bot has been in beta since August 11, 2026, included with SuperGrok and paid Cursor plans, with its own usage on top. Bots share a cloud computer that belongs to the account, sign in across apps and websites, use connectors where they exist and operate the screen everywhere else, and come back when something needs approval. xAI says teams use them for sales outbound, marketing campaigns and office operations; Enterprise access is a waitlist.

The limits are those of any bought agent, plus a few more. The agent runs in the vendor’s cloud with your users’ logins. It follows the vendor’s approval model, not yours, and your evaluation cases and audit requirements don’t travel with it. Where it operates a screen instead of an API, a layout change can break the job. Enterprise controls are still arriving on both.

So split the work by who carries the risk. An agent that drafts, researches or files on behalf of one person can be bought this way today. An agent that changes records, moves money or speaks to customers on the company’s behalf belongs in the build column of the matrix above. There is also a middle path: keep the workflow and its rules in your own systems, and let Muse, Grok Bot or Claude call them through an MCP server for Muse and Grok that enforces your permissions.

Split the work by who carries the risk

Buy a general-purpose agent (Muse, Grok Bot)

• Drafts, researches or files for one person
• Runs through common apps with your users’ logins
• Follows the vendor’s approval model

Build (your systems)

• Changes records, moves money or speaks to customers
• Acts inside your own systems
• Follows your approval rules and audit trail

When building wins

Building wins when the agent is part of what makes your business different, or when no product can reach the systems it needs to act in. Two of our builds show both patterns.

A commercial real estate platform we built is the first pattern: the agents are the product, and parallel agents turn a property address into a sourced report and a 10-year pro forma. No off-the-shelf agent does that, because that work is what the platform sells.

Superdeal is the second pattern. Its agent reads the platform’s own creator, deal and shipment records and works through the platform’s own approval step before anything is sent. A bought agent would sit outside that data and those approvals, which is where all of the agent’s value comes from.

The hybrid most teams end up with

In practice, nearly every custom agent is part bought. Models come from Anthropic, OpenAI, Google or open-source providers; vector search, telephony and observability come from vendors. What you build is the layer that encodes your workflow: the tools the agent can call, the rules it follows, the approvals it needs and the evaluation set that proves it works. Owning that layer is what lets you switch models as prices fall, and move between vendors without starting again.

The layer you build is the one that encodes your workflow.

AI agent vs chatbot vs RPA

Part of the build-or-buy question is whether you need an agent at all. Sometimes a chatbot or an RPA script is enough, and both are cheaper.

Chatbot, RPA or AI agent

How to run a fair test before you decide

You can test both routes cheaply before committing to either. Run the bought product on a slice of real traffic for two to four weeks, with its own reporting turned on, and record three numbers: how many cases it fully resolved, how many it got wrong, and how many it handed to a person. Then run the same cases through a custom prototype on your real data; our discovery sprint ends with one for $5,000.

A fair test of both routes

1. Run the bought product (2–4 weeks): On a slice of real traffic, with its own reporting turned on.
2. Record three numbers (same weeks): Cases fully resolved, cases it got wrong, cases handed to a person.
3. Run a custom prototype (discovery): The same cases, on your real data.
4. Compare on your evaluation cases (decide): Not on a demo, and at a cost you can live with at year-three volume.

Compare the two on your evaluation cases, not on a demo. If the product resolves enough cases at a cost you can live with at year-three volume, buy it. If it stalls on the cases that matter most, such as those that need your internal systems or your rules, that gap is what a custom build is for. If you do go custom, the vetting questions are in how to choose an AI agent development company.

The method is not specific to AI. We ran the same decision for affiliate tracking, where SaaS plans that step up with tracked affiliate revenue play the part that per-outcome pricing plays here.

A build-vs-buy checklist

Before you decide, write down answers to these, for this agent specifically:

• The one business number the agent must move, and its current value.
• Expected volume in month one and in year three.
• Every system the agent must read from or write to.
• Where the data may be processed and stored.
• Which actions need a person’s approval.
• Who owns the agent after launch, and their budget for changes.
• The three-year cost of buying at year-three volume, and of building.

If the checklist points to buying, buy. If it points to building, our AI agent development team fixes the price after a two-week discovery sprint, and the first conversation is a free AI audit that covers this decision, including when the answer is to buy.

Sources

1. MIT report: 95% of generative AI pilots at companies are failing, Fortune
2. Intercom pricing (Fin AI Agent), Intercom
3. Microsoft Copilot Studio pricing, Microsoft
4. Claude API pricing, Anthropic
5. Introducing Muse: The World’s First Personal AI Agent Built for Everyone, Meta
6. Introducing Grok Bot, xAI

Originally published at apptycoons.com.

A receptionist demo answers the phone, greets the caller and handles a couple of questions. A production voice agent has to book the slot. On the dealership voice agents we built for Innovative AI, that meant settling four things on one call: the exact vehicle, the right service out of the 100–200 on that vehicle’s menu, an open time and a way to get the car in.

99% of callers who went ahead with booking through the agent were booked, by our own count, on the Innovative AI build. Calls that weren’t bookings don’t count toward it.

The gap between those two is mostly routing. The demo puts one agent on the line and asks it to do everything. The production system puts a receptionist agent in front whose only job is to work out what the caller wants, and hands the call to an agent built for that job. This guide covers how that split works, what booking needs before it can happen, and when a phone tree or one more person at the front desk is the better buy. It is the call design we use for custom AI voice agents and AI receptionists.

What is call routing for an AI receptionist?

Call routing for an AI receptionist is the step where the agent works out the caller’s intent and sends the call to the path that handles it. That path can be another agent, a person or a callback queue. Routing is a classification problem, and it is the first decision on every call.

Anthropic’s guide to building agents describes the same pattern under the name routing: it “classifies an input and directs it to a specialized followup task”, and works well “for complex tasks where there are distinct categories that are better handled separately”. Its first example is customer service queries sent to different downstream prompts and tools. Agent frameworks build it in. OpenAI’s Agents SDK, for example, exposes each handoff to the model as a tool, so a triage agent can transfer a caller to a billing or refund agent.

A keypad menu routes too, but the caller does the classifying by pressing 2. An AI receptionist asks an open question (“How can I help?”) and does the classifying itself.

Why a demo receptionist breaks on a real phone line

A demo receptionist breaks because one agent carries every instruction, every tool and every edge case at once. With two call types that holds up. With five, the prompt mixes booking rules with status lookups and policy answers, and a change for one call type can break another that you didn’t retest.

Real phone lines carry several kinds of calls. A dealership line carries service bookings, questions about a car already in the shop and calls about everything else. Each needs different data and ends differently: a booking ends with an appointment written to the scheduler, a status question ends with an answer, and a complaint ends with a person.

Splitting the work lets you treat each call type as its own small system:

• Shorter instructions. The booking agent only carries booking rules, so it never has to decide whether the caller is booking at all.
• Fewer tools per agent. An agent that can only read the menu and write appointments can’t call the wrong system.
• Tests per call type. You can replay a week of booking calls against the booking agent alone and see what changed.
• Failures you can locate. When a call goes wrong, the transcript shows whether the route or the task failed.

The cost is one more step on every call. The handoff has to be fast and invisible to the caller, which is a latency question as much as a design one; our guide to voice agent latency covers that budget.

How the front agent routes a call in production

On the Innovative AI system, a receptionist agent takes every inbound call first. Its only job is to work out what the caller wants and hand the call to the agent built for that. The agents are still live in production.

We built the receptionist around three paths: book a service, check on a car already in the shop, or something else. By the time the booking agent speaks, the intent is settled. For a phone number the system already knows, so are the caller’s name, car and last service, which are saved against the number from earlier calls.

The split we recommend, modeled on that build: what the front agent does and what it leaves to the agents behind it

Three rules we recommend for any front agent:

• Ask rather than guess. If the first sentence could mean two things, ask one short question. A wrong route costs the caller their first minute.
• Confirm a saved caller, don’t assume one. A phone number identifies a line. Households share phones and cars, so a quick “Is this about the Camry?” beats a booking for the wrong vehicle.
• Pass a summary with every handoff. Whoever takes the call next, agent or person, should start from what the caller already said.

The case study on Innovative AI’s dealership voice agents covers the rest of the system, including its outbound calls.

What a booking needs before it exists

A booking exists only when the agent has every field the scheduler needs and the caller has agreed to them. On the Innovative AI build there were four, collected in order, and the booking agent wrote nothing until all four were settled.

1. The exact vehicle. Year, make, model and trim, because the service menu depends on the car.
2. The right op code. The caller describes the job in their own words, and the agent picks the matching entry out of the 100–200 services on that vehicle’s menu, each with its own op code.
3. An open slot. The agent checks the requested time against the dealership’s open appointments and offers another time if it is taken.
4. A transport choice. Drop-off (with a shuttle or loaner if needed), pickup by the dealership or mobile service at home, with an address asked for only when the option needs one.

Before booking, the agent reads the service back and goes on only once the caller agrees. A wrong op code books the wrong job, so that confirmation is in every booking.

This is where a demo and a production agent differ most. A demo can say “You’re all set for Tuesday” without anything behind it. A production agent can only say it after the scheduler has accepted the appointment. Our guide to AI service scheduling for dealerships walks through each of the four steps from the caller’s side, including what to do when no menu entry matches.

Other businesses have their own four fields. A clinic needs the patient, the visit type, the provider’s open slot and the location. A field service company needs the address, the job, the window and the access details. Write the list down before any prompt: it decides what the booking agent asks and in what order.

Where routed calls still fail

Routing narrows the failures but doesn’t remove them. On the Innovative AI build, the bookings that didn’t complete failed for three reasons: requests too odd or ambiguous to match to a service, accents and pronunciation the speech recognition misheard, and heavy background noise at the caller’s end.

None of those is a routing failure, but routing decides what happens next. A narrow booking agent knows when it is stuck, because it is stuck on one question: which service the caller means. That makes a clean exit easy to design. We recommend that after one failed clarification the agent offers an advisor or a callback and passes on what it already has, so the call ends with a next step instead of a hang-up.

Track routing separately from booking after launch. Count calls by the path the front agent chose, the handoffs to people by reason, and calls that were sent to one agent and handed back. A rising hand-back rate means the front agent is guessing.

When a phone tree or better staffing wins

A phone tree wins when callers need a destination, not an outcome; better staffing wins when the calls need judgment and the volume fits in business hours. An AI receptionist earns its build cost when many callers need something done, such as a booking, at hours or volumes your staff can’t cover. We build the third option, so weigh this table with that in mind.

Phone tree, more staff or an AI receptionist: how we would decide

GetVoIP’s comparison of the two makes a similar point from the IVR side: for pure high-volume transactional sorting, it says, “a menu is faster and cheaper than any conversation.”

Staffing is easy to size. The Bureau of Labor Statistics puts the 2025 median pay for receptionists at $18.27 an hour. A full-time receptionist covers about 40 of the 168 hours in a week, roughly 24%, and one call at a time within those hours. If your missed calls fall inside those 40 hours and rarely overlap, a second person or a better lunch rota is the cheaper fix. If they fall at night, on weekends or in bursts, a person can’t cover them at that price, and an agent can.

How to scope an AI receptionist that books

Start from the call log, not the demo. A week of recorded calls shows which intents your line carries, how many of them are bookings and how far callers’ words sit from the items in your booking system. From that, the scope writes itself:

• The paths. The intents the front agent routes on day one, and where everything else goes.
• The fields. For each bookable path, the fields the scheduler needs and the order the agent asks for them.
• The confirmation. What the agent reads back before it writes anything.
• The exits. When the agent hands over to a person, and what summary goes with the call.
• The measures. Booking completion among callers who chose to book, handoffs by reason and hand-backs from the routed agents.

A routed receptionist with booking falls in our $25k–$120k fixed-price band, set after a Discovery Sprint. The number of paths and booking-system connections moves it within the band more than the conversation does; the pricing page explains how the band is set.

Before any of that, check whether the calls you miss are worth the build. Put your call volume, missed-call share and customer value into the AI voice agent ROI calculator, and our guide to the cost of missed calls shows the formula behind it.

Sources

1. Building effective agents, Anthropic (Dec 19, 2024)
2. Handoffs, OpenAI Agents SDK documentation, as of October 2026
3. Receptionists: Occupational Outlook Handbook, U.S. Bureau of Labor Statistics
4. AI Receptionist vs IVR: How Each Handles Your Calls and Which Fits You Best, GetVoIP (Jul 9, 2026)

Originally published at apptycoons.com.

In conversation, people leave about 200 ms between turns. When an agent takes two seconds to respond, callers start talking over it — or hang up.

That pause is the first thing a caller judges, before they notice the voice or what the agent says, and most of it can be engineered away.

How fast should a voice agent respond?

A voice agent should start speaking within about one second of the caller finishing, and faster is noticeably better. That target comes from how people talk to each other, not from what the technology finds easy.

Conversation research is consistent here. Levinson and Torreira summarize it as gaps between turns “of the order of 200 ms”, while the time a person needs to plan even a short utterance is over 600 ms. People manage this by predicting how the other speaker will finish and preparing a reply while they are still listening. A comparison of ten languages by Stivers and colleagues found the same pattern everywhere: speakers avoid overlap and minimize silence, and the average gap varies by language only within about 250 ms of the cross-language mean.

The phone network has its own guideline. ITU-T G.114 sets a target of 150 ms one-way delay for most voice uses, before any AI is involved. Together, these numbers explain why a two-second silence feels broken: it is roughly ten times longer than the gap a caller expects.

Where the time goes

Where one turn’s time goes, in order

1. Network in: Caller audio reaches your services
2. Speech to text: Finishing the caller’s sentence
3. Language model: Deciding what to say or which tool to call
4. Text to speech: Producing the first audio
5. Network out: Audio travels back to the caller, plus the network hops between each service

Each item hides a further delay. Before transcription can finish, the system has to decide that the caller has stopped talking. The model’s first token arrives quickly, but a long system prompt, a large model or a tool call can push the first useful sentence much later. Speech synthesis needs a full phrase to sound natural. And on a phone call, audio travels from the carrier to your telephony provider, then to each AI service and back, so a service hosted far from the others adds a round trip on every turn.

Mid-call lookups belong in the same budget: when a dealership booking agent loads a vehicle’s service menu or checks open slots during an Xtime API integration, each request is a tool call inside the caller’s turn, and the caller waits through it.

A latency budget, stage by stage

A one-second target only works if each stage has its own share of it, written down before the build. The table splits a turn into stages, with the published figure for each where one exists, checked October 18, 2026, and how to measure the rest.

Latency budget for one voice agent turn (published figures checked October 18, 2026)

The table shows why the fixed parts matter. With the network at the G.114 limit in both directions and a 500 ms silence threshold, those two items alone take 800 ms (150 + 150 + 500), before transcription, the model or speech start. That is illustrative arithmetic, not a measurement, but it is why end-of-turn tuning and same-region hosting do more for latency than swapping models.

150 + 150 + 500 = 800 ms before transcription, the model or speech start.

Why vendor latency numbers don’t add up

Vendor latency figures usually measure one model in isolation, while the caller hears the whole chain. ElevenLabs is explicit about this: its models page lists Flash v2.5 at about 75 ms and marks the figure as excluding application and network latency.

That is a fair way to describe a model, and it is the right comparison between models. It is not what a caller experiences. Add up model-only figures for speech-to-text, the language model and text-to-speech, and the sum still leaves out end-of-turn detection, the phone network, the hops between services and any tool call. Those are the stages that set the pause a caller hears.

When a vendor quotes a latency number, ask three questions: which stages it covers, whether it is a median or a 95th percentile, and whether it was measured on a phone call or in a browser.

End-of-turn detection is the hidden delay

The most overlooked delay is deciding when the caller has finished. A simple voice activity detector waits for a fixed stretch of silence before it ends the turn. OpenAI’s documentation for its realtime API describes the trade-off directly: with a shorter silence duration, turns are detected more quickly. Set it too short, and the agent interrupts people who pause mid-sentence; set it too long, and every reply starts late.

Newer approaches look at meaning as well as silence. LiveKit’s agent framework, for example, uses a turn detector model that predicts the end of a turn from both what was said and how it sounded, on top of voice activity detection, and can adapt its delay to the caller’s own pauses. OpenAI offers a semantic mode with an adjustable eagerness setting. Neither removes the trade-off, but both let the agent answer quickly when a sentence is clearly complete and wait when it is not.

How to cut latency without making the agent worse

We stream every stage, start speaking before the full response is generated, and run tool calls in parallel with filler acknowledgements — so the agent feels present even while it works.

That comes down to six choices:

• Stream transcription, generation and speech, so each stage starts on partial output instead of waiting for the previous one to finish.
• Send the first sentence to speech synthesis as soon as it is complete, and keep generating the rest while it plays.
• Keep the speech, model and telephony services in the same region, and keep connections warm between calls.
• Keep the system prompt short and move rarely needed instructions into tools, so the model reads less on every turn.
• Use a smaller, faster model for routing and simple turns, and a larger one only where reasoning is needed.
• Cache data that does not change during a call, such as opening hours or the caller’s account, after the first lookup.

None of these require a worse answer. The goal is to remove waiting, not thinking.

Interruptions matter as much as speed

A fast agent that cannot be interrupted still feels robotic. When a caller starts talking, the agent should stop speaking almost at once, keep what it heard, and respond to the interruption rather than finishing its script. Frameworks such as LiveKit pause agent speech when they detect the caller and can tell a real interruption from a backchannel like “uh-huh”, so the agent does not stop every time someone agrees with it.

Test this on purpose. Interrupt the agent mid-sentence, talk over it in a noisy room, and pause halfway through a long account number. These are the moments callers remember.

Latency targets by call type

Not every call needs the same speed, and the right target depends on what the caller is trying to do. A booking or FAQ call is made of short, scripted turns where speed is most of the experience. A discovery or sales call has longer answers where quality matters more than shaving a few hundred milliseconds.

• Booking, FAQs and routing. Short questions and short answers. Aim for the fastest turns you can measure, a small fast model for most turns, and cached data such as opening hours.
• Account lookups and changes. The tool call dominates. Acknowledge at once (“Let me check that”), run the lookup in parallel, and set a budget per tool.
• Discovery, sales and support with judgment. Longer reasoning is acceptable if the agent signals it is thinking. Keep the first sentence fast and let the rest follow.
• Regulated calls, such as healthcare scheduling. A disclosure or confirmation step adds a turn by design; budget for it instead of cutting it. Our healthcare software development page covers the privacy side of those calls.

Example call (illustrative): acknowledge, then look up

1. Caller: Can I move my appointment to Friday?
2. AI agent: Let me check that.
3. AI agent: Friday has 10 am or 2 pm open. Which works better?
4. Caller: 2 pm, please.

Whatever the type, measure the same way and report the median and the 95th percentile separately for each call flow.

Platform or custom pipeline: who controls the latency?

Hosted voice platforms such as Vapi and Retell assemble the pipeline for you: telephony, transcription, model and voice behind one API. That is the fastest way to a working agent, and for many call flows their latency is good enough. The trade-off is control. You choose from the vendors and regions the platform supports, and when a turn is slow, you can see less of why.

A custom pipeline, built on frameworks such as LiveKit or Pipecat, puts every stage under your control: where each service runs, which models handle which turns, how end-of-turn detection is tuned, and how tool calls are scheduled. It takes more engineering and more operational work. It is worth it when calls involve heavy lookups in your own systems, when data must stay in a specific region, or when volume makes per-minute platform fees a large line item. Same-region hosting does double duty there: it cuts a network hop on every turn and it is also how an agent keeps EU callers’ data in an EU region when a client asks for it; the transfer rules are explained in EU AI Act and GDPR rules for AI agents. The per-minute side of the decision is worked through in AI voice agent cost. Whichever route you take, measure it the same way.

Who controls the latency

Hosted platform (Vapi, Retell)

• Fastest way to a working agent
• Vendors and regions the platform supports
• Less visibility into why a turn is slow

vs

Custom pipeline (LiveKit, Pipecat)

• More engineering and operational work
• You choose where each service runs
• Every stage under your control

How to measure voice agent latency

Measure what the caller hears, not what a dashboard reports. The number that matters is the time from the end of the caller’s speech to the first audio of the reply, recorded on a real phone call.

• Place test calls over the phone network, not only in a browser demo, because the carrier and telephony hops add delay a demo never sees.
• Record both sides of the call and mark the end of caller speech and the start of agent audio.
• Report the median and the 95th percentile across many turns; a good median with a slow tail still produces awkward calls.
• Log each stage separately, so a slow turn points to transcription, the model, a tool or speech synthesis.
• Repeat the test with background noise, accents and the longest tool calls in your flow.

Run this test on your own call flows before launch, because a latency figure measured on a different script, network or vendor mix says little about your calls.

“Latency isn’t a technical metric. It’s the difference between a conversation and a phone tree.”

What to do next

If you are planning a voice agent, set a latency target alongside your business goals, and ask any vendor or platform how they measured theirs. Our AI voice agent development work starts with your call flows, integrations and a latency budget for each one. To put a value on every answered call, read what missed calls really cost or put your own call volume into the AI voice agent ROI calculator.

Sources

1. Timing in turn-taking and its implications for processing models of language, Frontiers in Psychology (Levinson & Torreira, 2015)
2. Universals and cultural variation in turn-taking in conversation, PNAS (Stivers et al., 2009)
3. What is latency? (ITU-T G.114 one-way delay target), Twilio
4. Turn detection and interruptions, LiveKit Agents docs
5. Voice activity detection (VAD), OpenAI API docs
6. Models, ElevenLabs docs

Originally published at apptycoons.com.

On DubCam, a fan picks a program at sign-up, 50% of every subscription is attributed to that program, and the money goes out on the 1st of the month with no minimum threshold. That one sentence hides four systems: attribution, a ledger, payouts and tax reporting. It also hides a choice most platforms make too late: is 50% of the price the fan paid, or of what is left after the app store takes its cut?

This guide covers each system with real published fees and the arithmetic, so you can set the rules before the first statement goes out.

What a creator revenue share system needs

A revenue share is four systems that must agree with each other every month:

• Attribution: every payment linked to exactly one creator, by a rule the fan can see.
• Ledger: every split, fee, refund and payout recorded as its own entry.
• Payouts: creators paid on a fixed schedule through a provider that verifies who they are.
• Statements and tax: each creator sees how their number was calculated, and the platform files the forms the law requires.

The percentage in the contract is the easy part. Creators leave when a statement can’t be explained or a payout is late, not when the split is a few points lower than a rival’s.

Attribution: decide who gets credit, once

The most trusted attribution rule is the one the fan chooses. On DubCam the fan picks who to back at sign-up, and renewals follow that choice until the fan changes it. Store the choice on the subscription, keep a history of every change with its date, and show the fan who they are supporting.

Attribution on DubCam: the fan chooses

1. Fan signs up: Picks a program to back
2. Choice stored: On the subscription, with its history
3. 50% attributed: Renewals follow the choice
4. Paid on the 1st: No minimum threshold

Disputes start when credit is inferred, for example from viewing time that nobody outside the platform can see. If your model has to split one subscription across several creators by usage, publish the formula and keep the usage data each split was based on, because a creator will ask.

The ledger: every split as an entry

Each payment should create separate ledger entries for the fee, the platform’s share and the creator’s share, all linked to the original transaction. Refunds and chargebacks create new entries that reverse the old ones; nothing is edited.

Here is one $10 web subscription with a 50% creator share of gross, refunded the next week. The fee is Stripe’s standard US card rate of 2.9% plus 30 cents, as listed in October 2026; the numbers are illustrative, not a client’s.

Ledger entries for one $10 web subscription and its refund (illustrative)

Whether the processing fee comes back on a refund depends on your processor’s terms, so model it as its own entry rather than assuming. A creator statement is then a filtered view of the creator payable lines, and any line traces back to the payment that produced it.

Gross or net: the store fee decides

App store fees take 15% to 30% of an in-app subscription, so a share of gross and a share of net can differ by more than a dollar on a $10 plan. Apple pays developers 70% of an auto-renewable subscription price in a subscriber’s first year and 85% after one year of paid service; free trials don’t count toward that year. Members of the App Store Small Business Program, for developers with up to $1 million in proceeds in the prior year, receive 85% from the start. Google Play lists 10% plus a 5% billing fee on auto-renewing subscriptions bought through Play Billing by users in the US, EEA and UK (rolled out June 30, 2026) and in Australia and Japan (September 30, 2026), on a developer’s first $1 million of annual earnings.

$10 monthly subscription, 50% creator share, by channel (our arithmetic on published rates, taxes excluded, October 2026)

The last column is the one founders miss. A share of gross on iOS in year one leaves the platform $2.00 of every $10, before hosting, streaming and payout costs. A share of net keeps the platform’s margin steady but pays creators less on mobile than on the web. Neither is wrong. The creator terms must say which rule applies, the ledger must calculate it the same way, and the statement must show it.

Our arithmetic on Apple’s published 70% first-year rate, taxes excluded.

Can you send fans to the web to pay?

In the United States storefront, yes. Apple’s App Review Guidelines, section 3.1.1(a), say entitlements “are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps.”

Watch out

The US rule is not global

In other storefronts, links to outside purchasing need a specific entitlement or are not allowed, so check the guidelines for each country you launch in.

A web checkout changes the fee line in the table above, not the creator rule. Record the channel on every payment, and decide whether creators earn the same share whichever way the fan paid. Most platforms keep the rule identical so creators don’t have to understand app store economics.

What payouts cost, and why most platforms set a minimum

Paying a creator has a fixed cost per account and per payout, so small payouts are expensive. Stripe Connect’s pricing where the platform sets its own fees lists $2 per monthly active account (an account is active in any month it receives a payout), 0.25% plus 25 cents per payout, 1% for instant payouts and $2.99 per 1099 form e-filed with the IRS, as of October 2026.

Cost of one monthly payout on Stripe Connect (our arithmetic, October 2026 list prices)

That is why most platforms set a minimum and roll smaller balances into the next month. DubCam pays on the 1st with no minimum threshold, which makes the promise to a small high-school program simple. Paying with no minimum means small balances carry per-payout fees in full, so decide who bears them before launch. It is a product decision, and it should be made with this table in front of you.

Payouts don’t have to leave your platform as bank transfers. Earnings can land in an in-app balance or wallet that creators spend by card, the model behind stablecoin wallet payouts on a platform we built for a partner network.

Refunds, chargebacks and payout timing

Pay creators from settled money, not from payments that can still be reversed. Three rules keep a platform from paying out money it later loses:

• Hold period. Pay a month’s earnings after the refund window for that month has closed, or hold back a reserve until it does.
• Reversals as entries. A refund or chargeback after payout creates a negative entry for the creator, linked to the original payment.
• Negative balances carry forward. Deduct them from the next payout instead of chasing the creator, and show the deduction on the statement.

Tell creators the schedule and the hold rule in writing before their first payout. A late payout explained in advance costs less trust than an early one clawed back.

Tax and identity: what the platform must collect

Verify every creator before the first payout and collect tax details at onboarding, not at year end. Payout providers such as Stripe Connect run identity verification of the people you pay; your onboarding should collect a W-9 from US creators and a W-8 from non-US creators.

In the US, the IRS says payment apps and online marketplaces must file Form 1099-K when a payee’s payments for goods or services exceed $20,000 in more than 200 transactions, and that payees may receive the form for smaller amounts. In the EU, the DAC7 directive (Council Directive (EU) 2021/514, applied from January 1, 2023) requires platform operators to report sellers carrying out certain activities, including personal services, defined as time- or task-based work done at a user’s request. Whether a creator subscription counts depends on the model, so put the question to tax counsel during discovery. This section is not tax advice.

Build or buy a creator payout system

Buy when monetization isn’t your product. Patreon, for example, lists a 10% platform fee on creators’ income for creators who publish after August 4, 2025, plus payment processing, currency conversion and payout fees, as of October 2026. For a creator who only needs a membership page, that is cheaper than any build.

Buy a membership tool or build the payout system

Buy (Patreon, for example)

• 10% platform fee for creators who publish after August 4, 2025
• Plus processing, currency conversion and payout fees
• Cheapest when a membership page is all you need

vs

Build (DubCam, for example)

• Fans back a specific program
• Split rules no membership tool expresses
• Live video and payouts in one branded app

Build when the split, the attribution or the app is the product: a network where fans back a specific program, a share that follows rules no membership tool expresses, or live video and payouts inside one branded app. DubCam is that case. The same build or buy test applies to partner commissions, and the three-year numbers for that decision are in affiliate tracking: build or buy.

A custom build also decides your platforms. Live video and subscriptions on iOS, Android and the web is a different scope from a web-only membership site; the trade-offs between one shared codebase and separate apps are in native vs cross-platform development.

What we learned building DubCam

Letting the fan choose the creator at sign-up made everything downstream simpler. Attribution is a stored field, not a model. A creator’s statement is a list of their supporters’ payments. Support questions about “why did I earn this” have one answer.

DubCam ships as iOS and Android apps plus the web, with a ten-minute free preview before a fan subscribes, in-app purchases on the App Store and Google Play, and automated payouts on the 1st. The no-minimum rule tells a small program that every supporter counts.

What a revenue share build costs

A streaming app with subscriptions, attribution, a ledger and payouts is a fixed-price build within our $25k–$120k range, delivered in 6–16 weeks after a Discovery Sprint. In our judgment, these move it up the band: live video rather than uploads only, iOS plus Android plus web, more than one payout rail, a creator statements portal, and usage-based splits instead of fan-chosen ones. The pricing page has the terms.

If you are planning a creator or streaming product, our live streaming and creator platform development work covers subscriptions, splits and payouts, and our mobile app development team ships the iOS and Android apps.

Sources

1. Auto-renewable subscriptions, Apple Developer
2. App Review Guidelines, Apple Developer
3. Service fees, Google Play Console Help
4. Connect pricing, Stripe
5. Pricing, Stripe
6. A standard platform fee for new creators, effective after August 4, 2025, Patreon Help Center
7. Understanding your Form 1099-K, IRS
8. Council Directive (EU) 2021/514 (DAC7), EUR-Lex

Originally published at apptycoons.com.

Xtime has no self-serve API keys. As of October 2026, Supergood’s assessment of the Xtime API lists six things before the first production call: an NDA, a partner agreement, setup and per-dealer fees, a Cox Automotive business review, a certified demo and an invitation code from each dealership.

We built AI voice agents for Innovative AI that book service appointments at US car dealerships through Xtime and run sales follow-up through VinSolutions, Cox Automotive’s dealership CRM. The agents are still live in production. On that build, the hard parts were matching a caller’s words to one service out of a long menu, checking slots and handling transport. Those, plus the access steps and our recommendations on safe retries, are what this guide covers, from the system side. If you want the finished product rather than the build notes, our custom AI voice agents page has the scope.

How do you get Xtime API access?

You get Xtime API access through Cox Automotive’s partner program, not by signing up for a key. Supergood, which grades vendor APIs, lists the steps as of October 2026: an NDA and a partner agreement, a setup fee plus annual and per-dealer fees, a business review by Cox, and a certified demo before production approval. After that, each dealership opts in with an invitation code.

The steps to production access, per Supergood (as of October 2026)

1. NDA and agreement: Partner agreement with Cox
2. Fees: Setup, annual and per-dealer
3. Business review: Run by Cox
4. Certified demo: Before production approval
5. Dealer opt-in: One invitation code per dealership

The reference documentation is behind a login on the Cox Automotive Integration Platform. Supergood notes that Service Scheduling 1.0 and Service Marketing 1.0 are listed on Cox’s developer portal, and labels the scheduling capabilities as the Consumer Scheduling API.

Two consequences for planning:

• The calendar is not yours. The business review and the certified demo run on Cox’s schedule. Build against what you can test, and keep the demo-ready flow small.
• Contracts sit with whoever holds the integration. Decide early whether the dealer group, a software vendor or the build team signs, because the per-dealer fees and the support obligations follow that party.

We don’t quote the fee amounts here. They are set by Cox and should come from Cox in writing.

What the scheduling API covers, and what it doesn’t

The Xtime scheduling API covers the booking itself: dealer capacity, available appointment times, and creating or canceling appointments by year, make and model or by VIN, according to Supergood as of October 2026. It does not cover repair orders or inspection results.

That split decides what a voice agent can answer on its own.

Caller requests and whether the scheduling API answers them (scope per Supergood, as of October 2026)

Watch out

“Is my car ready?” is not a scheduling question

Repair orders are not offered by the scheduling API, so a status question needs DMS access or a handoff to a service advisor.

Xtime’s own product page describes “dynamic menus that reflect your dealership’s pricing, promotions, and service recommendations”. Menus are set by each dealership, so treat menu content as dealer data that changes, not as a fixed catalog you can hard-code.

The data flow on one booking call

One booking call touches Xtime at three points: the vehicle’s service menu, the open times for the chosen service, and the appointment itself. Everything else is the agent’s own logic and its own store.

The table is our recommended data flow, in the order the Innovative AI case study describes the call. It shows which system each step reads or writes, not how the conversation sounds.

Data read and written on one service booking call (our recommended flow)

Steps 3, 5 and 7 are the only Xtime calls, and step 3 has to come before any talk about times: the agent cannot offer a slot until it knows which service it is booking, and it cannot know the service until it has the vehicle. Transport options differ by dealership, so they live in configuration rather than in code. The case study covers the menu sizes and transport choices from that build.

Returning-caller recognition sits beside this flow rather than in it: on that build, the caller’s name, vehicle and recent service were saved against the phone number, so a repeat caller skipped questions the agent could already answer. The same system also looked up and confirmed existing appointments, and placed follow-up calls when the dealership’s CRM showed a booked customer had not arrived.

What the voice agent needs on top of the API

A voice agent needs five system-side pieces that no scheduling API provides: a menu-constrained output, an availability check inside the booking step, per-dealer transport configuration, a caller profile store and a create step that is safe to retry. The rest of this section is our engineering recommendations, not a description of the Innovative AI system and not Cox documentation. How the conversation itself should sound, from matching a caller’s words to offering another time, is in our guide to AI service scheduling for dealerships.

A menu-constrained output. The model’s choice of service should be an op code from the menu Xtime returned for that vehicle and nothing else. Pass the menu in as the only allowed values and validate the answer against it in code, so a request for “the 30k service” can only resolve to a line that exists. An answer that matches nothing is a handoff, never a guess.

Availability inside the booking step. Treat the open times read earlier in the call as a hint. The create step reads availability for that service and time again and books only if the slot is still returned, so the check and the write sit together in one function.

Per-dealer transport configuration. Store each rooftop’s options as data: whether it offers a shuttle, loaners, pickup or mobile service, and the service area for the last two. The agent asks only about options that dealership’s record lists, and the address field is required only when pickup or mobile service is chosen.

A caller profile store. Name, vehicle and recent service saved against the phone number live in your own store, not in Xtime. It is personal data: keep only those fields, set a retention period and delete profiles that pass it.

A retry-safe create. Calls drop. If the line cuts out after the agent sent the booking and before it heard the result, a naive retry or a callback can book the same car twice. Record each booking attempt on your side, tied to the call, before you send it. On any retry, check that record and the customer’s existing appointments first, and only create when neither shows the booking. The same confirm-before-write pattern appears in our AI agent guardrails checklist.

Where VinSolutions fits: the sales side

VinSolutions is Cox Automotive’s dealership CRM, so on an all-Cox stack the service side and the sales side come from the same company. VinSolutions calls itself “the AI-powered CRM with exclusive Cox Automotive shopper data and integrations with top industry providers”, and Cox’s brand list carries it next to Xtime (both as of October 2026).

Partner access points to the same place. VinSolutions’ integrations page tells vendors “If you are interested in becoming an integrated partner please visit our API Storefront”, and that link goes to Cox Automotive’s developer site, the one that hosts the Xtime reference documentation (as of October 2026).

On the Innovative AI build, sales follow-up runs through VinSolutions. The agent works through leads who visited a dealership and didn’t buy: a message first, then a call to learn the reason, such as price or a different car, and to capture what they want. It closes by telling them a supervisor will call back.

When a dealer group runs more than one vendor

Our build was all Cox Automotive: Xtime for service, VinSolutions for sales, and other Cox products at other rooftops. Not every group is. Cox’s own brand list, as of October 2026, includes Xtime for service, VinSolutions for CRM and Dealertrack for dealership management. A group whose CRM or dealer management system comes from another vendor is dealing with that vendor’s access program as well. CDK Global, for example, runs its own automotive API platform, Fortellis; the fortellis.io footer says “Fortellis is a trademark of CDK Global, LLC”. That means a second company, a second contract and a second style of API, and it was not part of the Innovative AI build.

The design we recommend for any mix of systems, including several products from one vendor, is one internal model and one adapter per system:

• One internal shape for a vehicle, a service, an appointment and a lead, used by the agent’s logic everywhere.
• One adapter per vendor , which translates that shape to Xtime, to VinSolutions or to the next system, and owns its credentials and error handling.
• Per-dealer configuration that says which adapter handles scheduling and which handles leads at each rooftop.

Our recommended design: adding a dealership on a different stack means an adapter, not a new call flow.

The agent’s prompts and tools then talk about appointments and leads, never about a vendor. Adding a dealership on a different stack means writing or reusing an adapter, not rewriting the call flow.

Rolling out dealer by dealer

An Xtime integration goes live one dealership at a time, because each one opts in with its own invitation code. Each rooftop also brings its own menu: op codes vary by dealership and system, and myKaarma’s documentation says dealerships “may contain a large number of opcodes, sometimes exceeding thousands”, which is why its API pages through them (myKaarma docs, as of October 2026).

Our recommendation is one test rooftop first, with a checklist per dealership after it:

Checklist per dealership, after the test rooftop

1. Invitation accepted: Test bookings visible to the service team.
2. Menus pulled: For the vehicles that dealership services most, and a sample of plain-language requests matched against them.
3. Transport options set: Shuttle, loaner, pickup, mobile service, and the service area for the last two.
4. Handoffs set: Handoff numbers and hours for service advisors and the sales desk.
5. Test calls: In noisy settings and with a range of accents, since those, along with requests too odd to match, were behind our misses.

Only move to the next rooftop when the first one’s service team trusts what lands in its schedule.

When not to build your own integration

A single dealership that wants after-hours answering and basic booking should buy a product that is already integrated with Xtime. The case is clearest on the integration side: a product already integrated with Xtime has done the partner work once, and a one-store build would repeat the agreement, review and demo for one invitation code. Xtime’s Schedule page lists a voice add-on (Brooke.ai), as of October 2026.

Building custom is our business, so read this with that bias in mind. The wider buy-or-build call, including when a custom agent pays off, is in the buy-or-build section of our scheduling guide.

What an integration adds to the build cost

An Xtime integration fits inside a Fixed-Price Build of $25k–$120k, and where it lands in that band depends on how many systems the agent talks to, not on the Xtime connection alone. Scheduling through Xtime with the op-code matcher, slot negotiation and retry-safe booking is one scope. Adding VinSolutions for sales follow-up, outbound calls and per-dealer adapters is a larger one. We fix the price after a $5,000 Discovery Sprint, and the pricing page shows the model.

Two costs sit outside our quote: Cox’s partner and per-dealer fees, and the time the business review and certified demo take. Put both in the budget before the build starts.

Before you scope it, have these ready: who will hold the Xtime agreement and the CRM access, the list of rooftops and the systems each one runs, the transport options each offers, and where calls should go when the agent hands off. With those four answers, a discovery sprint can price the work. For how this looks across the dealership, see our page on car dealership software.

Sources

1. Xtime API report card, Supergood (third-party assessment, last verified October 2026)
2. Xtime Schedule, Xtime (Cox Automotive)
3. Our brands, Cox Automotive
4. Auto Dealership CRM & Sales Software, VinSolutions (Cox Automotive), as of October 18, 2026
5. Integrations with VinSolutions, VinSolutions (Cox Automotive), as of October 18, 2026
6. Fortellis, Fortellis (CDK Global), as of October 18, 2026
7. How to get operation codes and service-menus, myKaarma, as of October 2026

Originally published at apptycoons.com.

In 2025 a researcher scanned 1,645 apps built with Lovable and found 170 of them, about 10.3%, with database access rules loose enough that strangers could read or change the data. The record for that issue, CVE-2025-48757, scores it 9.3 out of 10. Lovable disputes it, on the grounds that each customer is responsible for protecting their own app’s data.

That dispute is the whole problem in one line. The tool built the app. Making it safe to run is still the owner’s job.

If you built a prototype with an AI tool and people already use it, the hard question is behind you: the idea works. What is left is the work nobody sees in a demo. It covers who can read which row, what happens when a payment call times out, whether Apple will accept the build and who holds the keys. This guide is the checklist for that work, and a way to decide what to fix and what to rebuild.

Why AI-built prototypes break once real users arrive

AI-built prototypes break in production because the tools optimize for a working screen, not for the conditions around it. The complaints are usually the same five: it breaks once real users arrive, it fails a security review, it can’t connect to the systems the business uses, the app store rejects it, and nobody understands the code.

The security part is measured. Veracode tested more than 100 large language models on 80 coding tasks and found security flaws in 45% of the results. Java failed more than 70% of the time. The models left code open to cross-site scripting in 86% of the relevant cases and to log injection in 88%. Larger models did not do significantly better than smaller ones.

How often AI-generated code failed Veracode’s security checks

• All tasks: 45%
• Java tasks: 70%+
• Cross-site scripting cases: 86%
• Log injection cases: 88%

Veracode, July 30, 2025: more than 100 models, 80 tasks. Veracode sells application security tools.

Operations fail in a different way. In July 2025, during a code freeze, Replit’s AI agent deleted a live company database in a test run by SaaStr’s founder, erasing records for more than 1,200 executives and over 1,190 companies, according to Fortune. Replit’s CEO called it unacceptable. The company then announced automatic separation of development and production databases. That separation is exactly the kind of thing a prototype skips.

None of this means the prototype was a mistake. It proved the product. It was never built to carry other people’s money and data.

The production-readiness checklist for an AI-built app

Each item below has a test you can run or ask for. If nobody can show the test passing, treat the item as open.

Security

• Server-side access rules. Every read and write is checked on the server, not hidden in the interface. Test: log in as one user, change the record ID in a request to another user’s, and confirm the server refuses.
• Row-level security, deny by default. On Supabase and similar backends, every table with user data has row-level security switched on and a policy per action. A table with no policy should return nothing, not everything.
• Secrets out of the client. No service keys, AI API keys or payment secrets in the browser bundle or the mobile app. Calls that need them go through your server. Rotate any key that was ever shipped to a client.
• Input validation. Every form and API input is validated on the server for type, length and format, and output is escaped. That is where cross-site scripting and log injection start.
• Auth that can be revoked. Email verification where identity matters, rate limits on login and password reset, and sessions you can end from the server.

Watch out

A missing policy is an open door

In CVE-2025-48757, insufficient row-level security let unauthenticated users read or write tables in generated sites. Test with a logged-out request and with a second account, not only as yourself.

Data

• Backups you have restored. Automatic backups, plus one restore into a separate environment to prove they work.
• Separate development and production. A different database and different keys for each, so a test, a migration or an agent can’t touch live data.
• Migrations in version control. Schema changes are scripts in the repository, run the same way every time, not edits made in a dashboard.
• A ledger for money. If the app holds balances, credits, commissions or payouts, record every movement as an entry and derive the balance from the entries. A balance column that gets overwritten can’t be audited or reconciled with the payment provider.

Reliability

• Idempotent payment and booking calls. A retried request must not charge twice or book twice. Stripe’s API takes an idempotency key for exactly this: repeat the request after a connection error and it does not create a second object. Your own booking and order endpoints need the same rule.
• Retries with limits. Calls to outside services retry with backoff, then stop and record the failure instead of looping.
• Webhooks handled once. Payment and subscription webhooks are verified, stored and processed once, even when the provider sends them twice.
• Error tracking and monitoring. Errors reach a named person, with alerts on failed payments, failed jobs and spend on AI APIs. Rate-limit anything that costs money per call.

Integrations

• Gated APIs planned early. Some systems have no self-serve key. Dealership scheduling software is one example: access to Xtime runs through Cox Automotive’s partner program, with an agreement, fees and a certified demo, and then each dealership opts in. Our Xtime API integration guide lists the steps. Find out which of your integrations work like this before you promise a launch date.
• Writes that can be undone. Every write to another system has error handling and a way to correct it.

App stores

• Apple guideline 4.2. An app needs “features, content, and UI that elevate it beyond a repackaged website.” A web prototype wrapped in an app shell is the case this rule describes.
• Apple guideline 4.2.6. Apps “created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content.” Submit from your own developer account, under your own name.
• Store rules for payments. Apple’s guideline 3.1.1 requires in-app purchase for access to features or content inside the app, subscriptions included. That changes your fees and your revenue math, so check it before you price the plan.

Code ownership

• Accounts in your company’s name. The repository, cloud, database, domain, Apple and Google developer accounts, payment provider and every API key. Nothing held by a freelancer or a builder platform alone.
• A build that runs outside the tool. Someone other than the original builder can clone the repository, run it locally and deploy it from written steps.

Maintainability

• Tests on the paths that move money or data. Not full coverage: sign-up, login, payment, booking and anything that deletes.
• One way of doing each thing. Prompt-by-prompt building can leave duplicate libraries and parallel auth flows. Pick one of each and delete the rest, because dead generated code is still reachable code.
• A README a new engineer can follow. How to run it, how to deploy it, where the secrets live and who to call.

Fix or rebuild: how to decide

Fix the prototype when its foundations are sound and the problems are local. Rebuild the parts whose foundations are wrong, which is rarely the whole app. The test is not how the code looks. It is whether the data model and access model can express what the product has to do.

Fix in place or rebuild a layer

Fix in place (Foundations hold)

• Every row records which user or organization owns it
• Problems are local: a missing policy, an exposed key, no backups
• The app builds and deploys outside the AI tool

vs

Rebuild the layer (Foundations don’t)

• Ownership isn’t in the schema, so access can’t be enforced
• Money is an overwritten balance with no history
• Each change breaks another feature and nobody knows why

Two more cases point to a rebuild. The first is a platform limit: an app that has to control hardware over Bluetooth, run in the background or pass review as a native app may need native code the builder can’t produce. The second is an integration that needs a server-side partner connection the prototype has no place for.

The usual pattern per layer. The audit decides for your app.

The usual result is a mix. The screens stay, because they are what users already know. The access rules get rewritten. The data model gets a review, and the money tables get a ledger.

Can the AI tool make the app production ready on its own?

Partly. An AI tool can fix a named issue fast, and our own engineers use AI tools every day. What it can’t do is decide what to check, notice what is missing or answer for the result. Production needs a senior engineer hands-on: someone who reads the access rules, runs the restore and signs off on the payment flow.

Professional developers already work this way. In Stack Overflow’s 2025 survey of developers, 72% said vibe coding is not part of their professional work. More developers distrusted the accuracy of AI tools (46%) than trusted it (33%). And 75.3% said they would ask a person when they don’t trust an AI’s answer. Google’s DORA 2025 report, from nearly 5,000 technology professionals, describes AI’s main role in software development as “an amplifier”. It strengthens a team’s good practices and its bad ones alike.

So the question is not AI or no AI. It is whether someone with production experience is steering it.

What a production-readiness audit should deliver

A useful audit ends with decisions, not a list of worries. Ask for these before you pay for one:

• A findings list ranked by risk. Each finding says what is wrong, how it was tested and what an attacker or a bad day could do with it. Launch blockers are marked as blockers.
• A fix-or-rebuild call per layer. For screens, business rules, data model, access rules, integrations and hosting, with the reason.
• An ownership inventory. Every account and key, who holds it now and the steps to move it to you.
• Integration and store risks. Which APIs need partner approval, and how long it takes. Whether the app is likely to pass App Store review as built.
• A fixed quote for the fix list. Scope, price and order of work, so you can compare it with rebuilding or doing it in-house.

From prototype to production

1. Prototype: Real users, proven demand
2. Audit: Test each checklist item
3. Fix list: Ranked, with a fix-or-rebuild call
4. Harden: Fixed scope, fixed price
5. Launch: Accounts and code in your name

Who does the audit matters as much as the list. At Apptycoons it is done by our senior engineers, who were writing production code before AI tools existed. A technical project manager then turns the findings into a scope. The first conversation is free. The audit itself is scoped and priced before it starts, and if the fix list is big enough to be a project, it is quoted as a Fixed-Price Build in our $25k–$120k band. Our guide to fixed price or time and materials explains why we quote that way.

Where our builds cover these parts

None of the apps below started as an AI-built prototype. We built them from scratch, and each one covers a part of the checklist above.

• Access by role. Switch is shared banking for clubs and teams. An account belongs to a group, so treasurers, admins and members each get different rights over money and cards, and a card’s state has to show the same on every device.
• Money that reconciles. Freedom Pro pays commissions to a partner network and holds USD and stablecoin balances. The same team activity must always produce the same commission, and balances have to reconcile with the provider’s records.
• Payouts and store purchases. DubCam pays creators 50% of each subscription on the first of the month, with subscriptions on the phone apps running through in-app purchases. The revenue share guide covers the ledger and the store fee math.
• A native app through review. OHM Fitness runs separate native iOS and Android apps that control a 20-electrode suit over Bluetooth LE, live on the App Store and Google Play.
• A gated integration. Innovative AI runs voice agents that book dealership service in Xtime, one of the systems you can’t reach with a self-serve key.

If you want us to do this work on your app, our AI prototype to production service runs the audit and the fixes at a fixed price. For new web apps, our web app development page describes how we build them. For store releases, see mobile app development.

When you don’t need an agency

You don’t need an agency if the app is a demo, a waitlist or an internal tool with a handful of users, no payments and no sensitive data. Keep building with the AI tool. Work through the security and data sections of the checklist yourself, and turn on backups.

One experienced freelance engineer is often enough when the app has one clear risk: a missing access policy, an exposed key, a deploy that only works from the builder. Ask them to show you the tests passing.

A senior team earns its cost when several of these are true at once: money moves through the app, it stores personal data, an integration needs partner approval, a native app has to pass review, or you plan to raise money and someone will look at the code. If two or more apply, book an audit and bring the repository, the list of accounts and the problem that worries you most.

Sources

1. AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks, Veracode Research Reveals, Veracode (July 30, 2025)
2. CVE-2025-48757 Detail, NIST National Vulnerability Database (published May 30, 2025; disputed by the supplier)
3. Statement on CVE-2025-48757, Matt Palmer (2025)
4. An AI-powered coding tool wiped out a software company’s database, then apologized for a ‘catastrophic failure on my part’, Fortune (July 23, 2025)
5. App Review Guidelines (4.2 Minimum Functionality), Apple Developer (checked October 19, 2026)
6. Idempotent requests, Stripe API reference (checked October 19, 2026)
7. 2025 Stack Overflow Developer Survey: AI, Stack Overflow (2025)
8. DORA 2025 State of AI-assisted Software Development Report, DORA, Google (2025)

Originally published at apptycoons.com.

A production AI agent costs $25k–$120k to build at a fixed price, after a $5,000 two-week discovery sprint, and then tokens, hosting and monitoring every month. The tokens are the small part: a workflow agent that handles 20,000 tasks a month costs about $36 a month on Claude Haiku 5.5 and about $676 on Claude Sonnet 5.5 at list prices. That gap is the whole story of AI agent cost: the model is cheap, and the system that lets it act safely inside your CRM or ERP, with approvals and an audit log, is not.

The figures below are the ones on our pricing page, the same ones we quote against.

How much does an AI agent cost to build?

A production AI agent costs $25k–$120k as a Fixed-Price Build, after a two-week, $5,000 Discovery Sprint whose fee is credited to the build. Where a project lands in that band depends on three things: how many systems the agent touches, how much it may do without a person, and which compliance rules apply. The same math holds for agentic AI development in general: the cost follows the number of tools an agent can call and the actions it may take on its own, not the model you pick.

The total cost of an agent has three parts, and most budgets only plan for the middle one:

The three costs of an AI agent

What you pay for in discovery, build and run

Each phase removes a different risk.

Discovery: proving the agent can work on your data

Discovery is two weeks with a senior architect. It ends with a prototype running on your real data (not a slide deck), the architecture, a plan for each integration, and a fixed quote. Its job is to surface the problems that make AI projects overrun: data that is messier than the demo set, APIs that need approval to access, and approval rules nobody wrote down.

Build: turning a prototype into a system you can trust

The build is where most of the money goes, and little of it is spent on the model. It pays for connecting the agent to your systems of record, adding approval steps for high-impact actions, writing an evaluation set that proves the agent behaves, a security review, and launch. Work happens in two-week sprints with live demos, and the code sits in your repository from day one.

Model calls are one part of seven. The build pays for integrations, approvals, the audit log, the evaluation set and guardrails; model calls and hosting are monthly run costs.

Run: the monthly bill after launch

Running costs are model tokens, hosting, logs and monitoring, plus the time to update prompts and models as vendors release new versions. For most business agents tokens are the smallest of these at modest volume, and the largest at high volume. The worked example below shows how to estimate them.

AI agent cost by type

The type of agent decides most of the build price, because it decides how many systems the agent touches and how much it is trusted to do alone. The ranges below are how we place work inside our published band; the fixed quote comes from discovery.

Where common agent types land in a $25k–$120k build

Two of our own builds sit at different points on that table. Superdeal is a workflow agent inside a campaign CRM: its scope is creator discovery on three social platforms, drafted offers, and an approval step on everything it sends. A multi-agent research system we built sits at the top: specialist agents run in parallel over 20+ data feeds and uploaded documents, and every finding cites its source. Its scope is much larger than Superdeal’s, and the reasons are integrations and documents, not the model.

Two agent types carry extra line items the table does not show. A single-task assistant that answers from documents is a RAG system, and the RAG assistants we build are priced by how messy and permissioned those documents are; RAG development cost breaks that down. Voice agents add telephony, speech-to-text and text-to-speech to every minute of every call, which AI voice agent cost prices line by line.

Where the build budget goes

On our own agent builds, roughly 30% of the build price goes to integrations, about 20% to approvals, the audit log, security review and launch, 15–20% to the evaluation set, and only about 15% to the agent itself: its prompts, tools and orchestration. The rest, roughly 15–20%, covers data preparation, the admin screens for approvals and reports, project management with sprint demos, and the 30 days of support after launch.

How a typical build price splits on our agent projects (approximate)

• Integrations: about 30%
• Approvals, audit log, security, launch: about 20%
• Evaluation set: 15–20%
• Data prep, admin screens, project management, support: 15–20%
• The agent: prompts, tools, orchestration: about 15%

Rough shares from our own builds. A read-only assistant spends less on integrations; a regulated one spends more on safety and launch.

The agent is the smallest line. When a quote is mostly “AI development” and says little about integrations or evaluation, it is pricing the part that is cheapest to get right.

What drives the cost of an AI agent?

Five things move a quote, and the choice of model is not one of them. Model choice changes the running cost, but it rarely changes the build price by much.

Cost drivers and how to keep each one down

Integrations are usually the biggest line item

An agent that cannot read from and write to your systems of record is a demo. Each integration means authentication, handling the API’s limits and failures, mapping fields, and testing what happens when a write half-succeeds. With three or more integrations, this work can outweigh the agent logic itself.

Evaluation is what makes an agent shippable

Pilots skip evaluation and pay for it later. An evaluation set is a library of real cases with the correct outcome, run against every prompt or model change. It is the difference between “it worked in the demo” and “we know it works”. Budget for it as its own line: someone has to collect the cases, agree the correct outcomes with the people who do the work today, and rerun the set whenever a prompt or model changes. We cover why skipping it stalls projects in why AI pilots stall before production.

Human approval is cheaper than full autonomy

Every step an agent takes on its own needs guardrails: confidence thresholds, limits, rollback and logging. Putting a person on the high-impact steps for the first months is faster to build and easier to get past risk and compliance review. You remove approvals one by one as the logs show the agent is reliable. Our checklist of AI agent guardrails lists the controls an agent needs before any approval comes off.

Worked example: what an AI agent costs to run each month

An agent’s running cost is mostly tokens: the text sent to the model and the text it writes back. Here is the arithmetic for a realistic workflow agent, using list prices from Anthropic’s pricing page.

Assumptions: the agent handles 20,000 tasks a month. Each task makes four model calls. Each call sends 6,000 input tokens, of which 4,500 are a stable system prompt and tool definitions that prompt caching can reuse, and gets back 500 output tokens. List prices per million tokens, checked October 29, 2026, are $2 input, $0.10 cache read and $10 output for Claude Sonnet 5.5, and $0.10, $0.01 and $0.50 for Claude Haiku 5.5 (its price for prompts up to 100,000 tokens, which covers this example). Anthropic bills cache reads at 0.1 times the input price on most models and at 0.05 times on Sonnet 5.5.

Monthly token cost for 20,000 tasks (list prices)

How the cached Sonnet 5.5 call is worked out: 1,500 uncached input tokens at $2 per million is $0.0030, 4,500 cached tokens at $0.10 per million is $0.00045, and 500 output tokens at $10 per million is $0.0050, so about $0.0085 per call. Four calls per task and 20,000 tasks give about $676. The small premium for writing to the cache is left out because it is paid once per cache window, not per call.

One cached Sonnet 5.5 call, about $0.0085

• Output, 500 tokens: $0.0050
• Uncached input, 1,500 tokens: $0.0030
• Cached input, 4,500 tokens: $0.00045

Four calls per task and 20,000 tasks: about $676 a month.

Three things change this number more than the model price does:

• Caching. Reusing the stable part of the prompt roughly halves the bill here.
• Routing. Sending easy steps to a small model and only hard ones to a larger model lowers the average cost per task; at these list prices the gap between the two tiers is about 19x, so routing matters more than it did a year ago.
• Tokenizer. Anthropic notes that Claude 4.7 and later models use a tokenizer that produces about 30% more tokens for the same text, so estimates made with an older tokenizer will run low.

The same agent at 2,000, 20,000 and 100,000 tasks a month

Token cost grows in a straight line with volume; the build price does not move. Multiplying the per-call figures above by four calls per task gives these monthly totals:

Monthly token cost by volume (4 calls per task, list prices checked Oct 29, 2026)

Read across a row and the cheapest option is always the small model with caching; read down a column and only volume changes the bill. At 2,000 tasks the model is a rounding error next to hosting. At 100,000 it is a real line, and caching and routing decide whether it is $178 or $6,800.

On top of tokens, budget for hosting the agent service, logs and traces, and scheduled evaluation runs. These depend on your cloud and your retention rules, so treat them as their own line rather than guessing a percentage.

What an AI agent costs to maintain after launch

Maintenance is the engineering that keeps an agent correct while everything around it changes. The model bill is predictable; these four jobs are what surprise budgets:

• Model and price changes. Vendors retire models and change prices; each switch means rerunning the evaluation set before the new model goes live.
• Evaluation reruns. Every prompt change, tool change or new edge case from production goes through the full test set, and the set grows as users find new cases.
• Monitoring and traces. Someone reads the logs of failed and escalated tasks each week and turns them into fixes or new test cases.
• Integration drift. When a connected CRM, ERP or API changes a field or an auth flow, the agent starts failing without an error message unless a test catches it.

Our builds include 30 days of support after launch. After that, owners usually choose small fixed-price change requests for occasional updates, or a Dedicated Team when the agent has a roadmap of its own. We don’t publish a maintenance percentage of the build price, because it depends on how many integrations can drift and how often your process changes, not on what the build cost.

Why AI agent cost estimates range from $5,000 to $400,000+

Published estimates span two orders of magnitude because they put very different systems under one word. The cost guides that ranked for “AI agent development cost” when we checked on October 29, 2026 put an agent anywhere from about $5,000 to more than $400,000, and few of them show how they got there.

• The low end, roughly $5,000 to $25,000, is a rule-based bot or a prototype: one data source, read-only, no evaluation set, no approvals.
• The high end, $150,000 to $400,000 and more, is a multi-agent system in a regulated industry, built by a full team over six months or longer.
• The middle is a production agent that reads and writes real systems, with approvals, an audit log and an evaluation set. Our fixed-price band, $25k–$120k, covers that middle; a prototype costs less (our discovery sprint ends with one, for $5,000), and larger programs are split into phases.

Treat any published range as a way to sort scopes, not as a price. The number that counts is a fixed quote against a named scope.

Why quotes for the same AI agent differ so much

Two quotes for the “same” agent usually describe different systems. One vendor prices a prototype with a read-only connection; another prices writes, approvals, an audit log and a test set. Before comparing totals, line the quotes up against six questions:

Check every AI agent quote for these six items

Watch out

A thin quote is not a cheaper one

A quote that is low because it leaves out the evaluation set or the approval steps is not cheaper; it moves that cost to after launch, when it is paid as an incident.

For the questions to put to the vendor behind the quote, see questions to ask an AI agent development company.

Fixed price vs time and materials for an AI agent

A fixed price after discovery protects the buyer from overruns; time and materials protects the vendor. For AI agents, where the main risk is unknown data and integrations, the fix is to resolve those unknowns first and then fix the price, which is what discovery is for.

Pricing models for an AI agent build

We recommend fixing the price for the first production version, and moving to a Dedicated Team only if the agent becomes a product with its own roadmap. The trade-offs between the contract models are in our guide to fixed price vs time and materials.

When a custom AI agent is not worth paying for

A custom agent is not worth its build price when a product already does the job at your volume for less. The quickest test is arithmetic: multiply the product’s usage price by the volume you expect in year three, and compare it with the build plus three years of running cost.

Two published price lists show what that comparison looks like. Intercom lists its Fin AI Agent from $0.99 per outcome, so 1,000 outcomes a month is about $12,000 a year, well under a $25k build plus hosting and maintenance. Microsoft sells Copilot Studio as packs of 25,000 credits for $200 a month, which suits internal assistants that live inside Microsoft 365. At that kind of volume, inside tools you already use, buying wins on cost.

The arithmetic turns the other way when volume grows, when the agent has to write to your own systems, or when how it works is part of what you sell. A full three-year model, the lock-in questions to put to vendors, and the part-bought, part-built setup most agents end up with are in build vs buy AI agents.

When does an AI agent pay for itself?

An agent pays for itself once the monthly value of the work it takes over, minus its monthly running cost, has added up to the build price. Because our discovery fee is credited to the build, the upfront cost is the build price alone:

Payback in months = build price ÷ (monthly value of work handled − monthly running cost)

Volume decides the answer far more than the build price does. The example below uses stated assumptions; swap in your own. A support agent fully resolves half of the tickets it sees, each ticket takes a person 6 minutes, and an hour of that person’s time costs $40 fully loaded, so each resolved ticket is worth $4. Running cost (tokens, hosting, monitoring) is set at $1,000 a month at 2,000 tickets and $1,500 at 10,000.

Payback at two volumes and both ends of our build band (assumptions above)

Two things follow. At low volume a simple agent can pay back within a year, but a complex one rarely does, so either narrow the scope or buy a product. And the running cost belongs in the formula: leaving it out flatters the result most at low volume, which is exactly where the decision is closest. If the payback runs past two years at your volume, read build vs buy AI agents before you commit to a build.

How to budget for an AI agent project

Budget for the system, not the model. A realistic plan has four lines:

Four budget lines for an AI agent

1. Discovery: $5,000 (Weeks 1–2): Two weeks, ending with a working prototype and a fixed quote.
2. Build: $25k–$120k (6–16 weeks): Depending on agent type, integrations and compliance.
3. Run (Every month): Tokens from a worked estimate like the one above, plus hosting and monitoring.
4. Change (Ongoing): Model and prompt updates as vendors ship new versions, either as small fixed-price changes or a dedicated team.

Then pick one workflow and one number to move, such as hours saved, tickets resolved or decisions made per day, and hold the build to it. That keeps scope honest and makes the return easy to measure. If you want a fixed price for your own agent, our AI agent development team starts with a free AI audit: book the audit and bring the workflow you have in mind.

Sources

1. Claude API pricing, Anthropic
2. Intercom pricing (Fin AI Agent), Intercom
3. Microsoft Copilot Studio pricing, Microsoft

Originally published at apptycoons.com.