Custom AI agent development: what a service business should expect

Custom ai agent development means building one software agent that does one real job inside the systems your business already runs, with limits on what it can touch and a person approving what matters. It is mostly plumbing and rules, not model training. This page walks through what the work involves, what you should be handed at the end, and how to judge a developer before you pay one.

Start with one job, not "an agent"

"Build us an AI agent" is not a scope. A job is. "When an estimate has had no reply for four days, draft a follow-up text and put it in the office manager's queue" is a job. So is "every morning at 6, pull yesterday's booked jobs, unpaid invoices and missed calls into one summary."

Anthropic's engineering team, which builds these systems for a living, recommends finding the simplest solution possible and only adding complexity when needed. Its guidance also separates fixed workflows, which suit well-defined tasks, from agents that decide their own steps, which suit open-ended problems. Most office work in a service company is the first kind. If the steps are known, build the plain workflow and let the model handle the writing or the reading inside it.

The five parts of a build

1. Data access. The agent needs a way into your software. For ServiceTitan that means a registered app, an application key, and a client ID and secret generated by an admin. For HubSpot it is a private app token, which that vendor says to rotate every six months. Every tool is different, and a developer who has done it before already knows the quirks. Ask which of your systems have a usable API before anyone quotes you.

2. Permissions. Give the agent the least access that gets the job done. OWASP, the security nonprofit, lists excessive agency as a named risk for AI systems and traces it to excessive functionality, excessive permissions and excessive autonomy. Its fixes are plain: offer the agent only the tools it needs, keep downstream access to least privilege (read-only where possible), and require a human to approve high-impact actions. A follow-up agent should not be able to see payroll.

3. Approval gates. Decide in advance what the agent may do alone and what waits for a person. Drafting a text is low risk. Sending it to a customer, changing a price, issuing a refund or promising an arrival time is not. Start with everything in a draft queue and open paths one at a time, once you have watched it work.

4. Testing. Anthropic recommends extensive testing in sandboxed environments, along with appropriate guardrails. In practice that means running the agent against copies or read-only views first, reading what it would have sent, and keeping a log of every action and the record it touched. If your software vendor offers a test environment, use it. ServiceTitan, for example, can provide an integration environment on request.

5. Someone who maintains it. Credentials expire, vendors change their APIs and your process changes. Decide who watches the logs and fixes breakage after launch.

What you should be handed at the end

Whoever builds it, the following should end up in your hands, in writing:

• The list of systems the agent connects to and exactly which permissions it has in each.
• Credentials held in accounts you own, not in the developer's personal login.
• The agent's rules: what it does alone, what it queues, what it never does.
• The prompts and configuration, so the work is not locked inside one person's head.
• An action log you can read without asking the developer.
• A plain statement of what happens if you stop working with them.

If a developer will not put those in writing, keep looking.

Build, buy or hire

Many jobs do not need custom work. If your field service software already follows up on estimates the way you want, turn that on. The Federal Reserve's survey of small employers found that firms planning to start with AI named finding tools that meet business needs as their top obstacle (54%), and current users named adapting tools to the business (43%). Custom development exists for that second problem: the job crosses several systems or follows rules no product ships with.

How Cortex does it

Cortex builds agents inside the software a service company already uses, and our trust page states the defaults: each agent gets defined access to defined systems, sensitive actions require approval, and an agent sends nothing on its own unless you have explicitly allowed that path. We start with one or two workflows, not dozens. You own your software accounts and records. We do not publish a price, and we do not quote a date before someone has looked at your systems.

What we do not do: replace your software, make judgment calls about pricing exceptions or angry customers, or connect to a vendor that offers no usable interface. If that is your situation, the audit says so.

Mistakes to avoid

• Paying before the job is defined. If the proposal says "AI agents" without naming a trigger, the data it reads and the result it produces, it is not a scope.
• Giving it admin access because it is easier. It is easier once. It is also the thing you will regret.
• Skipping the draft stage. Watch it work for a couple of weeks before it sends anything alone.
• Building an agent for a problem a setting would solve.

Next step

Book the free AI Operations Audit. You get a ranked list of workflows worth building and you owe us nothing after it. To see how agents fit together, read about AI agents, the human-in-the-loop approach, our integrations and how we work.