AI agents in integration: what they are and where they fit

A year ago the question was “should we try a chatbot?”. Today it is “can the assistant look up the order, check the stock and open a return?”. That second question is an integration question. An AI agent is only as useful as the systems it can reach, and only as safe as the way it reaches them.

This guide is for people who build and run integrations. It explains what an agent actually is, the building blocks that matter, where agents fit and where a plain, deterministic integration is the better answer, and how to compare the platforms.

Chatbot, workflow, agent

The three words get mixed up. A useful way to tell them apart is to ask who decides the next step.

	Who decides the next step	Example
Chatbot	Nobody; it answers from text it was given	“What are your opening hours?”
Workflow / integration	The designer, in advance	“On every new e-shop order, create a sales order in the ERP”
Agent	A language model, at run time, within limits you set	“Customer C-1042 asks where order 58821 is and whether they can change the address”

An agent receives a goal, decides which tools to call, looks at the results and decides what to do next, until it can answer or hand over. That flexibility is the point, and also the risk: the path is not fixed in advance.

The building blocks

1. The model and its instructions

The large language model (LLM) does the reasoning. The instructions (often called the system prompt) define the agent’s job, tone and limits: “You help customer service agents with order questions. You never promise refunds.” Clear, narrow instructions do more for quality than switching models.

2. Tools (function calling)

A tool is an operation the agent can call: get_order_status(orderId), get_stock(sku), create_return(orderId, reason). The model sees each tool’s name, description and parameters, and decides when to call it. Tools are where agents meet integration: behind each tool there is usually an API or an integration process that talks to the ERP, CRM or warehouse system.

Good tools are narrow and business-shaped. “Get order status for a customer” is a good tool. “Run SQL against the ERP” is not.

3. MCP: a standard way to offer tools

The Model Context Protocol (MCP) is an open protocol for exposing tools and data to AI applications. An MCP server publishes a set of tools; any MCP-capable agent or assistant can discover and call them. For integration teams this matters because you can expose a tool once and let several agent platforms use it, instead of building a separate plug-in for each. It also creates a new thing to govern: which MCP servers exist, who can use them, and what they can do.

4. Grounding on business data

Grounding means the agent answers from your data, not from what the model remembers. There are two main ways:

Retrieval from documents (policies, manuals, product sheets), often called RAG.
Live tool calls to systems of record for facts that change: order status, balances, stock.

For integration use cases the second matters more. The order status must come from the ERP at the moment of the question, not from a document indexed last week.

5. Guardrails

Guardrails limit what the agent may say and do: topics it must refuse, personal data it must not reveal, actions it may not take, and checks on its outputs. The strongest guardrail is not in the prompt but in the tools: an agent cannot issue a refund if no refund tool exists.

6. Human approval

For actions with consequences (credit notes, cancellations, anything above an amount), the agent proposes and a person approves. This is the human-in-the-loop pattern from workflow automation, applied to agents.

7. Observability

You need to see every conversation, every tool call with its inputs and outputs, and every error, with a correlation ID that links the agent’s step to the integration execution behind it. Without that, “the assistant gave the customer a wrong date” can’t be investigated.

8. Cost

Agents cost money per use: model tokens, platform fees, and the load on your back-end systems from tool calls. A chatty agent that calls five tools per question, thousands of times a day, adds up. Measure cost per conversation early.

Where agents fit, and where they don’t

Agents are a good fit when:

Requests arrive in natural language and vary a lot (customer emails, internal help-desk questions).
The answer needs several lookups that depend on each other.
A person currently does the triage: reads, looks things up in three systems, then decides.

Deterministic integration is better when:

The steps are known and fixed: an order always becomes a sales order. A process does it faster, cheaper and the same way every time.
Volume is high and latency matters: thousands of messages a minute.
Exactness is required: invoice amounts, VAT, stock movements. You want a mapping, not a model’s judgement.
Regulations require you to explain every decision step by step.

A practical split: let the agent understand the request and choose among a few well-defined operations; let integration processes carry out those operations reliably.

Common mistakes

Giving the agent broad access. A tool that can read every customer or write any field turns one bad prompt into a data leak. Design tools with least privilege.
Write tools without approval. Start read-only. Add write tools one at a time, with a human approval step.
Trusting tool inputs from the conversation. If the customer says “I am customer C-1042”, check that against the authenticated session, not the chat text.
No evaluation set. Collect 30 to 50 real questions with expected answers before launch, and rerun them after every change to instructions, tools or model.
Using an agent where a form would do. If every request has the same three fields, build a form.

How to compare platforms

Where does your data live? An agent platform close to your systems of record (or your integration platform) saves a lot of tool-building work.
Tool options. Can tools call your APIs and integration processes? Does it support MCP, as a client, a server or both?
Guardrails and approvals. What is built in, and can you add your own checks?
Identity. Can the agent act with the user’s permissions, or only as one service account?
Observability and governance. Full traces of tool calls, an inventory of agents, a way to switch an agent off quickly.
Model choice. Are you tied to one model provider, and does that matter for your data residency?
Pricing. Per conversation, per message, per agent or by tokens. Model it with real volumes.

Tools in this space

The market moves fast, and feature lists change every quarter. These are the platforms we see most often, in alphabetical order. Check current capabilities with each vendor.

Boomi Agentstudio. Boomi’s environment for designing, deploying and governing AI agents, including a low-code agent designer and a control tower for monitoring agents, including some from other vendors. Agents use tools backed by Boomi integrations and APIs, and recent releases add MCP support through a registry of MCP servers. It fits best when the tools your agents need are integrations that already run on Boomi.
Building your own with an LLM SDK. Model providers and open-source frameworks offer SDKs for tool calling, MCP and agent loops. You get full control over prompts, models and hosting, and you take on the guardrails, observability and operation yourself. A good option for teams with strong engineering capacity and unusual requirements.
Microsoft Copilot Studio. A low-code tool for building agents and copilots in the Microsoft ecosystem, with connectors to Microsoft 365, Dynamics 365 and the Power Platform. A natural choice when users work in Teams and Microsoft 365.
Salesforce Agentforce (with MuleSoft). Agents built into Salesforce and grounded on CRM data, with MuleSoft available to connect them to systems outside Salesforce. Strongest for sales, service and marketing scenarios where Salesforce is the system of record.
ServiceNow AI Agents. Agents that work inside ServiceNow workflows for IT, HR and customer service, using the platform’s data and approval model. A good fit if your service processes already run on ServiceNow.
Workato. An integration and automation platform that has added agent capabilities on top of its recipes and connectors, popular with business-technology teams that automate across many SaaS applications.

Where to go next

Two practical articles put these ideas to work in Boomi:

Building your first agent in Boomi Agentstudio: an order-status assistant for customer service, with tools backed by integration processes.
Giving AI agents safe access to business systems with MCP and Boomi: least-privilege tool design, read vs write tools, approvals and audit.

The tools behind an agent are often APIs, so our API management guide is useful background too.