The safest way to integrate an AI agent with enterprise software is to place it behind a controlled integration layer, not give it broad access to each system. That layer exposes narrow business tools, enforces identity and authorization, validates schemas and business rules, handles retries and idempotency, records side effects, and reconciles results with the system of record. Use supported APIs and events first; use UI automation only where a stable API is unavailable.
Key takeaways
Expose business capabilities such as
find_customer,draft_ticket_reply, orsubmit_invoice_for_review, not unrestricted CRUD or generic HTTP access.Keep authorization at the API and policy layer; restrict tokens by user, tenant, audience, scope, object, field, and operation.
Separate read, propose, approve, commit, and verify steps so consequential writes have explicit control points.
Design for duplicate, delayed, reordered, partial, and failed events; a successful model response does not prove the target system changed.
Preserve system-of-record identifiers, correlation IDs, idempotency keys, and an audit link from the user request to the confirmed transaction.
Reference architecture
A production design usually has six logical layers. The channel receives a request or trigger. The agent runtime interprets the goal and selects from an approved tool catalog. A policy and identity layer determines what that caller and workload may do. Adapters translate stable tool contracts into vendor APIs, workflows, or robotic automation. An event and job layer manages long-running work, retries, and callbacks. Systems of record remain authoritative, while telemetry links every step. These can be separate services or modules, but the responsibilities should be explicit.
Design the tool contract before the prompt
Name intent, not transport
A tool called post_json exposes too much freedom. A tool called propose_customer_address_change can require a customer ID, normalized address, source of evidence, and reason; it can return a proposal ID and required approval class without making the change. The adapter chooses the correct vendor endpoint. This makes permissions, tests, telemetry, and human review legible to the business. Keep read and write capabilities separate, and do not expose tools that the agent cannot safely select.
Specify inputs, outputs, and errors
Use strict schemas with required fields, enumerations, formats, size limits, and mutually exclusive options. Validate again inside the adapter; model-side structured output is not an authorization control. Return normalized identifiers, status, version, and evidence rather than dumping an entire vendor response into context. Define errors the agent can act on: invalid request, not authorized, not found, conflict, rate limited, dependency unavailable, approval required, and unknown outcome. Do not convert every failure into friendly prose that hides whether a transaction occurred.
Make writes idempotent and verifiable
Assign an idempotency key to the business operation, not each retry. Store the mapping from that key to the target record and outcome. Use optimistic concurrency or version checks when available so the agent cannot overwrite a newer human change. After a write, read the authoritative state or consume a confirmed event and compare it with the intended result. If the response times out, mark the outcome unknown and reconcile before retrying; otherwise one ambiguous timeout can create duplicate contacts, tickets, orders, or payments.
System-specific integration patterns
CRM: preserve identity, deduplicate, and respect limits
CRM agents commonly search accounts, summarize activity, qualify leads, update fields, or create follow-up tasks. Use stable external IDs and deterministic matching before creating records, and return only task-relevant fields. Preserve platform transaction and permission semantics. Salesforce Composite can run dependent REST subrequests and offers rollback behavior, but subrequests share one user context and platform limits. Microsoft Dataverse exposes an OData v4 Web API; retain its metadata and security model rather than flattening tables into a generic store.
ERP: protect posting and reconciliation boundaries
ERP writes can affect inventory, tax, procurement, and financial records. Let an agent extract data, match supporting documents, and prepare a proposal, while configured business rules and approvals own posting. Use documented application APIs rather than direct database changes. SAP S/4HANA documentation distinguishes synchronous OData services from asynchronous message-based services and provides operation-specific APIs. Choose the interface based on the actual process, retain document and line-item identifiers, and reconcile posted state with the source documents. A draft that looks correct is not equivalent to a posted, balanced, approved transaction.
Help desk: separate requester and agent visibility
Support platforms distinguish public requester content from internal agent information. Zendesk documents separate Requests and Tickets perspectives; an end user sees only public comments and selected fields, while agents and administrators can manage more of the ticket. Encode that distinction in separate tools. Do not let retrieved private notes leak into a public draft. Preserve requester, organization, channel, status, assignment, and comment visibility. For autonomous replies, require policy-grounded evidence, confidence or escalation rules, and a check that the ticket did not change while the response was being prepared.
Internal tools: curate the action surface
Internal APIs may be accessible yet operationally undocumented. Inventory owners, authentication, environments, schemas, side effects, rate limits, deprecation policy, and test fixtures before making endpoints tools. Generate adapters from OpenAPI or expose a curated MCP server when useful. Filter tools by caller and run; do not publish an entire API for convenience. Version tool descriptions and server responses.
Synchronous calls, events, and long-running work
Use a synchronous call when the operation is short and the immediate response is authoritative. Use a job or event pattern when work can outlive the request, involves approval, or crosses multiple systems. Standard event envelopes such as CloudEvents can improve interoperability by carrying identifiers, source, type, time, and schema references, but the specification does not define your business semantics or delivery guarantees. Document whether delivery is at-most-once or at-least-once, how duplicates are detected, how ordering is handled, and which component owns retries. Keep sensitive data out of event metadata and encrypt payloads where required.
Production checklist
Inventory each system, owner, supported API, object model, environment, rate limit, and system-of-record boundary.
Define narrow read, propose, approve, commit, verify, and compensate tools with strict schemas.
Implement OAuth or workload identity with minimum scopes, audience restriction, secure token storage, and rotation.
Map canonical business identifiers and fields to each platform without copying unnecessary data into agent memory.
Add idempotency, concurrency checks, timeouts, bounded retries, dead-letter handling, and reconciliation for unknown outcomes.
Test permissions, duplicates, stale records, partial failure, rate limits, malformed responses, unavailable dependencies, and rollback paths.
Trace the initiating identity, agent and tool versions, approvals, vendor request IDs, side effects, and final verification.
Launch read-only, then proposals, then approved writes; expand autonomous actions only after production evidence supports it.
Limitations and when not to integrate an agent directly
An agent cannot repair missing ownership, inconsistent master data, undocumented APIs, or a process that teams do not agree on. UI automation can bridge a legacy gap, but interface changes and session state make it more fragile than an API. Do not allow direct autonomous writes when the platform lacks adequate authorization, test isolation, idempotency, audit evidence, or a recovery path. A deterministic workflow, integration platform, or human-operated queue may be the right control plane, with the agent limited to interpretation and drafting.
Frequently asked questions
Should an AI agent connect directly to a CRM or ERP API?
Usually it should call a controlled adapter or integration service. That layer can enforce platform-specific authorization, schemas, transaction limits, idempotency, retries, and logging. A direct SDK call may be reasonable for a small read-only prototype, but production writes benefit from a stable boundary that is independent of the prompt and model.
Is MCP a replacement for OpenAPI?
No. OpenAPI describes HTTP APIs, while MCP defines how an AI client can discover and use tools, resources, and prompts from a server. An MCP tool can call an OpenAPI-described service underneath. Both require thoughtful business contracts, authorization, lifecycle management, and testing.
When is RPA appropriate in an agent integration?
Use it when a necessary legacy operation has no supported API and the UI path is stable enough to automate. Keep the agent’s role separate from the robot’s deterministic procedure, constrain credentials, verify the resulting record, and monitor UI changes. Prefer an API when one is available and supported.
How do you prevent duplicate actions after retries?
Use a business-level idempotency key, persist the requested operation and outcome, and check the system of record before repeating an unknown transaction. Vendor request IDs help diagnosis but do not always provide business idempotency. Also design event consumers to deduplicate because at-least-once delivery can legitimately repeat a message.
Map one integration end to end
Book a System Audit to inventory one workflow’s systems, identities, records, actions, approval tiers, and recovery paths. The internal request handling use case shows how a bounded intake-to-resolution flow can connect knowledge, routing, approvals, and existing tools without replacing the systems of record.
Sources
Reviewed against current OpenAPI, OAuth, MCP, and CloudEvents specifications plus current first-party Salesforce, Microsoft Dataverse, SAP, and Zendesk API documentation.
OpenOperative Editorial Team
Technical Editorial Team