AI Agent Integration: Connect One Read-Only Workflow

AI agent integration connects an agent to software and data it can use to complete a task: reading an order, finding an account, preparing a support case, or requesting an approved change. The connection might use an existing product feature, a connector, an API, or a Model Context Protocol server.

For a first implementation, I recommend one read-only workflow with a result you can verify. Prove that it returns the right information to the right person before letting it change orders or send messages.

Read-only is a limit on actions, not a guarantee of appropriate access. An agent that never changes a record can still disclose another customer’s order. The small demonstration below makes that distinction inspectable.

Start with one order lookup, not access to the whole ERP

Suppose a distributor wants an agent to answer: “How much of order SO4107 has shipped?”

For this example, the business has already verified that the requester belongs to customer C17. The integration receives that identity from its trusted application context—not from the customer’s message or an account number chosen by the model.

The permitted tool is get_order_status. Its input contains only the order reference:

{ "order_id": "SO4107" }

Our local demonstration returned:

{
  "ok": true,
  "orderId": "SO4107",
  "orderedCases": 24,
  "shippedCases": 18,
  "remainingCases": 6,
  "remainingShipDate": null,
  "observedAt": "2026-10-29T16:00:00Z"
}

The timestamp and records are synthetic, frozen inputs. This is an executed, in-memory tool handler—not a connection to a distributor’s ERP, a login implementation, or a test of an AI model.

A suitable illustrative answer is: “The record shows 18 of 24 cases shipped, with 6 remaining. No shipment date is recorded for the remaining cases.” It should not turn a blank date into “the rest ships tomorrow.” Nor should it claim delivery to the customer merely because the order record says shipped.

The handler returns a small, approved set of fields. The mock source also contains an internal margin value and operational notes, but neither appears in the result. Passing the entire ERP record to the model and asking it to hide sensitive fields would place that protection later than necessary.

This is how a business question becomes an integration specification: one verified requester, one source record, one permitted lookup, and an observable output.

Change the request and inspect what leaves the system

The mock store contains a second order, SO5108, belonging to customer C22. Keeping the connection read-only does not answer whether C17 may read it.

We ran the same handler against changed inputs:

The local run passed 19 assertions, including field filtering, missing verification, these changed inputs, and confirmation that the source records remained unchanged. We also supplied a separately trusted C22 context and confirmed it could retrieve its own order. The rule is authorized access, not a permanent ban on SO5108.

That is deliberately limited evidence. We wrote the inputs and handler; no model selected a tool or generated the response. We did not test production authentication, a real ERP, resistance to prompt injection, or a complete security design. The result demonstrates the behavior of this small access boundary.

The underlying risk is not peculiar to AI. OWASP’s object-level authorization guidance explains why an API receiving a record ID must check whether the user may perform the requested operation on that record. Permission to call an endpoint does not establish permission to every object behind it.

Our single-customer equality check illustrates one simple policy. Real businesses may have parent accounts, branches, delegated buyers, employee roles, and field-level restrictions. Those require the actual authorization model, not a copy of this mock.

Connect the complete path from request to answer

The useful project is not “give the agent ERP access.” It is “answer this recurring question using permitted, current records, with a fallback when that cannot be done.”

Find the authoritative source for the answer

For SO4107, establish where ordered quantity, shipment quantity, and the remaining shipment date actually live. They may not be in the same system. An order-management record may say fulfilled while a separate carrier feed describes physical movement.

Ask which source supports the exact promise you want to make. If the request is about delivery, the shipment-quantity result above is insufficient. Either connect the needed evidence or narrow the answer. Our customer service automation guide explains how these state differences change the appropriate customer response.

Also distinguish source update time from retrieval time. Fetching an old record now does not make its contents current. The demonstration’s frozen timestamp makes no claim about production freshness.

Keep identity and permitted scope outside model-selected arguments

The application should establish the requester and the access policy before releasing customer-specific data. For the demonstration, that verified context is an assumed input; implementing and testing the real sign-in or staff-verification process is separate work.

A service account might technically read thousands of orders. That does not mean every person chatting with the agent may read those orders. Prefer source-native access restrictions where they support the required policy, and enforce the remaining business boundary before data enters model context.

An internal support employee may legitimately need broader access than a customer. Specify that separate role and its tests. Do not widen the customer-facing tool simply because an employee demonstration needs both accounts.

Give the agent a narrow operation with a useful result

Define what the tool accepts, what it may return, and which failures remain distinguishable to the application. In our example, an order reference is required; an arbitrary database query, URL, account override, or requested field list is not accepted.

Anthropic’s client-tool documentation makes the execution split clear: the model requests a structured tool call, application code runs it, and the result returns to the conversation. That description applies to custom client-executed tools; hosted tools can have a different execution arrangement.

Use that application boundary to validate inputs and authorization. A well-formed call is still a request to perform an operation, not evidence that the caller is entitled to its result.

Bound execution and preserve a real fallback

Set limits on the number of tool calls, elapsed time, and repeated failed lookups. Otherwise, a simple status question can become an extended search through unrelated records. Handle unavailable credentials or source systems explicitly rather than supplying remembered customer data as though it were a fresh lookup.

The end state should be one supported answer or a clear handoff. A message saying “we opened a case” belongs in the response only after that case actually exists. If the first release has no case-creation tool, direct the request to the existing support path without inventing an automated action.

The human-review guide covers the receiving queue. Here, retain the original question, verified account reference, lookup outcome, and unresolved need so an employee does not start over.

Choose the connection after defining the operation

A connector name tells you which systems can communicate. It does not, by itself, tell you which records and actions the resulting workflow permits.

Use an existing native capability when it meets the requirement. If your customer portal already shows the correct order information under the correct account permissions, improving that experience may be enough. Do not rebuild authentication and order lookup just to introduce a conversational interface.

Use a supported connector or direct API for an actual gap. Check the exact operation, fields, permissions, and failure behavior. A connector with “ERP integration” on its product page may support a different object or action than this workflow needs. Confirm in a safe environment rather than infer suitability from the logo.

Use MCP when the chosen agent application supports it and its tool interface fits the deployment. The MCP architecture documentation describes a client-server protocol through which servers expose tools and context. It is not a replacement for deciding which customer may access SO4107. The same business access checks remain necessary whether the request arrives through MCP or a direct API.

Use an agent only when selecting the next step adds value. A fixed form that accepts an order reference and returns an authorized status might be simpler than an agent. Natural-language inquiry handling can justify interpretation, but merely fetching a known record does not require an autonomous planner. The agent-versus-chatbot comparison addresses that architecture choice.

This is native first, integration second, custom code last applied to a concrete operation. Our small custom handler explains a boundary; it is not evidence that you should replace a working native permission system with custom code.

Move from a useful mock to evidence from your actual stack

The mock reveals what an implementer should demonstrate next. It does not remove the need to demonstrate it.

First, verify real identities and permissions using representative customer and staff roles. Test more than the happy path: a changed order ID, a removed permission, an unverified requester, and fields that should never be returned. Our code did not implement a real identity provider or all the access relationships your business may need.

Next, test the actual source connection. Does it preserve the necessary fields and meaning? What happens to partial shipments, revised orders, canceled lines, stale records, or a missing source? The mock’s six remaining cases do not prove how your ERP represents those states.

Then evaluate the model separately. Give it authorized results with missing dates and partial quantities. Does the response stay within those facts? Does it ask for permitted verification when needed, or claim an action that never happened? Passing handler tests cannot establish model behavior because no model participated in them.

Finally, exercise the operational fallback and any proposed writes in a non-production environment. A future cancellation or refund operation needs its own authority, confirmation, and recovery tests. Correct read access is not permission to add those actions.

Use the pilot-to-production roadmap for release planning. The next investment should follow the unresolved evidence: identity, source data, model interpretation, or workflow completion—not automatically a more powerful model.

Submit one system connection for review

Describe the recurring request, the software holding the answer, who should be allowed to see it, and what result would count as complete. KelenAI’s workflow automation services connect those operating requirements to an implementation around existing systems.

Start with our free workflow consultation request. We review the submitted context and follow up if a focused conversation would help. Please do not include API keys, credentials, confidential records, or customer personal data in the initial submission.