This page is an overview of the integration approach. Detailed pages for the two integration categories that already have dedicated documentation — back-office and ERP systems, and CRM data — are linked at the end of this page. Connecting the blueprint to your specific systems is part of a paid consulting engagement. See the Consulting Process for how that work is scoped.
The adapter pattern
Every integration in the blueprint follows the same structure: a stable interface on the agent side, and a swappable adapter on the system side.Integration categories
The blueprint groups external systems into categories, each with its own interface contract. The categories relevant to most department agent deployments are:Back-office and ERP systems
Systems that hold stock levels, order records, financial data, and other operational back-office information. The interface provides a generic set of operations — check stock, create order, update status, generate document — that agents call without knowing which specific system sits behind the adapter.
CRM data
Customer relationship data — contacts, cases, deal history, communication logs — treated as a separate, access-controlled domain. Each department agent is granted an authorised scope that determines which CRM records it can read and write. All access goes through the CRM interface; no agent reaches CRM storage directly.
Inbound channels
The input sources an agent monitors — a shared inbox, a form endpoint, an event stream, or a scheduled trigger. These are configured as part of each agent’s input sources and are not separate adapters, but they follow the same principle: the agent sees a normalised input event regardless of which channel it came from.
Outbound messaging
The channels through which the agent delivers its outputs — outbound email from a connected mail account, messages posted to an internal channel, or notifications sent to a responsible team. Like inbound channels, these are configured per agent as outbound interfaces.
Scheduling systems
A connected scheduling tool used by agents that need to offer, create, or cancel appointments. The agent calls the scheduling interface to check availability and register a booking; the adapter handles the communication with whatever calendar or scheduling platform your organisation uses.
Custom systems
Any system with a structured API that does not fit the categories above. Custom interface contracts are designed during the consulting engagement and follow the same adapter pattern as all other integration categories.
Connecting a system
Connecting a system to the blueprint means two things: defining the interface contract for that category (if one does not already exist), and building an adapter that satisfies that contract for your specific system. The credentials, authentication method, and permissions required depend entirely on what your organisation grants for access to that system. Connecting a system requires the access your organisation controls — whether that is an API credential, a service account, a connection string, or any other form of authorised access your system uses. The blueprint does not prescribe a specific authentication flow, and no credentials are shared with third parties beyond what the target system itself requires. The adapter handles all authentication and session management internally. The agent never sees credentials — it only ever calls interface operations and receives structured responses.The staged build approach
The blueprint follows an evolutionary principle for integration: build and validate the agent workflow first, connect to the live system only when the workflow is proven and the integration is needed. During early build and testing, adapters are backed by a local reference implementation — a controlled data store that responds to every interface operation. This lets the full agent workflow be developed and tested end-to-end without depending on access to live systems. When the workflow is validated and the organisation is ready, the reference implementation is replaced with a production adapter for the actual target system. The agent code does not change. This approach is described in detail on the ERP & Legacy Systems page, which documents the staged sequence for back-office integration. The same sequence applies to any integration category.What is covered in the dedicated pages
ERP & Legacy Systems
The adapter pattern applied to back-office and inventory data — including the interface operation set, the staged build sequence, and what the adapter handles on behalf of the agent.
CRM Integration
How CRM data is modelled as a bounded domain, how access control is enforced at the interface level, and what the generic CRM operation set covers.