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.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 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:
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 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.
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.ERP & legacy systems
The same adapter approach applied to back-office and inventory data — including the recommended staged build sequence.
Consulting Process
How integration work is scoped and delivered as part of a consulting engagement.