AI agent development services: what you are actually buying

Most proposals for AI agent development services read alike: an agent, a model, a timeline. What separates a build that runs your inbox triage or order exceptions from one that stalls after the demo is everything the proposal does not mention, such as access limits, approval steps and testing. This article lists what a competent build contains, so you can compare proposals line by line. It sits under our AI Integration & Automation work, where agents are one tool among several.

What are AI agent development services?

An AI agent is software that reads a request or a document, then chooses its own steps and tools to finish a task, rather than following one fixed path. AI agent development services cover the work of designing, building, connecting, testing and handing over an agent for a specific business workflow.

The word that matters is workflow. A useful agent does one job inside your operation: sorting a shared support inbox, checking an incoming document against a purchase order, or preparing a response to an order exception. Buying "an agent" with no workflow attached usually produces a general assistant that nobody owns and nobody can measure.

What does an AI agent build actually include?

A build has six parts. If a proposal cannot point to each one, ask where it went.

1. One scoped workflow. A written description of the job: what triggers it, what inputs arrive, what a good result looks like, who owns it, and what the agent must never do. This is the specification everything else is tested against.
2. Connections to your systems. Read and write paths into the tools the work already uses, such as Microsoft 365 or Google Workspace for email, your ERP, CRM or ticketing system for records. The goal is to connect what you have, not replace it.
3. Limited access. The agent receives only the permissions its task needs, applying least privilege to software the same way you would to a new hire. Read access to the order system does not imply permission to edit prices.
4. Approval points. A person reviews anything that sends a message, changes a record, moves money or cannot be undone, with enough context to judge it in seconds. How to design this step is covered in AI agents with human approval.
5. Testing and release. The agent is scored against real historical cases before it touches live work, then released in stages. The method is laid out in how to test AI before it touches your operations.
6. Operations and handover. Logging, monitoring, documentation, training for the people who review its work, and a clear answer to who runs it afterward.

Anything beyond these six, such as a polished interface or a branded assistant name, is optional. Anything missing from them is a gap you will pay to fill later.

How long does it take to scope and build a first AI agent?

Nobody can quote a trustworthy duration before seeing your workflow, so treat any fixed number offered on a first call with caution. What you can ask for instead is the stages and what each produces:

Delays rarely come from the model. They come from waiting on access to a system, an owner who has not been named, or a test set nobody has time to label. Settle those in the first week.

Illustrative example: Consider a regional distributor whose customer service team reads every order exception email by hand: a short shipment, a price mismatch, a missing purchase order number. A first agent could read each email, look up the order in the ERP, and prepare a proposed reply and a proposed correction for the service lead to approve. It would have read access to orders and shipments, no permission to change prices, and no ability to send anything itself. The build would be tested on a few months of past exceptions before it saw a live one.

What drives the cost of AI agent development?

Providers differ widely, so we cannot give a useful number without knowing your workflow, and this article does not quote one. The drivers are more useful than any figure, because they let you compare two proposals fairly:

• Systems connected. Each integration adds work for authentication, field mapping, error handling and testing. A system with a well documented API is cheaper to connect than one with none.
• Input mess. Typed forms are easy. Scanned documents, forwarded email chains and free text in five formats need more handling and more test cases.
• Consequence of an error. An agent drafting an internal summary needs light testing. One preparing customer messages or touching payments needs more evaluation, tighter approvals and fuller logging.
• Exception volume. The more cases fall outside the normal pattern, the more design and review capacity the workflow needs.
• Testing depth. Building the test set from real cases is often the largest single effort, and the part most often cut from a cheap quote.
• Operating model. Hosting, model usage fees, monitoring and ongoing changes continue after launch. Ask that they be itemized apart from the build.
• Who runs it. Handing the agent to your team costs training and documentation. Keeping the builder on costs a support agreement.

Where a reader needs a number for their own situation, a discovery call is the honest way to get one, and a separately scoped audit is a common first step for operations work. If you want to understand running costs in more depth, see what AI workflow automation costs to run and what it saves.

What red flags should you watch for in a proposal?

Five patterns show up often enough to screen for:

1. Autonomy with no approval step. If the agent can send, write or pay on its own from day one, the proposal has skipped the question of who answers for its mistakes. Approval can relax over time as evidence builds, but it should start in place.
2. A demo standing in for a build. A demo on three clean examples proves little. Ask what happens with a scanned page, a duplicate or an angry customer.
3. No evaluation plan. If the proposal does not say how the agent will be scored, on whose cases, and against what target, you will find out its accuracy in production. Evals should be named in the scope.
4. Vendor-owned accounts and no exit. If your data, prompts, configuration and logs live in accounts you cannot access or transfer, you are renting your own process. A vendor may host the agent, but the contract should say who owns each component and how you take it back.
5. No operating plan. Who watches the agent, who handles a failure at 6 a.m., and who updates it when your ERP changes? A silent proposal means the answer is you.

A weaker signal is a promise of broad access "for flexibility." Access should be narrow at launch and widened deliberately, as the access section of the approval guide explains. Anthropic makes a related point in its guidance for developers: it recommends "finding the simplest solution possible, and only increasing complexity when needed," and notes that this "might mean not building agentic systems at all" (Anthropic). A provider who never suggests a simpler option is worth questioning.

When is plain workflow automation the better buy?

Choose workflow automation when you can write the steps down and they rarely change: when an order arrives, check these three fields, route it here, update this record. That is cheaper to build, cheaper to run, easier to test and easier to audit, because the path is fixed. Add an AI step only where the input needs interpretation, such as reading a free text email.

An agent earns its place when the steps cannot be fixed in advance: a request could need a lookup in one system, a question to a customer, or a hand-off to a specialist, and which one depends on what the agent finds. The full comparison, including robotic process automation, is in AI agents, RPA or workflow automation: which fits the work. In practice many good solutions mix them: a fixed workflow for the clean majority, an AI step for the judgment calls and a person approving what matters.

How should you evaluate competing providers?

Ask each one the same six questions and compare the answers in writing.

1. Which one workflow would you start with, and why that one?
2. What access will the agent hold, system by system, and what can it never do?
3. Which actions need a named person's approval, and what will that person see?
4. How will you test it on our past cases, and who agrees the target?
5. What do we own at the end, and where will it run?
6. Who monitors it, who changes it, and what is priced separately?

A provider who answers specifically, even when the answer is "that depends, and here is how we would find out," is more trustworthy than one with a smooth answer to everything. The same questions appear in the wider guide on choosing an AI implementation partner.

How Kastling approaches AI agent development

We start with a discovery call, free and without commitment, to understand the workflow and who owns it. For AI and operations work a separately scoped paid audit is common, though not mandatory, and it produces the written workflow, the access review and the priorities that a build needs. A proposal follows with scope, dependencies, milestones and how success will be measured.

Development is tested against real business scenarios with the people who will review the output involved, then connected to your environment with training and an agreed owner. Agents are built to hold the access their task needs and no more, with a named person approving consequential actions. Data access and ownership are agreed up front, and maintenance is optional under a separate agreement. To talk through a specific workflow, see our AI integration and automation service.