Custom AI agent development for work that crosses systems

A custom AI agent is a language model that can call tools: search the CRM, read a ticket, update a record, send a message. It works through a task in several steps and picks each step from what it finds. A chatbot answers questions. An agent finishes work.

That sets the risk. A chatbot that gets something wrong writes a bad sentence. An agent that gets something wrong can refund the wrong order, so most of the build is about tools and limits.

A copilot sits in between: an assistant inside a tool your team already uses, such as a CRM sidebar, that drafts while a person decides. Many agents should ship first as copilots and earn autonomy from their logs.

If fixed rules do the job, we build business process automation instead, because it is cheaper to run and easier to audit. The longer comparison is in AI agents vs automation vs chatbots.

Yes, if the tool has an API, and most business software does. We connect agents to HubSpot, Salesforce, Zendesk, Intercom, Gmail, Outlook, Slack, Microsoft Teams, Stripe and internal databases. Where a vendor publishes a Model Context Protocol server, we use it. Otherwise we write the connector on the models' standard function calling interface.

Each connection runs on its own service account, scoped to the job description. A support agent might read orders, write internal notes on tickets and send nothing to a customer without approval. It never gets admin rights because they happen to be convenient.

People meet the agent where they already work. A sales rep gets a Slack message with the lead summary and a button to accept the suggested owner. A support rep sees a drafted reply as an internal note in the helpdesk. Nobody learns a new app.

There are 2 limits worth knowing early. Tools without an API, such as some older desktop accounting software, need a workaround: a scheduled export, a shared inbox or a person in the loop. And an agent is only as current as the data it reads. If your CRM runs a month behind, so will the agent. Map flags both before you sign anything.

With several layers, each built on the assumption that the one before it can fail. The model will sometimes misread a case, so the design limits what a misreading can cost.

1. The agent can call only the tools in its job description, with the narrowest access that does the job. Read access is generous. Write access is earned.
2. Anything that moves money, changes a contract or messages a customer waits for a person's approval, until the logs justify relaxing that rule for one specific action.
3. Hard limits live in code, outside the prompt: refund ceilings, daily action caps, a monthly spend limit. The model cannot talk its way past them.
4. Everything the agent reads is treated as data. Emails and attachments can carry hidden instructions, and OWASP ranks prompt injection first in its Top 10 for LLM applications (2025) (opens in a new tab). We keep instructions apart from content and test against planted text.
5. The evaluation set runs before every change, and every live action is logged with its inputs, so a bad decision can be traced in minutes.

A supervisor can pause the agent from Slack or Teams with one command. Where the stakes stay high, such as payments or legal commitments, a person stays in the loop permanently, and the spec says so.

Most single agents cost $15,000 to $40,000 to build: one production agent with 2 to 3 tool integrations, approval steps, an evaluation set and handover. Systems with many tools, several cooperating agents, or write access to finance or contract records cost $40,000 to $90,000. A narrower agent that follows a fixed sequence of steps, such as the inbound lead qualification agent, is built as a workflow with model steps and costs $12,000 to $25,000 over 4 to 6 weeks.

The price moves with 5 things:

• Tools the agent writes to. Reading is cheap to build. Each write path needs its own approvals, limits and tests.
• Input mess. Clean form submissions are easier than free-text emails with attachments in 3 languages.
• Evaluation set size. A support agent covering 40 ticket types needs far more test cases than a lead router covering 4.
• Approval design. One approver in Slack is simple. Tiers by amount, region or customer take longer.
• Access. If credentials or a security review take 3 weeks, the calendar stretches even when the hours do not.

Running costs are billed at cost, with no markup: model usage from OpenAI, Anthropic or Google, plus hosting. We measure cost per task during Prove, so the monthly estimate in the proposal comes from your own data. Monitoring and tuning after launch is optional, at $1,500 to $5,000 a month.

When something cheaper does the job. We would rather say so on the first call than after the pilot.

Buy before you build if the work lives inside one vendor. If your whole support process runs in Zendesk or Intercom, their own AI agents deserve a trial first, and we can help you judge one against your real tickets. The same goes for the agents built into HubSpot and Salesforce. A custom agent is worth its cost when the task crosses vendors, depends on your own business rules, or when you want to own the prompts, logs and tests outright.

Use plain automation if the steps never change. A form that routes on a dropdown does not need a language model.

Wait if the process is not settled. An agent copies a process. If your team handles the same case 3 different ways, the agent will too, only faster.

If the job is answering questions from documents with no action at the end, a RAG knowledge system fits better and costs less to run.

An agent build does not include training or fine-tuning your own model (unless the evaluation set proves prompts and retrieval cannot reach the bar), consumer-facing apps, CRM data cleanup, which we scope separately, or software licenses, which you buy in your own name.