Anika is the integration architect at a regional home care agency that coordinates services for roughly 900 older adults across three counties. She has integrated with eight different technology platforms in the past five years, and she has learned that the way a platform describes its integration surface in documentation and the way it actually behaves in production are rarely the same thing. What she wanted from BlueMirror’s technical documentation was not an architecture diagram. She wanted to know where her system connects, what it looks like from her side of the boundary, and what she needed to build.
Every external system that integrates with BlueMirror connects at the Blue Pane membrane through a registered agent. The agent is the integration unit. Not a user account, not an API credential, not a service token: an agent with a declared identity, a declared set of capabilities, and a declared set of limitations. The agent registration process produces a manifest, and the manifest is the contract between the partner’s system and the membrane.
The agent registration manifest
The manifest declares four things. First, identity: who the agent is, who operates it, and how its credentials can be cryptographically verified. Second, capabilities: what domains the agent operates in, what actions it can perform, and critically, what it cannot do. A pharmacy agent that includes “cannot_prescribe” and “cannot_diagnose” in its capabilities declaration is stating both what it offers and what it explicitly does not claim. Third, context requirements: which fields the agent needs to fulfill its function, which fields it might optionally request if available, and which fields it will never request. A transportation agent that declares it will never request medication data has committed to that limitation in a logged manifest that the membrane enforces. Fourth, integration details: whether the agent is MCP-compatible, its certification status, and the protocol version it communicates in.
The manifest is not a one-time registration artifact. It is a living contract. Changes to the agent’s capabilities or context requirements require manifest updates, and manifest updates trigger a re-evaluation of the agent’s trust tier. An agent that adds a new capability mid-relationship is not automatically trusted to exercise it. The evidence package requirement applies to expanded capabilities as it applies to initial trust earning.
Five partner types and their entry points
Healthcare systems, including EHR platforms, scheduling modules, and care coordination tools, connect at TIER_2B minimum with a valid health system credential chain. The context requirements for scheduling interactions include relevant scheduling constraints and accessibility needs. FHIR R4 compatibility is expected, because BlueMirror’s health context is structured for FHIR exchange and the integration surface reflects that. HIPAA compliance is mandatory for any interaction involving health data, and the agent manifest must include a Business Associate Agreement reference. The most common initial use case for EHR integration is appointment scheduling through the health concierge agent: the external scheduling system and BlueMirror’s agent negotiate appointment times through a sandbox, and the outcome flows into both systems’ records. Epic’s scheduling module, Cerner’s patient scheduling API, and similar systems enter through this pathway.
Pharmacy systems connect at TIER_2B with pharmacy credentials and advance to TIER_4D with demonstrated reliability across a sufficient interaction history. The context requirements for prescription refill interactions are tightly scoped: medication name and dosage, delivery preference, and the person’s generic preference if declared. The buying agent handles the commercial side of pharmacy interactions; the medication advisor handles clinical cross-reference. The pharmacy agent interacts with both, through separate sandboxes with separate context permissions. A pharmacy system that wants to present cost-saving alternatives works through the buying agent’s sandbox, which has price and delivery context but not clinical context. A pharmacist reviewing a medication list for interactions works through the medication advisor’s sandbox, which has clinical context but not financial context. The separation is intentional.
Insurance and benefits platforms connect at TIER_2B with tight default exploration bounds. Context permissions for insurance interactions are deliberately minimal: current plan identifier and any coverage concerns the person has explicitly chosen to surface. Commitment authority is zero: the insurance agent cannot transact through the membrane without the person’s direct participation. A legitimate insurance agent that wants to serve Margaret’s actual needs can do so. It simply requires Margaret’s active involvement in the decision.
Transportation services connect at TIER_3C with accessibility and location context. Requirements are: pickup location, destination, and any accessibility requirements that affect vehicle selection or driver briefing. Health context does not transfer to transportation agents. The transportation agent does not need to know why Margaret needs an accessibility accommodation. It needs to know that she does. Uber Health, Lyft Healthcare, and medical transportation providers enter through this pathway.
Care coordination platforms, including home care agency management systems, care plan software, and caregiver scheduling tools, connect at TIER_3C with a path to TIER_4D through demonstrated care coordination reliability. Context requirements depend on the coordination scope: a home care scheduling system needs the care plan elements that affect aide dispatch timing and task assignment. It does not need the full medical record. The care coordination context is the subset of the MoC hierarchy that is relevant to the coordination function the agent is performing, and the Context Gate Controller determines what that subset is based on the interaction type, not on what the agent would like to have.
MCP compatibility
Partners that already support the Model Context Protocol have a simplified integration path. BlueMirror acts as an MCP provider for all five partner categories. An external agent that already communicates in MCP format sends its manifest through the MCP registration endpoint, receives an initial trust tier assignment, and can begin interacting immediately through the standard MCP message format. The membrane handles trust scoring, context gating, and sandbox management transparently from the external agent’s perspective.
Partners that do not support MCP integrate through BlueMirror’s adapter layer. The adapter translates between the partner’s existing API format and BP-ACP, the Blue Pane Agent Communication Protocol. The adapter handles protocol translation, context packaging, and the trust scoring handshake. From the partner’s side, the integration looks like adding a new API endpoint. The BlueMirror side handles the complexity of mapping the partner’s request format to the context gate’s evaluation logic.
MCP compatibility is not required, but it reduces integration time substantially. The partner that builds MCP-native eliminates the adapter layer and gains direct access to the full protocol specification rather than a translation layer that may introduce edge cases.
The integration timeline
Eight weeks from manifest registration to production access, and the timeline is aggressive by design.
Weeks one and two: register the agent manifest, receive the initial trust tier assignment, and review the context requirements mapping. The membrane evaluates the manifest and returns a context requirements assessment: here are the fields you declared as required, here is what the Context Gate Controller will permit at your initial trust tier, and here is where the gap exists if your declared requirements exceed what the current tier permits. This is the document that matters most to Anika’s engineering team. It tells them what their system will actually receive in production, not what they hoped to receive based on the capabilities description.
Weeks three and four: build the BP-ACP endpoint or configure the MCP adapter, then connect to the sandbox test environment. The test environment mirrors the production membrane behavior exactly, including trust scoring, context gating, and timeout enforcement. What works in the test environment works in production. What fails in the test environment reveals a real gap that needs to be addressed.
Weeks five and six: run integration tests. Validate context gate behavior against the specific interaction types the partner’s system will use. Confirm exploration bounds behave as expected across the declared trust tier. Test the sandbox lifecycle, including agreement, timeout, and violation paths.
Weeks seven and eight: certification review. BlueMirror’s partner integration team reviews the test results, the manifest, and the interaction logs from the test environment. Production access is granted. A monitoring period begins, during which interaction patterns are reviewed for alignment with the declared manifest. Discrepancies between declared and observed behavior trigger a re-evaluation.
What is fixed and what is flexible
Three aspects of the integration are not negotiable. The membrane model is fixed: every integration goes through Blue Pane. There is no direct API access to the person’s data, to the concierge agents, or to the Memory of Context hierarchy. The trust tier system is fixed: the tier definitions, evidence package requirements, and violation thresholds are not customized per partner. The audit trail requirement is fixed: every interaction is logged, and the log is cryptographically signed and preserved. Partners that find these constraints incompatible with their architecture have found the right information early.
Three areas are flexible. Context requirements for the specific domain and interaction types the partner operates in, because different care coordination models legitimately need different subsets of context. Commitment authority thresholds for the partner’s interaction type, within the bounds of the tier system’s defaults. Timeout values for the partner’s negotiation patterns, because a home care scheduling interaction has different natural timing than a pharmacy refill. The specific fields in the agent manifest, because the manifest structure accommodates domain-specific declarations that BlueMirror’s partner integration team helps specify.
Anika registered her agency’s manifest the following Tuesday. The context requirements assessment came back the same day. She had requested three fields that the home care trust tier did not permit at initial entry. The assessment told her which fields, which tier would permit them, and how long the evidence package process typically took for care coordination platforms that had achieved TIER_4D. She forwarded the assessment to her engineering lead. It was the first time a platform’s integration documentation had told her exactly what she would not have access to before she found out in production.
Cross-References#
The Membrane (BMT-03.01). The membrane model the partner integrates with.
Trust Tiers and What They Unlock (BMT-03.02). How the partner agent earns trust across the tier system.
Bounded Exploration (BMT-03.03). The exploration bounds the partner’s agent operates within during interactions.
The SDK and the Marketplace (BMT-12.05). The platform-stage partner ecosystem that builds on the integration surface.
Technical Appendix BMT-03.05-A is available to partners and investors at partners.bluemirror.tech.