How Systems Integrators Can Add AI Agent Delivery

Systems integrators already know that a successful API response is only one part of a reliable business process. Records can be duplicated, messages can arrive late and legacy applications can acknowledge work before completing it. Adding an AI agent increases the need to preserve those distinctions because a fluent explanation can otherwise hide an incomplete transaction.

This guide is for integration architects, delivery directors and managed-service leads adding agent delivery to an existing systems-integration practice. The opportunity is to connect language-based assistance to controlled business capabilities while keeping transaction integrity, identity and recovery in explicit engineering components. The agent should use a reliable integration layer; it should not become an improvised replacement for it.

Offer bounded business capabilities, not raw system access

Start with the business operation the agent needs, such as retrieving an approved case, preparing a customer-profile change or submitting a reviewed service request. Expose a narrow operation with validated inputs and a meaningful result. Avoid giving the model a generic database write tool or unrestricted access to every function an application account can perform.

A useful tool contract specifies the operation name, input schema, business preconditions, caller identity, approval requirements, side effects, outcome states and error categories. It should distinguish “accepted for processing” from “completed”, and “rejected” from “outcome unknown”. These states determine what the agent may tell the user and whether another action is safe.

Keep business rules close to the systems that own them. The agent may select a permitted operation and prepare parameters, while the integration service validates identity, authority and current state. The agent architecture guide explains the wider components; the integrator’s responsibility is to make each boundary enforceable and testable.

Give each layer a clear owner

Responsibility boundaries in an integrated agent service

Layer	Primary responsibility	Evidence expected
Agent interaction	Interpret the request and present supported outcomes	Task evaluation and refusal or handoff cases
Capability gateway	Validate identity, scope, inputs and approval	Contract and denied-operation tests
Workflow state	Track progress, waiting, cancellation and recovery	State-transition and restart tests
System adapters	Translate to supported application interfaces	Integration and compatibility evidence
Systems of record	Own authoritative business state	Confirmed outcomes and reconciliation
Operations	Observe, respond and maintain the service	Runbooks, alerts and handover exercise

The same supplier may own several layers, but the responsibilities should remain explicit. A model provider does not own your ERP adapter. An integration team does not automatically own the client’s approval policy. Record these boundaries in the delivery and support agreement.

Design for uncertain outcomes before adding retries

A request can succeed in the target system while its response is lost. Retrying blindly may duplicate the business action. Use a stable operation identifier and an outcome lookup where the target supports them, and design a controlled reconciliation route where it does not.

Microsoft’s idempotent consumer guidance explains handling repeated messages so their effect is not repeated. Apply the principle at the actual business boundary: deduplicating an agent message does not automatically protect a downstream application that receives a second write.

The contract should state which errors are retryable, which require corrected input and which need human investigation. Put limits on retries and preserve the same logical operation identity. Avoid several layers independently repeating the same action without a coordinated policy.

Version checks are separate from duplicate checks. A new legitimate request may target a record that changed after approval. Revalidate the approved parameters and current record version before execution. An operation can be unique and still be stale.

Treat legacy batch processing as a first-class state

A legacy system may accept a file or queue entry and report the result later. Represent that delay explicitly. The agent can report submission and provide the tracking reference, but it should not claim that the business record exists until confirmation arrives.

Microsoft’s asynchronous request-reply pattern is a useful reference for separating request acceptance from later completion. The implementation must match the actual application interface, including authentication, status retrieval and failure handling; adopting a pattern name does not make the legacy system support it.

Agree who owns the batch, error file and reconciliation. If an overnight import rejects a record, the agent needs an actionable state and a responsible queue. A technical team discovering the error several days later is not an adequate customer-facing completion model.

Where only a manual step is available, document it as such. The agent can prepare the required package and track acknowledgement. Do not describe the whole process as automated when a person still performs a material transaction without integration evidence.

Worked integration: a customer setup spans two systems

Illustrative design scenario: an authorised workflow creates a customer profile in a CRM and submits a corresponding setup request to a legacy ERP batch. The CRM succeeds. The ERP later rejects the request because a required business field is invalid.

The agent should show partial completion and the specific unresolved dependency. It should not send a final welcome message implying the customer is fully set up. The integration layer records both outcomes under the same workflow reference and routes the correction to the approved owner.

Decide the recovery policy before the test. The business may want to retain the CRM profile in a pending state while correcting the ERP request. Automatically deleting it could erase useful history or conflict with other work. Compensation is a business decision, not a universal technical rollback.

Microsoft’s Saga pattern guidance discusses coordinating local transactions and compensating actions across services. For this project, use that as an architecture reference while defining the actual permitted recovery, irreversible steps and manual resolution. Not every workflow requires a saga implementation.

Now expire the approval before a corrected request is resubmitted. The system should require the applicable renewed approval rather than reuse an old authorisation for changed data. Finally, restart the workflow service and replay the completion event. The CRM profile must not be created again, and the pending ERP result must remain traceable.

Test the interfaces and the agent as different concerns

Contract tests should verify schemas, identity context, permission denials and business preconditions. Integration tests should verify the actual supported interfaces and state mappings. Recovery tests should cover timeouts, duplicate and late events, restarts, partial completion and unavailable dependencies.

Agent evaluations should then test whether language requests produce the correct permitted operation, parameters, explanation and handoff. A strong language score cannot compensate for an adapter that duplicates writes. A reliable adapter cannot compensate for an agent choosing the wrong customer record.

The testing and evaluation guide provides the broader method. Keep evidence of which components were real, simulated or unavailable in each test. Acceptance should expose remaining integration uncertainty rather than hide it behind a polished demonstration.

For Arabic-English projects, include exact identifiers, mixed-language requests and ambiguous business terms in the evaluation. Validate that translation does not change an operation’s scope or approval requirement. Subject-matter review should focus on the consequential parameter, not only on whether the explanation reads naturally.

Keep identity and approval attached to the action

Carry the authenticated user and business context through the capability gateway. A powerful shared service account should not erase the distinction between what different users may request. Authorise the actual operation at execution time using the approved identity model.

An approval should refer to the specific action, material parameters, target record and relevant validity conditions. If those change, apply the agreed reapproval rule. A generic “yes” in a long conversation is weak evidence when the system cannot establish what was approved.

The security architecture guide develops access and tool controls. Integrators should also define how credentials rotate, how supplier access is removed and how logs avoid exposing unnecessary sensitive values while retaining useful transaction references.

Make the production handover prove recoverability

The acceptance artifact is a transaction-and-recovery dossier. It includes capability contracts, state transitions, source-of-truth mappings, deployment configuration, test evidence, known limitations and the operational runbook. It should identify the owner of every unresolved state and the supported way to reconcile it.

Run a handover exercise with the people who will support production. Ask them to find a failed workflow, determine whether a side effect occurred, recover it through the approved route and explain the resulting customer status. If they must ask the original developer to interpret hidden state, the handover is incomplete.

The monitoring guide covers service signals. Add integration-specific measures such as unknown outcomes, stuck pending states, duplicate suppression, approval expiry and reconciliation backlog. A healthy model endpoint does not prove a healthy business process.

Agree support boundaries with application owners. A vendor API change, a legacy batch failure and a model behaviour regression need different responders, while the service owner needs one coherent incident view. Document escalation and communication so suppliers do not pass the unresolved workflow between teams.

Add agent delivery without abandoning integration discipline

Package the offer around a bounded business capability and the evidence needed to operate it. Price discovery, adapter work, evaluation and handover explicitly. The consultancy practice guide addresses offer economics and reusable delivery methods.

Open for AI’s AI agent development service can be discussed alongside an integrator’s existing systems responsibilities. To scope an agent delivery contribution to your integration project, bring one business transaction, its interface contracts, a partial-failure example and the proposed support map. Agree ownership of the agent layer, adapters, acceptance and production recovery before committing the combined service.