BMT-03.05 Executive Summary#
BlueMirror.tech | May 2026#
Anika is the integration architect at a regional home care agency coordinating services for roughly 900 older adults across three counties. She has integrated with eight different technology platforms in the past five years and 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. 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 registration process produces a manifest, and the manifest is the contract between the partner’s system and the membrane.
The manifest declares four things. Identity: who the agent is, who operates it, and how its credentials can be cryptographically verified. Capabilities: what domains the agent operates in, what actions it can perform, and explicitly what it cannot do. A pharmacy agent that includes “cannot_prescribe” and “cannot_diagnose” in its capabilities declaration has committed those limits in a logged manifest that the membrane enforces. Context requirements: which fields the agent needs, which it might optionally request, and which it will never request. Integration details: MCP compatibility, certification status, and protocol version.
The manifest is not a one-time registration artifact. Changes to capabilities or context requirements trigger 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.
Five partner types have defined entry points. Healthcare systems connect at TIER_2B minimum with a valid health system credential chain. FHIR R4 compatibility is expected; HIPAA compliance is mandatory for any interaction involving health data. The most common initial use case is appointment scheduling: the external scheduling system and BlueMirror’s health concierge agent negotiate through a sandbox, and the outcome flows into both systems’ records. Pharmacy systems connect at TIER_2B and advance to TIER_4D with demonstrated reliability. The buying agent handles commercial pharmacy interactions in one sandbox with price and delivery context; the medication advisor handles clinical cross-reference in a separate sandbox with clinical context. The separation between commercial and clinical contexts is intentional and enforced. Insurance and benefits platforms connect at TIER_2B with tight default exploration bounds and zero commitment authority: the insurance agent cannot transact through the membrane without the person’s direct participation. Transportation services connect at TIER_3C with accessibility and location context, without health context about the reason for the accommodation. Care coordination platforms connect at TIER_3C with a path to TIER_4D, receiving the care plan elements relevant to dispatch timing and task assignment, not the full medical record.
Partners that support the Model Context Protocol have a simplified integration path: BlueMirror acts as an MCP provider, and the manifest registers through the MCP endpoint. Partners that do not support MCP integrate through an adapter layer that handles protocol translation transparently. MCP compatibility is not required, but it reduces integration time substantially.
The integration timeline is eight weeks from manifest registration to production access. Weeks one and two produce the context requirements assessment: what the Context Gate Controller will actually permit at the initial trust tier, and where the gap exists if declared requirements exceed what the tier permits. This document is the most important output of the first two weeks. It tells the partner what their system will actually receive in production, not what they hoped for based on the capabilities description. Weeks three and four involve building the endpoint and connecting to the sandbox test environment, which mirrors production membrane behavior exactly. Weeks five and six run integration tests against the specific interaction types the partner’s system will use. Weeks seven and eight are certification review and production access grant.
Three aspects of the integration are not negotiable: the membrane model (every integration goes through Blue Pane, there is no direct API access to the person’s data), the trust tier system (tier definitions, evidence package requirements, and violation thresholds are not customized per partner), and the audit trail requirement (every interaction is logged, cryptographically signed, and preserved). Three areas are flexible: context requirements for the specific domain and interaction types, commitment authority thresholds within the tier system’s defaults, and timeout values for the partner’s negotiation patterns.
Anika registered her agency’s manifest the following Tuesday. The context requirements assessment came back the same day. Three fields she had requested were not permitted at the home care trust tier at initial entry. The assessment named the fields, named the tier that would permit them, and described the typical timeline for care coordination platforms reaching 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.
The full article, including the API contract specifications, test harness documentation, and certification requirements, is at BlueMirror.tech.