Integrate an AI agent with an ERP one business action at a time.

Begin with the action the agent must complete

“Connect the agent to the ERP” is not an implementable requirement. Name the outcome: retrieve an invoice and its status, update a permitted set of customer fields, create an order from approved inputs, or apply a defined ticket transition. Identify the record owner, current state, required fields, business validation, approval, and authoritative proof that the effect occurred.

This action brief prevents accidental scope expansion. It also reveals whether an integration is needed at all. If the agent only needs data already available in a governed warehouse or retrieval service, direct ERP access may be unnecessary. If a person must approve the decision but not re-enter it, the integration can place approval before the write instead of automating the judgment.

Use the narrowest complete integration path

A supported API is usually the first choice when it exposes the full operation, preserves the required identity and authorization, and returns enough information to verify the result. Events, approved exports, or an existing integration platform may solve read and synchronization use cases without touching the interface. Existing deterministic automation may already be a dependable asset.

An interface-backed tool becomes relevant when the required action remains available only through the deployed user interface or when the supported integration surface stops before a critical step. The design can also be hybrid: APIs handle the operations they expose, while an interface adapter covers only the missing action. Avoid duplicating stable supported capabilities merely to make the architecture uniform.

Define the action contract before selecting the agent

• Inputs: required types, formats, identifiers, optional values, and the source of each field.
• Preconditions: record status, reference-data checks, duplicate detection, and any period or account restrictions.
• Effects: the exact records, fields, statuses, or related objects the action may change.
• Authorization: the requesting identity, application identity, permitted operation, value limits, and approval conditions.
• Failures: invalid input, conflict, policy denial, authentication failure, unavailable system, unrecognized interface state, and uncertain completion.
• Evidence: returned identifier, read-back, status transition, authoritative report, or another check tied to the business result.

Keep planning and execution responsibilities separate

The agent can interpret the request, gather context, and decide whether to propose the action. The integration should independently validate the request against its schema and policy before it changes the ERP. Prompt instructions are useful context, but they are not an authorization boundary.

This separation also improves portability. A workflow-specific tool can be called by different agent systems without giving each one knowledge of ERP screens or credentials. The tool contract remains stable while the implementation behind it can be maintained for the supported environment.

Test business correctness, not just connectivity

A connection test proves very little. Build cases around representative records and failure modes: valid creation, missing reference data, stale status, duplicate request, permission denial, approval rejection, partial response, application interruption, and a changed interface assumption. Include reconciliation for requests whose outcome cannot be determined safely.

For writes, compare the resulting source-system state with the contract. A new identifier alone may be insufficient if totals, line items, ownership, dates, or statuses can still be wrong. Record the application version, role, configuration, and data conditions under which the tests passed.

Plan operations before volume

Assign an owner for the tool, its application dependency, policy, exception queue, and change approvals. Decide how access is revoked, how sensitive logs are handled, how failed requests are reconciled, and which alerts stop execution. Capacity and concurrency should be tested against the actual environment rather than inferred from one successful run.

Expand only after the first action has clear evidence and manageable exceptions. A second action may share infrastructure, but it introduces its own states, permissions, risks, and verification requirements. Treat each workflow as a separate operational capability.

A concise buyer checklist

• Can a supported API or approved existing integration perform the complete action?
• Is the write scope narrower than the application role being granted?
• Which business conditions require a person’s approval?
• What prevents a duplicate or replayed request from creating a second effect?
• What source-system fact proves that the result is correct?
• Which changes force the action to stop and be retested?
• Who owns exceptions, access reviews, and application-version changes?

Frequently asked questions

Should an ERP agent integration start read-only?

Often that is a useful way to validate identity, data interpretation, and observability, but it does not prove a write workflow. A write action needs its own controls, error model, approval design, and effect verification.

Is an available API always the right choice?

A complete supported API is normally preferred. The team must still confirm that it exposes the required action, authorization model, business semantics, and evidence in the deployed environment.

How should duplicate requests be handled?

The action should use an idempotency key, source reference, precondition check, or another workflow-appropriate mechanism. Blind retry is unsafe when the previous outcome is uncertain.

Can one integration cover the entire ERP?

That framing is too broad for a governed rollout. Each operation has different inputs, permissions, effects, exceptions, and evidence. Build and approve capabilities at the workflow level.

What is the first artifact a buyer should prepare?

A workflow brief naming the desired effect, application environment, supported alternatives, roles, approvals, exception paths, and authoritative evidence of success.