> ## 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. # CRM integration > How the M9TZ Agent Blueprint treats CRM data as its own bounded domain — and how department agents access only the slice of customer data they are authorised for. Customer relationship data — contacts, deal history, support cases, communication logs — is one of the most sensitive and cross-cutting data types in any business. Every department touches it in some form, but no department should have unrestricted access to all of it. The approach described on this page explains how the M9TZ Agent Blueprint handles CRM data as a bounded, access-controlled domain. ## CRM as a separate data domain In a department-based agent architecture, each department agent operates within its own authority domain. CRM data does not belong to any single department — it is shared infrastructure that multiple agents may need to read from or write to, each within their own scope. The blueprint models CRM as its own tenant within the system: a self-contained data domain with a defined interface through which all agent access is channelled. No department agent reads from or writes to CRM storage directly. All access goes through the CRM interface, which enforces what each calling agent is authorised to see and do. ``` ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ Department A │ │ Department B │ │ Department C │ │ agent │ │ agent │ │ agent │ └────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘ │ authorised │ authorised │ authorised │ scope only │ scope only │ scope only ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ CRM interface │ │ (access control + stable operation set) │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────┐ │ CRM adapter │ ← swappable └──────────────────┘ │ ▼ Your CRM system (existing platform or in-house) ``` ## Access control at the interface The CRM interface is the single point where access decisions are made. When a department agent calls an interface operation, the interface checks the calling agent's authorised scope before returning any data or allowing any write. A few examples of how scopes differ across departments: * A sales-function agent may be authorised to read and update deal stage and contact communication history, but not to see support case history. * A support-function agent may be authorised to read contact details and open cases for its assigned queue, but not to read deal values or pipeline data. * A billing-function agent may be authorised to read account status and invoicing contacts, but not to modify contact ownership or deal records. The scopes are defined during the design phase as part of each department agent's role definition. They are not negotiated at runtime — they are fixed declarations that the interface enforces. ## The adapter pattern for CRM Like back-office and ERP integration, CRM follows the same adapter design: a stable interface on one side, and a swappable adapter on the other. The interface defines a generic set of operations that cover the CRM needs of department agents. The adapter translates those operations into whatever the underlying system — whether an established CRM platform or a simpler in-house solution — requires. ### Generic operations on the CRM interface The exact operation set is scoped during the design phase, but a representative set includes: | Operation | What it does | | -------------------------- | ------------------------------------------------------------------------------------ | | Look up contact | Returns contact details for a given identifier, within the caller's authorised scope | | Create contact | Adds a new contact record with the fields the caller is authorised to write | | Update contact | Modifies specific fields on an existing contact record | | Look up deal or case | Returns a deal or support case record by identifier | | Update deal or case status | Moves a deal or case through a defined status transition | | Append history entry | Adds a timestamped event or note to a contact or case record | | List assigned records | Returns the records assigned to a given agent, queue, or owner within scope | Each operation follows the same JSON-in, JSON-out contract used across the blueprint. The calling department agent sends a structured request; the interface validates the scope, calls the adapter, and returns a structured response. ## What sits behind the adapter The adapter can be backed by different systems depending on the organisation's existing setup and stage of the build. **During early build and testing**, the adapter is typically backed by a local reference implementation — a simple, controlled data store that responds to every CRM interface operation. This lets agents be developed and tested without depending on access to a live CRM platform. **In production**, the adapter is replaced with one that connects to whatever CRM system the organisation uses — an established external platform, or a well-structured in-house solution. The agent code and the interface contract remain unchanged. Only the adapter changes. This mirrors exactly the staged approach described on the [ERP and legacy systems](/agent-structure/erp-legacy-systems) page: validate the workflow first, connect to the live system when it is needed and the workflow is proven. The blueprint does not prescribe a specific CRM platform and does not describe concrete field schemas for any external product. Which system sits behind the adapter — and how that adapter is built — is custom to your environment and is part of the consulting engagement. See the [Consulting Process](/consulting/engagement-model). ## Clean separation from other business data Keeping CRM as a separate domain — rather than letting department agents access customer data through shared tables or direct queries — provides several practical guarantees: * **Containment** — a change to how CRM data is stored or structured requires updating only the adapter, not every department agent that touches customer data. * **Auditability** — all access to CRM data goes through one interface, which means you have a single place to log, monitor, and review every read and write operation any agent performed on customer records. * **Authorisation clarity** — each agent's access to CRM data is declared explicitly in its role definition, not inferred from shared database permissions. You can read the role definition and know exactly what customer data that agent can see. * **Independent replaceability** — if the CRM system behind the adapter changes, the rest of the agent system is not affected. The adapater is the only component that needs to be updated. ## Relationship to the broader architecture CRM integration is one instance of a general principle in the blueprint: every external data source is accessed through a stable interface with a swappable implementation behind it. Department agents communicate through defined message contracts; they do not share internal state or data stores. This keeps each part of the system independently understandable and independently replaceable — which, as the business grows and its tooling evolves, is what makes the agent architecture maintainable over time. The same adapter approach applied to back-office and inventory data — including the recommended staged build sequence. How integration work is scoped and delivered as part of a consulting engagement.