> ## Documentation Index > Fetch the complete documentation index at: https://docs.m9tz.de/llms.txt > Use this file to discover all available pages before exploring further. # ERP and legacy system integration > How department agents connect to your ERP or other established back-office systems through a stable adapter interface — without coupling your agent to any one product. Department agents in the M9TZ Agent Blueprint need to interact with your core business data — stock levels, orders, financial records, documents — without knowing which specific system holds that data. The adapter pattern described on this page is how that separation is achieved. 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](/consulting/engagement-model) 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. ``` Department agent │ │ calls a generic operation ▼ ┌─────────────────────────┐ │ Back-office interface │ ← stable, does not change │ (abstract contract) │ └─────────────────────────┘ │ │ fulfilled by ▼ ┌─────────────────────────┐ │ Adapter │ ← swappable per target system │ (implementation) │ └─────────────────────────┘ │ │ speaks to ▼ Your ERP or other established system ``` The agent only ever talks to the interface. If the target system changes, the adapter is swapped out. The agent's SOPs and message contracts are unaffected. ## 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: | Operation | What it does | | ------------------- | --------------------------------------------------------------------------------------------- | | Check stock | Returns current availability for a given item or SKU | | Reserve stock | Places a soft hold on a quantity for a pending order | | Release reservation | Cancels a hold that is no longer needed | | Create order | Registers a new order record with the relevant line items | | Update order status | Moves an order through defined status transitions | | Generate document | Produces a structured record — invoice, delivery note, or similar — against an existing order | | Look up record | Retrieves a named record (customer account, product, pricing tier) by identifier | 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: 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. 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. 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. 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. This staged approach is consistent with the broader design principle described in the Introduction: build incrementally, validate at each stage, and avoid investing in live integrations before the workflow that depends on them is proven. ## 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) The agent never sees any of this. From the agent's perspective, it calls an interface operation and receives a structured JSON response. Whether that response came from a local reference store or a live production system is an implementation detail the adapter owns entirely. ## 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 That work is custom to your environment and is delivered as part of the paid consulting engagement. See the [Consulting Process](/consulting/engagement-model) for how integration work is scoped. The same adapter approach applied to customer relationship data — contacts, cases, and history — as a separate, cleanly bounded data domain. How the engagement is structured, including how custom integration work is scoped and delivered.