The integration and the controls usually cost more than the model.
Buyers often expect the language model to be the expensive part of an AI agent. In most business projects it is not. The effort goes into connecting the agent to the ERP, CRM, ticketing, or line-of-business systems, building the actions it may take, enforcing permissions and approvals, and proving on real cases that it behaves correctly before anyone relies on it.
That means the cost of a custom AI agent is shaped by the same things that shape any integration project, plus the work specific to a system that makes decisions: evaluation, monitoring, and the controls that keep it inside its limits. A simple agent that answers questions from one well-documented system is a small project. An agent that acts across several older systems is not.
The sections below describe the drivers in the order they usually matter. None of them has a standard price, because each depends on the condition of your systems and the rules of your process. A useful estimate comes from mapping one real task in detail, which also tells you whether the task is worth automating at all.
The number and condition of the systems drive most of the effort.
Every system the agent must reach adds work. A modern CRM with a documented API and test environments is the easy case. An ERP with many generations of custom fields, a practice system with a narrow API, or a database behind an application with no API at all takes more effort to connect safely, and more testing to be confident the connection holds.
Data quality matters as much as access. If two systems disagree about a customer’s terms or an item’s stock level, someone has to decide which one is authoritative before the agent can give a reliable answer. That decision and the cleanup that follows are real work, and they are often underestimated because they look like someone else’s problem until the agent exposes them.
Identity is the third factor. If the agent must act with each person’s permissions, it needs to connect to your sign-in system and map roles consistently across the systems it touches. Where roles are already well defined, this is straightforward. Where every system has a separate user list with different rules, reconciling them becomes part of the project.
Each action the agent may take adds rules, approvals, and tests.
An agent that only reads is the simplest to build and the easiest to trust. Each action that changes a record adds work: validating inputs, enforcing limits, handling the failures of the underlying system, deciding whether a person must approve it, and recording what happened. An action that touches money, customers, or regulated records needs more of each.
Approval flows add cost as well. Someone has to see the proposed action with the reasoning and the source records, approve or reject it, and have that decision recorded. If the approval happens inside a tool people already use, such as the ticketing system or Microsoft Teams, it needs integration with that tool as well.
The audit trail is part of the build, not an extra. Recording who asked, what the agent called, what each system returned, and what changed, in a form your team can search, is what lets you investigate a mistake and satisfy a reviewer. Plan for it in the first release rather than adding it after something goes wrong.
Evaluation, monitoring, and model usage continue after launch.
Before launch, the agent should be tested on a set of real past cases with known correct outcomes. Building that set takes effort from people who know the work: choosing representative cases, recording what the right answer or action was, and reviewing the results. The larger and more varied the task, the more cases the evaluation needs.
After launch there are running costs. Model usage is charged by the provider according to how much text the agent reads and writes, so an agent that pulls large records into every request costs more to run than one that retrieves only what it needs. Hosting, monitoring, and logging add to that, as does the time of the person responsible for reviewing results.
Models and the systems around them change. A new model version can behave differently, and an ERP upgrade can change a field the agent depends on. Budget for periodic re-evaluation and maintenance of the integration layer, the same way you would for any integration that the business depends on. Plan for it from the start.
Start with one task at the answering stage to keep the first release contained.
The most reliable way to contain cost is to narrow the first release. Choose one task, connect only the systems it needs, and begin with actions that read and draft rather than change records. That release proves the integration, the permissions, and the evaluation approach on a small scale, and it produces a result the team can use while the next stage is planned.
Reuse is the second lever. An integration layer built for one task can serve the next, so the second task that uses the same ERP and CRM costs less than the first. Designing the actions as a general set for the business, rather than one-off connections for one agent, is what makes that reuse possible.
Ask for a fixed scope and price for the first release, with the task, systems, actions, and evaluation written down. Baybloom scopes agent work this way, one task at a time, so the business can see what the first release includes before deciding on the second. A clear scope is also the best protection against a pilot that grows without producing anything people use.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project