Custom AI agent development, connected to the systems you already run.

Staff stop looking up the same records in three systems and re-typing the same updates. We build custom AI agents that answer from approved sources, draft the next step for a person to approve, and act in the ERP, CRM, or ticketing system through a written list of approved actions, with an audit trail of every step.

Discuss an AI agent How the work runs

Who hires us for this

Operations, support, and technology leads with a repeated task that involves reading records, deciding a next step, and acting in one or more systems: answering customer questions, triaging and drafting replies, preparing a quote, updating a job or an order. It is also for businesses that have bought Microsoft Copilot, ChatGPT Enterprise, Salesforce Agentforce, or a similar platform and need it connected to internal systems, and for leaders who have seen agent demos and want to know what would hold up in their operation.

Why now

Staff answer the same questions from the same records and then update the same systems by hand.
The company has licensed an agent platform or copilot, and it cannot reach the ERP, the practice system, or the older database where the work happens.
A vendor has offered an agent and nobody can say what it would be allowed to do.
The board has asked about AI and the honest answer is a chatbot nobody trusts.

A decision, not a pitch

Answer, draft, or act?

Assistants earn trust in stages. The scope names the stage, and the next one is added only once the first proves reliable.

Consideration	Answers	Drafts	Acts, within limits
What it does	Answers questions from approved records	Prepares replies, summaries, and next steps	Updates records and creates tasks within a written boundary
Who decides	The person asking	The person approving	The person, for anything over the threshold
Risk	Low, with sources shown	Low, with approval	Managed, with limits and audit
Where to start	Most businesses	When answers are trusted	When drafts are trusted and the action is routine

What this covers

What custom AI agent development covers.

Assistants over your records

Answers from policies, tickets, and systems, with the source shown, permissions respected, and nothing invented.

Drafting and triage

Replies, summaries, and next steps drafted for a person to approve; requests classified and routed with the reason shown.

Bounded actions

Updating a record, creating a task, or preparing a quote inside your systems, within limits, with approval where the stakes require it.

Integration with existing systems

An integration layer, often an MCP server or a small API, that exposes approved actions in the ERP, CRM, ticketing, or practice system, including older databases without a modern API.

Connecting a platform you already license

Microsoft Copilot, ChatGPT Enterprise, Salesforce Agentforce, and similar platforms given access to internal systems through the same approved actions, instead of broad credentials.

Permissions and limits

What the agent may read, what it may do, and what always needs a person, written down and enforced per role.

Evaluation and monitoring

Accuracy and behavior measured on your data before rollout and watched after, with an owner on your side.

Inside the tools people use

The assistant in the CRM, the ticketing system, or the chat tool, not a separate window.

Controls

The controls every assistant ships with

An assistant that can act is only as safe as the limits around it. These are the parts that matter more than the model.

Control	What it means in practice
Permissions	The assistant reads and acts only with the permissions of the person it works for, never more.
Bounded actions	A written list of what it may do, in which systems, and the limits: amounts, record types, customers.
Approval points	Actions above a threshold, or with a customer relationship at stake, are proposed and wait for a person.
Sources shown	Every answer cites the record it came from; anything not found is declined rather than guessed.
Audit trail	Every read, draft, proposal, and action is recorded with who, when, and why.
Evaluation and monitoring	Behavior tested on your cases before rollout, watched after for accuracy, failures, and cost per task, with a named owner and a way to switch it off.

When companies call us

If this sounds like your business, here is where we start.

Support agents answer the same questions from the same records

An assistant in the ticketing system that answers from approved sources with the source shown, and drafts the reply for the agent.

Sales spends hours preparing quotes from past deals

An assistant that prepares the quote from the account history and pricing rules, for the rep to approve.

Dispatch triages requests by reading each one

Requests classified and routed with the reason shown, and the dispatcher able to override.

Managers want a daily brief from several systems

An assistant that summarizes the exceptions from the records, with links to each.

The company licensed a copilot and it cannot see the ERP

An integration layer that gives the copilot read actions over orders, inventory, and accounts, with the same permissions each person already has.

Documents, requests
Model stepextract · classify · draft
confidentSystem of recordsampled for accuracy
uncertainReview queueperson decides

Nothing posts without a threshold, a review path, and a sample. The exception queue has a reason and an owner.

How the work runs

Scoped in writing, built in releases, handed over.

01
Pick one task and its boundary
What the assistant reads, what it may do, and what always needs a person, written down.
02
Set the data boundaries
What the model may see, where it runs, and what never leaves your systems.
03
Prove it on your cases
Behavior and accuracy measured on real examples before rollout, with the result written down.
04
Build the approved actions
An integration layer that exposes each action to the agent with its inputs, roles, limits, and approval rule, built against your systems in a test environment.
05
Build it into the tool
The agent inside the system people use, with approval points, sources shown, and an audit trail.
06
Monitor and extend the boundary
Behavior watched after launch; the next action allowed only once the first proves reliable.

Deliverables

What you receive.

ScopeAgreed

First release · version 1.2Scope and acceptance

Includes: The core workflow, roles and permissions, and the first integration
Left for later: Reporting and the second integration
Acceptance: Criteria agreed with your team
Price: Fixed before the build begins
Start date: Agreed in writing

Approved by operations Approved by finance

RunbookHanded over

Operations · version 1.0Running the system

01Deploy a releasePipeline
02Roll back a releaseTested
03Restore from backupTested
04Alerts and who respondsCurrent
05Access and secretsBy role

Written scope
What the first release includes, what it leaves for later, the integration decisions, the acceptance criteria, and the price, agreed before development begins.
Release notes
What changed in each release, what was tested, what the security review covered, and how to roll it back.
Documentation and runbooks
How the system is built, how to run it day to day, and what to do when something fails.
Training and handover
Sessions with the people who will use and run the system, and a handover checklist your team signs off on.

Every release ships with tests, a security review, and documentation, so your team can run what we build.

Your first release

What the first release could include.

The scope is written and agreed before development starts. This is the shape it usually takes.

In the first release

One task at one stage: answers, drafts, or a bounded action
The approved actions it needs, exposed through an integration layer with permissions, limits, and approval points agreed in writing
Sources shown on every answer; declines when nothing matches
An evaluation on your real cases, with the result written down
An audit trail, monitoring, a named owner, and a way to switch it off

Usually later

The next stage for the same task
A second task on the same foundation
The assistant in a second tool

Systems it may connect

Built to work with what you already run.

ERP systems: NetSuite, Microsoft Dynamics, SAP Business One, and similar
CRM: Salesforce, HubSpot, and similar
Ticketing: Zendesk, ServiceNow, Jira Service Management, and similar
Practice and line-of-business systems, including older databases without a modern API
Agent platforms and copilots: Microsoft Copilot, ChatGPT Enterprise, Salesforce Agentforce, and similar
Microsoft Teams, Slack, and email
Identity providers for permissions
Model providers chosen for the task and the data

Regional freight carrier

Help desk agents answer tracking questions from the records and approve each reply before it goes out.

A tracking question at a regional freight carrier usually means checking the transport system, a partner carrier’s site, and the proof-of-delivery folder, then typing a reply. An assistant in the help desk tool answers from those records, shows the source for each fact, and drafts a reply for an agent to approve. It declines when nothing matches. Accuracy is measured on real past tickets before rollout. A next stage might let it open a damage claim within a written limit, with an audit trail of every action.

Where this shows up

Industries where we do this work.

Examples, not a closed list. We take substantial projects from independent businesses in other industries too.

Professional services firms

Signed proposals become staffed projects without re-keying, budget burn is visible on every engagement, and clients approve deliverables in a portal.

Technology-enabled businesses

The internal tools and customer-facing apps your service runs on, built by a senior team before you are ready to hire engineers.

Private equity portfolio companies

Software across the hold period, with a portfolio assessment for the fund and a delivery path for each company.

Another industry entirely

Describe the workflow and the systems around it. Fit depends on the work and the stakes, not the sector.

In plain terms

What is custom AI agent development?

Custom AI agent development builds software that uses a language model to read your records, decide on a next step, and, within limits you set, act in the systems you already run. The model is the smaller part. The integration with your ERP, CRM, and other systems, the permissions, the approval points, the audit trail, and the evaluation and monitoring are what make it something a business can rely on.

Custom does not always mean a new agent from scratch. Often it means connecting a platform the business already licenses to internal systems through a set of approved actions. We build in stages, answers first, then drafts, then bounded actions, and say plainly when a task should stay with a person.

Questions

Questions about custom AI agent development.

What buyers ask before a project starts, answered plainly.

What is the difference between an assistant and an agent?

An assistant answers and drafts; an agent also acts. We build both on the same foundation and add the ability to act only within a written boundary, with approval above a threshold.

Can it act without a person?

For routine actions within the limits you set, yes, with an audit trail. Anything over the threshold or with a customer relationship at stake is proposed and waits for a person.

How do you stop it inventing answers?

It answers only from approved sources and shows which one. When nothing matches, it declines. That behavior is tested before rollout on your real cases.

Where does our data go?

We agree on that in writing before anything is built: what a model may see, where it is processed, and what stays inside your systems.

What if it makes a mistake?

Every action is recorded and, where the system allows, reversible. The owner can switch the assistant off, and the mistake becomes a test case.

Should we build a custom agent or use the copilot we already license?

Use the platform where it covers the task with the connectors it provides. Build custom where the task spans internal systems, custom fields, or approval rules the platform cannot see. Often the answer is both: the platform for conversation, and an integration layer we build for the actions.

Can an agent work with our older systems?

Usually. The integration layer can use an API where one exists, a restricted database account, an export, or a message queue, and as a last resort the application’s screens. The approach is chosen per system and tested before rollout.

What is an MCP server, and do we need one?

The Model Context Protocol is an open standard for exposing tools to AI applications. An MCP server is a practical way to offer your approved actions to several agent tools at once. For a single agent, a plain API may be enough.

Does it replace the team?

It changes the work: the team approves, handles exceptions, and sets the boundary. The people who did the task usually become its reviewers.

Discuss an AI agent.

Tell us about the work and the systems around it.
We’ll come back with a written scope for a first release.