TL;DR
AI agent integration connects an agent’s tool calls to approved operations in systems like ERP, CRM, ITSM and data platforms. The model only proposes a structured call, and trusted code checks it and runs it. Teams connect through direct APIs, MCP servers, iPaaS flows, RPA bridges or event queues, often mixing several. Identity, permissions and approvals belong outside the model, in a gateway the agent cannot talk its way past. Reliable integrations also need idempotency keys, bounded retries and a plan for partial failures across systems. Start read-only, add narrow write actions, test failure paths, then scale with tracing and clear ownership.
Key Takeaways AI agent integration links an agent’s tool calls to approved operations in ERP, CRM, ITSM, HR and data systems. Function calling, MCP, iPaaS, RPA and event-driven messaging each fit different systems, so most enterprises combine them. Authentication, least-privilege permissions and approval gates are enforced by trusted services, because a prompt can be overridden. Idempotency keys, bounded retries and timeouts stop a failed-looking call from creating duplicate tickets or payments. A tool gateway, scoped identities and end-to-end tracing turn a demo connector into an integration that survives production. Rollout moves from read-only access to controlled writes, then failure testing, then production with named owners. Watch on YouTube
How Enterprise AI Handles Complex Data Across Multiple Systems
A short Kanerika explainer on how enterprise AI works across many connected systems, the ground every agent integration has to cover.
The Myth That an API Key Makes an Agent Integrated
When you ask a team how their new agent connects to the ERP, you often hear a confident answer. It has an API key, a tool description and an MCP server, so it is integrated. That belief usually lasts until the first duplicate purchase order.
Gartner’s warning points the other way. The firm predicts that over 40% of agentic AI projects will be canceled , citing rising costs, unclear value and weak risk controls. In the same release, it notes that wiring agents into legacy systems is complex and often needs costly changes. A connection is the easy part, because the hard part is everything that happens when the call goes wrong.
This guide breaks down the myths one layer at a time. It covers patterns, permissions, retry rules and rollout. Together, those separate a working demo from AI agent integration a business can trust with real records.
What Is AI Agent Integration?
AI agent integration is the engineering that lets an AI agent read from and act on enterprise systems through approved, governed operations. The agent decides which tool to use, while trusted services decide whether that call is allowed and how it runs.
That split matters because a language model only produces text. So even when it “calls” a tool, it only emits a structured request, and your code carries it out. OpenAI’s function calling guide describes exactly this loop, where the application executes the call and sends the result back to the model.
How It Differs From Traditional System Integration
Classic integration wires system A to system B along a fixed path. A nightly job moves orders, or a webhook updates a ticket, and the sequence never changes.
An agent, by contrast, chooses its own path at run time. It might read a CRM account, then search a knowledge base, then open an incident, all in an order nobody scripted. So the integration has to stay safe for sequences you did not predict, which is why controls sit in the infrastructure instead of the workflow.
Read Actions vs Write Actions
Reading a customer record carries a different risk from changing one. A bad read wastes a call or leaks data if permissions are loose, while a bad write changes the business itself.
Creating a ticket, updating an invoice or changing an ERP posting all fall into the second group. That is why most teams launch agents with read-only tools first, then add write tools one operation at a time.
The Building Blocks of an Integration
Every production setup has the same core parts, whatever the vendor, so learning them pays off. Knowing them makes it easier to judge any platform you evaluate, since each one simply packages these pieces differently.
Agent runtime. The loop that sends prompts, then receives tool calls and returns results.Tool definitions. Named operations with typed inputs, outputs and descriptions.Tool gateway. The service that validates each call, checks policy and routes it.Identity layer. Tokens, service identities and the permissions behind them.Connectors. Adapters, MCP servers or iPaaS flows that reach the target system once a call is approved.Observability. Traces, logs and audit records for every call and its outcome.If one of these parts is missing, the gap usually shows up as a security finding or an outage. Map each block to an owner before writing a single connector. An AI agent architecture review or a guide on how to build AI agents helps.
Which Enterprise Systems Do AI Agents Connect To?
Most enterprise agents touch several system types. Each brings its own interfaces, permissions and failure behavior, so the integration work varies more than the agent logic.
Table 1 maps each target to its usual interface and main engineering concern.
Table 1: Enterprise Systems and Their Integration Concerns
System type Typical interface What agents usually do Main engineering concern
ERP (finance, supply chain) Vendor business APIs, OData or SOAP services, middleware Look up orders, stock and invoices; draft postings Transaction integrity and business rules CRM REST APIs, bulk and event APIs Read accounts, update cases, log activities Object and record permissions, API limits ITSM REST table and workflow APIs Open, assign and update tickets Role-based access and ticket state rules HR and payroll Vendor APIs and approved integration services Answer policy questions, start requests Sensitive personal data and tenant permissions Data warehouse or lakehouse SQL endpoints, semantic models, connectors Run governed queries and summaries Row-level security, query cost and concurrency
One rule holds across every row. An agent should call the business API that enforces validation. Writing straight to the database underneath skips the rules the application exists to protect.
Legacy ERP is the hardest case. Older platforms often lack clean APIs, so teams expose a governed copy of the data for reads. Kanerika did this by mirroring QAD ERP data into Microsoft Fabric for a global manufacturer. Writes stay on supported interfaces.
Case Study
Bringing Live QAD ERP Data into Microsoft Fabric with Open Mirroring
Kanerika connected 200+ QAD ERP tables to Microsoft Fabric for a global manufacturer, capturing new, changed and deleted records with zero duplicates on reload.
Read the Case Study → AI Agent Integration Patterns: APIs, MCP, iPaaS, RPA and Events
Because systems differ, there is no single right way to connect an agent. The right pattern depends on whether the target has a usable API, how risky the action is and what integration tooling you already own.
Direct APIs and Function Calling
With direct integration, you define a tool for each operation and map it to an API call in your own code. The model fills a JSON schema, then your service validates the arguments before anything reaches the target system.
Anthropic’s tool use documentation describes the same contract. The model returns a structured call, your application runs it and sends back the result. This pattern gives you the most control, although every new system means another adapter to build and maintain.
MCP for Standardized Tool Access
The Model Context Protocol is an open-source standard for connecting AI applications to external systems . Under its specification, servers expose tools, resources and prompts over JSON-RPC 2.0, so any compatible agent client can discover and call them.
That reuse helps, yet it feeds a second myth, the idea that an MCP server is a complete integration. The MCP specification itself says tools represent arbitrary code execution. It also says tool descriptions are untrusted unless they come from a trusted server. Authorization is also optional in the protocol, so permissions, retries and audit still have to be built around it. Kanerika’s guide to the Model Context Protocol covers protocol depth. Its LangGraph MCP integration walkthrough and its piece on context-aware agents with MCP go further.
Agent-to-agent traffic, meanwhile, is a related but separate question. The A2A protocol positions MCP for connecting agents to tools and data, and A2A for connecting agents to other agents.
iPaaS and Existing Integration Platforms
Most large companies already run an integration platform with tested connectors, mappings and error queues, so the groundwork often exists. Letting an agent call an approved iPaaS flow, instead of the raw system, reuses all of that work and keeps one place for monitoring.
Case Study
55% Faster Operations with Real-Time Data Integration
An iPaaS integration with a Dynamics 365 connector replaced eight separate systems for support staff, cutting integration time by 35% and operating costs by 37%.
Read the Case Study → The trade-off, though, is extra latency and a dependency on the platform’s connector catalog. Even so, for regulated writes such as invoice changes, routing through a flow your integration team already supports is usually the safer first step. Low-code tools sit at the lighter end of this spectrum, and the Zapier vs Power Automate comparison shows where each fits.
RPA Bridges for Legacy Screens
Still, some systems have no usable API at all. In those cases an existing RPA bot can act as the tool, so the agent decides what to do while the bot handles the screens.
This works, but it is fragile, since a changed screen layout or an expired session breaks the bot. Treat it as a bridge until an API exists, and check whether AI-driven RPA or a supported interface can replace it later. Kanerika’s RPA services page warns that bots break when underlying systems change, so plan for their upkeep.
Event-Driven Integration, Queues and Webhooks
Not every agent task should run inside a single request. Sometimes a new ticket, a failed payment or a stock alert should wake an agent. In that case an event broker or webhook delivers the trigger, while a queue holds long-running work.
However, events bring their own risks, including duplicates, out-of-order delivery and spoofed calls. So before acting on a webhook, verify its signature, as GitHub’s webhook guidance recommends. Then hand it to a consumer that can safely see the same event twice.
Table 2 then compares the five patterns on what they suit and where they break.
Table 2: AI Agent Integration Patterns Compared
Pattern Best for Main risk Who usually owns it
Direct API with function calling Well-documented APIs and a few high-value operations Tight coupling, schema drift, rate limits Application or platform team MCP server Tools reused by several agents or clients Tool trust, optional authorization, server security Platform team iPaaS flow Systems with existing connectors and governed workflows Latency, licensing and platform dependency Integration team RPA bridge Legacy screens with no usable API Broken selectors, session failures Automation team Events, queues and webhooks Triggers and long-running or asynchronous tasks Duplicates, ordering and spoofed requests Platform or integration team
iPaaS vs Custom Build: How to Choose
In the end, the build-or-buy call comes down to a handful of questions. Ask them per system, not once for the whole program, because the answers change from the CRM to the ERP.
Does a supported API exist, and does your iPaaS already have a tested connector for it? How risky is the action, and does it need the platform’s existing approvals and error queues? How fast must the agent respond, and can it tolerate an extra hop? Who will own the connector when the vendor changes its API? When a governed connector exists and the action is sensitive, reuse the platform. When you need low latency, fine-grained tools or a system nobody supports, build a custom adapter behind your own gateway instead. Ideally, a team that already runs enterprise data integration work builds it.
A Reference Architecture for AI Agent Integration
Within a wider enterprise AI architecture , a sound design keeps the model away from direct authority over business systems. The agent proposes, the gateway decides, and connectors execute, with identity and observability wrapped around every hop.
Agent runtime. Selects an approved tool and produces structured arguments, while holding no credentials of its own.Tool gateway. Registers tools, validates inputs against schemas, applies policy and routes each call.Identity and approval. Issues scoped tokens, checks permissions and pauses high-risk writes until a person approves.Connectors. Versioned adapters, MCP servers, iPaaS flows or RPA bots that reach each system.Reliability services. Queues, idempotency storage, retry budgets, circuit breakers and dead-letter queues.Observability. One trace ID from the user request through every tool call to the final system response.The gateway is the part teams most often skip, but it is also the part that makes everything else enforceable. Once every call passes through one service, you can change a permission, block a tool or add an approval without touching the agent.
Orchestration is a separate concern. How several agents hand work to each other is an AI agent orchestration question, while these layers govern how one agent touches a real system.
A security rule in a system prompt is only a suggestion. A prompt-injected document can talk a model out of it, but not a gateway out of a permission check.
Identity and Permissions for AI Agent Integration
Identity answers two questions for every call. Who is acting, and what may they touch? Get either wrong and an agent becomes a privileged account that anyone who can type to it can steer.
Delegated Access vs Service Identities
Delegated access lets an agent act for a signed-in user, usually through OAuth with scoped, short-lived tokens. The agent then sees only what that user may see, which suits CRM reads and personal requests.
Service identities, by contrast, suit background work, such as an agent that triages every new incident overnight. In that case the identity should be dedicated to the agent, scoped to its few operations and easy to revoke. MCP follows the same model for remote servers. Its authorization specification treats a protected server as an OAuth resource server, so it must check that each token was issued for it.
Least Privilege at the Operation Level
OWASP’s entry on excessive agency traces many agent failures to too much functionality, too many permissions or too much autonomy. Its fixes are plain. Give each extension the minimum scope, and require human approval for high-impact actions.
That means a tool called create_incident rather than a generic call_servicenow , and a token that can create incidents but not close them. Narrow tools also make audit easier, since each log line names a business action. Kanerika’s guide to agentic AI security covers the wider threat model.
Watch on YouTube
AI Agent Risks: When Databases Get Encrypted
A quick Kanerika short on what happens when an agent holds more access than it needs, and why scoped permissions matter.
Table 3 shows a starting access matrix that most teams adapt per system.
Table 3: Sample Access Matrix for Agent Actions
Agent action Identity model Access level Approval
Read permitted CRM records Delegated user token Scoped read Not normally needed Query approved warehouse views Governed service or user identity Read-only Not normally needed Create an ITSM incident Dedicated agent identity Create only Policy-based Change ERP financial data Delegated or approved service identity One specific write Required
Secrets, Tokens and Tool Trust
Credentials belong in a managed secret store, not in prompts, tool descriptions or logs. Short-lived tokens limit the damage if one leaks, while rotation should run without a redeploy.
Tool trust also needs the same care. Pin the MCP servers and connectors an agent may load, review their descriptions, and treat any text a tool returns as data rather than instructions. A zero trust stance, where every call is verified regardless of where it comes from, fits agents well.
Watch on YouTube
Data Agent Architecture Explained: Under the Hood #shorts
Kanerika walks through what sits under a data agent, including the governed access layer that decides which tools and data it can reach.
Error Handling: Making Agent Tool Calls Safe to Retry
Enterprise APIs fail in ordinary ways, through timeouts, throttling, expired tokens and brief outages. The myth here is that a retry fixes them, when a blind retry is how one ticket becomes three.
Idempotency Keys
An idempotency key is a unique ID attached to a write, so the target system can recognize a repeat and skip it. Stripe documents the pattern clearly. With an idempotency key , a client can safely repeat a request after a connection error without creating a second object.
Since not every enterprise API supports keys, the gateway often has to provide the guarantee itself. First it stores the key with the result. Then it checks for an existing record by external ID before creating one, and returns the stored outcome on a repeat.
Retries, Backoff and Rate Limits
Retry only errors that can heal on their own, such as timeouts, brief outages and throttling. Validation and permission errors will fail the same way every time, so retrying them just burns quota.
When a system throttles, it often answers with HTTP 429, and RFC 6585 lets that response include a Retry-After header saying how long to wait. Respect it, add exponential backoff with jitter, and cap the total attempts per call so a confused agent cannot hammer a CRM.
Timeouts and Long-Running Work
A timeout only tells you the caller stopped waiting, rather than that the write failed. The record may exist on the other side, so check its state before trying again.
For work that takes minutes, such as a report build or a bulk update, move it onto a queue. The agent gets a job ID, and either polls for the result or receives an event when it is done.
Partial Failures Across Two Systems
Unlike a database, independent enterprise APIs do not share one transaction. If an incident is created and the CRM update then fails, you now hold half a business action that someone has to finish or reverse.
Microsoft’s Compensating Transaction pattern describes how to undo completed steps when a later one fails, since a simple rollback is not always possible. For agents, that means recording each step’s state durably, so a recovery job can resume or compensate instead of starting over.
Circuit Breakers and Dead-Letter Queues
When a system is down, repeated calls only slow everything else. The Circuit Breaker pattern stops calls after failures pass a threshold, then lets a test call through once the system may have recovered.
Finally, work that still cannot complete goes to a dead-letter queue with its full context. From there, an owner can replay it safely or close it out by hand, and nothing is silently lost.
Approval Gates and Observability
Once calls are reliable, two controls turn a capable agent into an accountable one. Approval gates decide which actions wait for a person, while observability proves what actually happened afterward.
Where Human Approval Belongs
Approval belongs on actions that move money, change sensitive records or are hard to undo. Lower-risk reads and drafts, on the other hand, can run on their own, which keeps reviewers focused on decisions that matter.
The gate should show the exact proposed call rather than a summary. After approval, the gateway rechecks permissions and current state before running, and an expired request can never run later without fresh sign-off.
Tracing and Audit Records
Ideally, one trace ID follows a request from the user, through each tool call, to every downstream API and queue. With it, an on-call engineer can see in minutes which step failed and what the target system returned.
Case Study
42% Productivity Gain with API Integration and Power BI
Kanerika built an API integration layer across Jenkins, Sonar, Jira and GitHub, turning a week-long consolidation into hours and lifting productivity by 42%.
Read the Case Study → Audit records go further than logs, because they tie an identity, an approval and a confirmed business result together. Kanerika’s guide to AI agent observability covers tooling, and Table 4 lists the integration metrics worth an alert.
Table 4: Integration Metrics Worth Monitoring
Metric What it measures Why it matters
Tool call success rate Successful versus attempted calls per tool Spots a failing connector early Downstream latency Response time of each target API Finds slow dependencies Throttle rate Share of calls answered with 429 Shows quota pressure before an outage Duplicate-action rate Repeated business actions caught or missed Proves idempotency works Partial-failure count Multi-system actions left incomplete Triggers recovery work Approval wait time Delay between proposal and sign-off Reveals reviewer bottlenecks
Worked Example: A Ticket in ServiceNow, a Case Update in the CRM
Picture an illustrative case at a mid-size insurer. A support agent opens a ServiceNow incident, then writes the incident number back to the matching CRM case.
Validate the request. The agent extracts the account, issue and priority, then the gateway checks the fields against the tool schema.Read the CRM case. Because the token is delegated, it returns only records the requesting user may see.Check for an existing incident. The gateway searches by the case ID first, so a repeat request finds the earlier ticket.Apply the approval policy. Priority-one incidents wait for a duty manager, while lower priorities proceed.Create the incident. The call carries an idempotency key, so the gateway can store the returned incident ID against it.Update the CRM case. After that, the agent writes the incident number to the case through a narrow update tool.Recover from a partial failure. On one run the CRM call timed out, so the recovery job read the case, saw no update, and retried once.Confirm and record. Finally, both systems are checked, and the trace, approval and results are saved together.Step 7 is where the earlier myths would have hurt most. A blind retry of step 5 would have opened a second incident. Instead, the stored key and the state check turned an outage into a short delay.
Checklist
Data Integration Checklist for Enterprise Teams
A practical checklist for planning integrations across enterprise systems, covering sources, connectors, security, monitoring and ownership.
Get the Checklist → Common AI Agent Integration Mistakes
The same handful of errors shows up across agent programs, whatever the industry, so they are worth naming. Kanerika’s list of AI agent challenges covers the wider set, but these are the integration-specific ones.
Admin-level service accounts. One broad token turns every mistaken call into a high-impact one, since nothing limits it.Model wired straight to production. Skipping the gateway also skips validation, policy and logging.Retrying every failure. Blind retries create duplicate tickets, payments and records.Treating two writes as one transaction. Separate APIs need state tracking and compensation.Using RPA where an API exists. Screen automation costs more to keep alive than a supported interface does.Treating MCP as the whole architecture. A protocol does not replace authorization, retries or monitoring.Logging replies instead of outcomes. A confident answer does not prove a record changed, unless the system confirms it.Most of these trace back to one habit, which is building tools before writing their contracts. Well-defined AI agent skills , each with typed inputs, a narrow scope and clear errors, prevent several of them at once.
A Four-Stage Rollout for AI Agent Integration
Scope grows in stages, and each stage earns the next with evidence, much like any agentic workflow rollout. Skipping ahead is how pilots that looked fine in a demo stall at the security review.
Stage 1: Read-Only Access
First, start with approved reads and compare the agent’s answers against the source system. This proves authentication, permissions and data quality before anything can change.
Stage 2: Controlled Writes
Next, add one write operation at a time, each with its own scope, idempotency key and approval rule. Also run these in a test environment that mirrors production permissions.
Stage 3: Failure Testing
After that, force expired tokens, throttling, timeouts, schema changes and outages on purpose. Then confirm the agent recovers without duplicates. Kanerika’s guide to agentic AI testing sets out how to build those suites before release.
Stage 4: Production With Owners
Finally, go live with limited access, named owners for each connector and alerts that reach a person. After that, raise volumes and permissions only when failure rates and recovery times hold steady.
This staged approach also makes it easier to pick the right first use case. The agentic AI applications that reach production fastest tend to be read-heavy at first, with writes added later.
How Kanerika Approaches AI Agent Integration
Kanerika’s agentic AI services build agents one workflow at a time, with measured baselines and clear limits. The work follows four steps.
Pick the Workflow. Kanerika ranks workflows by volume, clear rules and cost of errors, then starts where a baseline is measurable.Design the Agent. The team defines the tools the agent can call, what it remembers and where a person approves before it acts.Connect and Test. Agents get scoped access to ERP, CRM and documents, then are scored on historical cases before go-live.Run and Improve. Monitoring, audit logs and a review loop keep accuracy up as data and processes change.Kanerika’s AI governance practice adds policy, guardrails and audit logging around those agents.
Integration Results From Kanerika Projects
Much of this rests on integration work Kanerika already delivers outside agents, especially on ERP and CRM. For a global manufacturer on QAD ERP, the team built a connection into Microsoft Fabric that picks up new, changed and deleted records. As a result, more than 200 tables stay current, with zero duplicate records on reload. That same discipline, detecting changes and never writing twice, is what agent writes need.
For a media production company, support staff had to reach eight on-premises and cloud systems to answer benefits questions. Kanerika’s iPaaS integration with a Dynamics 365 connector cut integration time by 35% and operating expenses by 37%. The FLIP platform adds low-code pipelines and EDI integration for partners still exchanging documents the old way.
Kanerika builds access controls and audit trails into the architecture before the first agent goes live. Its AI application development team builds the agent itself.
Kanerika Service
Agentic AI Services
Kanerika designs and builds production AI agents with tool gateways, scoped identities and tested connectors to your ERP, CRM and data platforms.
Explore Agentic AI Services Getting AI Agent Integration Right
So how do you integrate AI agents with enterprise systems safely? First, give the agent narrow tools and route every call through a gateway you control. Then connect each system with the pattern that fits it, whether that is an API, MCP, iPaaS, RPA or events.
Then make failure boring. Scoped identities, idempotency keys, bounded retries and full tracing mean a timeout or an outage costs a few minutes and leaves the records intact. AI agent integration done this way lets an agent act on real systems because every action it takes is checked, logged and reversible.
Frequently Asked Questions
What is AI agent integration?
AI agent integration is the engineering that connects an AI agent to enterprise systems such as ERP, CRM, ITSM and data platforms. The agent proposes structured tool calls, and trusted services validate, authorize and run them. Good integrations add scoped identities, approval gates, retry rules and tracing, so every action the agent takes is checked and recorded.
How do AI agents connect to systems like ERP, CRM and ServiceNow?
Agents reach these systems through tools mapped to supported interfaces, such as vendor REST APIs, MCP servers, existing iPaaS flows or, for legacy screens, RPA bots. A gateway between the agent and the system validates arguments, checks permissions and logs the call. Agents should use business APIs that enforce validation, never write directly to the underlying database.
What is the difference between MCP and API-based AI agent integration?
A direct API integration maps each agent tool to an application-specific call in your own code. MCP is an open standard that exposes tools, resources and prompts through one protocol, so several agent clients can reuse them. The two work together, since an MCP server usually wraps the same APIs and still needs authorization, retries and monitoring around it.
Do enterprises need an iPaaS platform for AI agent integration?
Not always. An existing iPaaS is worth reusing when it already has tested connectors, mappings and error queues for the target system, especially for sensitive writes. A custom adapter behind your own gateway fits better when you need low latency, fine-grained tools or a system no platform supports. Many enterprises use both, choosing per system rather than once.
How do AI agents authenticate to enterprise applications?
Agents authenticate with delegated user tokens, usually through OAuth, when acting for a signed-in person, or with a dedicated service identity for background work. Tokens should be short-lived and scoped to the few operations the agent needs. Credentials stay in a managed secret store and never appear in prompts, tool descriptions or logs, and every token is easy to revoke.
How do you stop an AI agent from creating duplicate records when a call fails?
Attach an idempotency key to every write so the target system, or your gateway, can recognize a repeat and return the first result. Before retrying after a timeout, check the record’s current state, because the write may already have succeeded. Retry only temporary errors, respect Retry-After headers, and cap attempts so one confused agent cannot flood a system.
Which agent actions should require human approval?
Approval fits actions that move money, change sensitive records or are hard to reverse, such as ERP postings, payroll changes or account closures. Reads and low-risk drafts can usually run alone. The reviewer should see the exact proposed call, and the gateway should recheck permissions and state after approval. Expired requests must never run without fresh sign-off.
How do you monitor AI agent integrations in production?
Give every request one trace ID that follows it through each tool call, API and queue. Track tool success rates, downstream latency, throttling, duplicate actions, partial failures and approval wait times, with alerts routed to a named connector owner. Keep audit records that tie the identity, approval and confirmed business result together, not just the agent’s reply.
What should be tested before an AI agent integration goes live?
Test the tool contracts, permissions and the full task path against a production-like environment. Then force failures on purpose, including expired tokens, throttling, timeouts, schema changes, outages and duplicate events, and confirm the agent recovers without duplicates or half-finished work. Release only when critical cases pass consistently and each connector has a named owner and runbook.
What is the difference between AI agent integration and AI agent orchestration?
Integration is how a single agent safely reaches and acts on real systems through tools, identities, connectors and error handling. Orchestration is how several agents, or several steps, are coordinated to complete a larger task. A multi-agent system still needs sound integration underneath, because every agent eventually calls the same ERP, CRM or ITSM interfaces.
