A regional retailer’s people knew how to move between its systems, and its AI did not. EIC defined business-level tools over 9 priority systems and knowledge services, so AI can work where the work happens while people keep the decisions.
Privately held specialty retailer operating physical stores, owned eCommerce, an external marketplace, and a central fulfillment operation, with 126 regular employees. Organization Strategy, AI-Native Process Reengineering, and Knowledge Engineering had established what work should happen, what context it required, and where human authority remained.
Part 4 of 5 at the same retailer: the connectivity layer that production AI was later built on. Read part 5: production AI →
The company’s applications were individually capable but not consistently usable by AI. Employees could use AI to analyze or prepare work, but they still acted as the integration layer, opening systems, retrieving records, reconciling context, and executing the actual transaction or update.
Native endpoints exposed system objects, not always the business interaction an AI-native process actually required
Some systems had first-party operational MCP services, while others had only APIs, documentation MCPs, or no MCP interface at all
Retrieval, preparation, routine updates, consequential changes, and human approvals required different control levels
Each new use case risked repeating system discovery, authentication design, integration engineering, and testing.
Low-level APIs could require excessive calls, large payloads, and repeated AI transformation of technical data.
Applications that remained operationally effective could appear obsolete simply because their AI interface was poor.
Instead of asking “What endpoints does this application have?”, EIC started with “What does the process need AI to know or do at this step?”
Each interaction defined required information, permitted action, system of record, input and output structure, authentication method, human-control requirement, and expected failure behavior.
EIC did not expose every native API method directly to AI.
Where mature first-party MCP existed, EIC used it. Where a vendor exposed only APIs or an MCP that did not cover the operational use case, EIC created process-specific remote MCP tools over the existing API.
Read tools, preparatory tools, approved write tools, and consequential actions were separated so a model could not silently gain broader authority through connector reuse.
AI gained access to the information and bounded actions required to execute the process, while people retained consequential decisions and vendor systems retained their operational control boundaries.
A planner or an automated trigger starts the Replenishment Review Skill.
Recent demand from Shopify, item and purchasing context from NetSuite, warehouse stock from the WMS, supplier and EDI status from SPS Commerce, and guidance from governed RAG.
AI prepares the recommendation and explanation; the buyer retains the inventory-commitment decision.
The same governed tools update the purchasing or replenishment record and submit any approved warehouse task.
| Work area | Execution method | Why |
|---|---|---|
| NetSuite: item and inventory position, supplier and purchase-order context, permitted record updates | First-party NetSuite AI Connector plus custom MCP tools | Custom tools cover process-specific interactions; user-delegated OAuth 2.0 keeps existing NetSuite role permissions. |
| Shopify: recent order and demand context, product and channel state | First-party MCP where it fit; custom MCP over the GraphQL Admin API | Internal merchant and admin interactions needed the Admin API, with scoped access tokens. |
| WMS: available, allocated, inbound and location-level inventory; approved warehouse tasks | NetSuite-native connectivity plus custom business-level WMS tools | AI never controlled robot motion or safety logic directly. |
| ShipStation: shipment state and carrier context | Custom operational connector over the V2 API | The public MCP served API documentation only; a server-side API key is held in the approved secret store. |
| Loop Returns: return context, policies, status and approved return actions | First-party Loop Returns MCP | OAuth 2.1 with PKCE carries the user’s existing Loop permissions. |
| Gorgias: tickets, customer history and service configuration | First-party Gorgias MCP plus the REST API | Operational actions outside the production-safe MCP surface use scoped OAuth 2.0 bearer tokens. |
| SPS Commerce: supplier transaction state, missing or late EDI documents | Custom remote MCP connector over the SPS REST interactions | No first-party operational MCP was used; OAuth 2.0 bearer tokens. |
| Governed RAG: authorized corpora, relevant knowledge and source chunks with provenance | EIC-governed MCP connector | Identity-aware corpus and document-level access controls, so access to a collection does not mean access to every item in it. |
Connectivity discovery and design effort for subsequent automation initiatives fell by 50% because system ownership, authentication, interaction models, and reusable tools were already defined.
Replenishment exception context assembly fell from 18 minutes of multi-system preparation to 6 minutes of AI-assisted review, a 67% reduction while the final inventory decision remained human.
The replenishment workflow reduced routine user navigation from four to five separate application views to one AI-assisted review flow before approval.
72% of the interactions required by the next two automation initiatives reused an existing connector, authorization pattern, or business-level interaction.
Business-shaped responses reduced AI processing and context overhead by 25–30% compared with early prototypes that consumed larger raw API responses and reconstructed context inside prompts.
34 reusable business-level interactions replaced hundreds of low-level API operations; 3 first-party MCP services and 5 custom adapters covered 9 priority systems and knowledge services, and no core operational system required replacement solely for AI connectivity.
The retailer did not need a separate NetSuite integration for ChatGPT, another for Microsoft Copilot, and another for a Llama application. Where the client supported MCP, the same approved server and tool definitions could be reused.
The service behind this storyAI Connectivity →
12 competing AI opportunities became one governed portfolio: 5 funded first, 4 deferred, 3 parked, and foundations built once for every later initiative.
Know-how that lived with experienced employees became explicit, validated target processes, so automation teams received approved process logic before design began.
27 sources classified by authority, owner and retrieval method, and 11 governed collections instead of one corpus, before committing to a large retrieval platform.
EIC translates what your processes need AI to know and do into reusable business-level tools over the systems you already run.