Integrate an agent through approved actions, not broad system access.
An AI agent becomes useful in a business when it can look things up and make changes in the systems where work happens: the ERP that holds orders and inventory, the CRM that holds accounts and opportunities, the ticketing system, and the line-of-business application. Integration means deciding exactly which lookups and changes it may make, and building those as named actions the agent can call.
The tempting shortcut is to hand the agent an API key with wide access and describe the rules in its instructions. That works in a demonstration and fails in operation. Instructions are advice to a model, not controls. A key with administrator rights lets the agent do anything the key can do, whoever asked and whatever the request said.
The dependable pattern is an integration layer between the agent and your systems. The layer offers a small set of actions, such as look up an order, check a customer’s credit terms, or create a return, and each action enforces permissions, limits, approvals, and logging in code. The agent chooses which action to call; the layer decides whether it runs.
Start by mapping one task across the systems it touches.
Pick one repeated task that crosses systems and has a clear definition of done. A customer asks where an order is and whether it can be returned. A sales representative needs a quote built from account history and current pricing. A technician needs the service history and parts availability before a visit. Choose a task people already do often, so there are real cases to test against.
Follow that task from request to finished record and write down every step. Which system is checked first, which fields matter, which changes are made, and who is allowed to make them? Note the judgment calls: when does a return need a manager, and when does a quote need finance? This map becomes the specification for the actions the agent will need.
The map usually shows that the agent needs fewer actions than expected, and that most of them only read. It also exposes data problems early. If the ERP and the CRM disagree about a customer’s terms, the agent will inherit the disagreement. Deciding which system is authoritative for each field is integration work that has to happen whether or not an agent is involved.
Build an integration layer that exposes each action with its rules.
Each action in the layer has a name, a plain description the model can read, the inputs it accepts, and the output it returns. Inputs are validated before anything touches the ERP or CRM. An action to create a credit note, for example, accepts an invoice number, a reason, and an amount, checks the amount against the invoice, and refuses anything outside the rules.
The layer can be a small API or an MCP server. The Model Context Protocol is an open standard that many agent platforms can call, which makes an MCP server a practical choice when more than one AI tool needs the same access. A plain API is often enough for a single agent. Either way, the business rules live in the layer, not in prompts.
Build the layer against test copies of your systems with realistic records. ERP and CRM integrations fail in ordinary ways: rate limits, locked records, required fields that differ by record type, and custom fields added over time. Each action should fail clearly and report why, rather than retrying blindly or leaving a half-finished change in one system and nothing in the other.
Carry each person’s permissions and approval rules into every action.
An agent should act on behalf of a specific person and with that person’s permissions, not with a shared service account that can see everything. When a representative asks the agent about an account, the layer checks whether that representative may see it. When a manager asks, the answer may include more. Identity comes from your existing sign-in, so roles are not recreated by hand.
Sort the actions by consequence. Reading a record is low risk. Drafting a change for a person to confirm is low risk. Changing a price, issuing a credit, canceling an order, or sending something to a customer is consequential, and those actions should pause and wait for a named person to approve them, with the agent’s reasoning and the source records shown alongside.
Set limits inside each action as well. A return can be created automatically below a value threshold and only for certain product lines; above it, approval is required. These limits are business decisions, so the people responsible for the process should set them and be able to change them without a new release. Write them down so the security team can review them.
Evaluate on real cases, then launch with monitoring and a way to stop.
Before staff rely on the agent, run it against a set of real past cases with known correct outcomes. Measure whether it called the right actions, with the right inputs, in the right order, and whether it stopped for approval when it should have. Record the results in writing, including the failures, and decide in advance what level of accuracy the task requires.
After launch, log every call with who asked, which action ran, what it returned, and what it cost. Watch for failures, slow responses from the underlying systems, and changes in model usage. Give one person on your side responsibility for the agent, the authority to adjust its limits, and a simple way to switch it off without affecting the ERP or CRM.
Extend in stages. Add a second action only once the first proves reliable, and a second task only once the integration layer has held up in daily use. This is the approach Baybloom takes when connecting agents to existing systems: one task, a written list of approved actions, evaluation on real cases, and a record of everything the agent does.
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