This page does not include implementation details for any specific ERP or back-office connector. Designing and building a connector to your actual system is part of a paid consulting engagement. See the Consulting Process section for how that work is scoped and delivered.
The problem: coupling agents to systems
If a department agent calls your ERP system directly — using that system’s proprietary API, query format, or data model — you create a tight coupling between the agent and a specific product. When that product changes, is replaced, or is not yet available in the early stages of a build, the agent breaks or cannot be tested. The adapter pattern solves this by placing a stable, generic interface between the agent and whatever system sits behind it.The adapter pattern
The interface defines a fixed set of operations the agent is allowed to call. The adapter is the component that translates those generic calls into whatever your actual back-office system requires.Generic operations on the interface
The interface covers the operations that department agents typically need from a back-office or ERP-style system. The exact set is defined during the design phase for your specific workflows, but common examples include:
Each operation receives a JSON payload and returns a JSON response. The agent constructs the request, calls the interface, and acts on the response — without knowing whether the adapter behind the interface is talking to an established ERP product, a proprietary internal system, or a local reference store.
Staged approach: start with a reference implementation
The blueprint follows an evolutionary build principle: get a working system into testing as early as possible, and replace placeholder components with production ones only when the workflow is validated and the integration is actually needed. For back-office integration, this means:1
Start with a local reference implementation
During early build and testing, the adapter is backed by a simple internal data store — a structured file or lightweight database that you control. It responds to every interface operation and lets you test the full agent workflow end-to-end without depending on access to your live system.This reference implementation is not a mock or a stub — it is a real, functioning adapter that follows the same interface contract as the production adapter will. Agents under development interact with it exactly as they would with the production system.
2
Validate the workflow
Run the full department workflow — order processing, stock checks, document generation, or whatever the target process is — against the reference implementation. Confirm that the agent’s SOPs, decision branches, escalation paths, and message outputs all behave correctly before any live system is involved.
3
Build the production adapter when needed
Once the workflow is validated and the business is ready to connect to the live system, a production adapter is built for your specific ERP or back-office product. This adapter implements the same interface contract the reference implementation already satisfies.The agent code does not change. Only the adapter changes.
4
Switch adapters
The reference implementation is swapped for the production adapter in the agent’s configuration. The agent continues to call the same interface operations with the same JSON payloads. The adapter handles all translation to and from the target system’s format.
What the adapter handles
The adapter is responsible for everything that is specific to the target system:- Authentication and session management for the target system
- Translating generic interface operations into the target system’s API calls, query formats, or file protocols
- Mapping the target system’s response format back into the standard JSON response the interface defines
- Handling errors and unavailability from the target system, and surfacing them as structured error responses the agent can act on (retry, escalate, or log)
Swapping adapters for different systems
Because the interface is stable and generic, the same agent can work with different back-office systems in different deployments by using a different adapter. Department Agent A in one organisation points its adapter at one system. The same agent design deployed for a different organisation points its adapter at a different system. The agent’s SOPs do not change. This also means that if your organisation replaces its back-office system in future, a new adapter is built for the replacement. The agents that depend on back-office data continue to work without redesign.What this page does not cover
This page describes the architectural pattern only. It does not include:- Connection details, credentials, or API specifications for any specific ERP or back-office product
- Field mapping schemas for any specific system’s data model
- Implementation code for any production adapter
CRM integration
The same adapter approach applied to customer relationship data — contacts, cases, and history — as a separate, cleanly bounded data domain.
Consulting Process
How the engagement is structured, including how custom integration work is scoped and delivered.