Assembly

An Assembly is the moment where all of your context, rules, and infrastructure are synthesized into a single, governed execution plan for a copilot.

Given a role and a location in your environment (a collection, asset, or both), the platform assembles:

  • the character the model should play,
  • the exact set of MCP tools and remote agents it is allowed to use,
  • the parameters and scope fragments required to safely call those systems, and
  • a signed graph of how that configuration was derived.

This is how we turn awareness of the moment into controlled, auditable action.

Assembly sits on top of the core architectural elements:

  • Roles - who is the user.
  • Assets & Collections - what they're working on and where.
  • MCPs & Agents - what capabilities exist and how they're governed.
  • Binding Rules - how capabilities and permissions propagate through the environment.

Given a role_id and a target collection/asset, the engine walks the binding graph, collects the relevant MCPs and agents, applies masks and parameters, and returns a compact, signed AssemblyResponse.

Although an Assembly can be triggered from within the Bifrost tool (typically for testing and development), the primary interface is the Bridge API. Applications, services, or orchestration layers call Bridge to obtain an Assembly, then use that Assembly to drive downstream LLM calls and tool executions.

The AssemblyResponse Model

At the API level, an Assembly is represented as:

AssemblyResponse {
  assembly_id: string
  assembled_at: string
  character: CharacterConfig
  mcps: FocusMCPConfig[]
  agents: FocusAgentConfig[]
  mim_graph: object
  signature: object
}

Field-by-field:

assembly_id: string

A unique identifier for this Assembly instance.

  • Used for correlation across logs, telemetry, and downstream tool calls.
  • Lets you reference or replay a specific configuration when investigating behavior or explaining why an agent could (or could not) do something.

assembled_at: string

The timestamp when the Assembly was created.

  • Captures when the environment was interpreted.
  • Helps correlate with asset moves, binding rule changes, or policy updates over time.

character: CharacterConfig

The character is the LLM-facing configuration:

  • Model / inference endpoint and configuration.
  • System prompt chunks and role-specific guidance.
  • Any policy or safety overlays that should always apply for this role and context.

This is where core procedures and institutional knowledge are embedded so that the copilot "feels" like the right expert for this user, in this space, at this moment.

mcps: FocusMCPConfig[]

The list of MCP configurations available to the agent in this Assembly:

Each entry represents a single MCP with:

  • Allowed tools (after applying role-based tool lists and masks).
  • Parameter constraints (e.g., a narrowed set of patient_ids or sensor IDs).
  • Scope fragments required for OAuth or other authorization systems.

Only the tools that survive the binding rules, masks, and role permissions appear here. This is how control is built into the structure instead of being bolted on later.

agents: FocusAgentConfig[]

The set of remote agents the copilot may call via A2A:

  • Endpoint and auth details needed to invoke the agent.
  • Role-based permissions controlling who can ask this agent to act.
  • Optional initialization parameters tailored to the current asset, project, or patient.

These are typically workflow- or system-specific agents (e.g., "scheduling agent", "factory-line reconfiguration agent") that your copilot can delegate to within the guardrails of the Assembly.

mim_graph: object

A condensed representation of the traversed binding graph that produced this Assembly:

  • Which assets and collections were considered.
  • Which binding rules fired and at what depth.

The primary use of the mim_graph is to give the LLM a quick overview of the relationships between the nodes traversed. This enables the LLM to understand queries, such as "Do the patient's siblings have any autoimmune disorders?", without having to try each possible patient node it has access to.

signature: object

A cryptographic signature and relevant metadata for verifying the Assembly.

  • Created by hashing the Assembly payload and signing with Mimory's private key (similar in spirit to a signed JWT).
  • Allows downstream systems to verify that:
    • The Assembly was produced by a trusted Mimory component.
    • The configuration has not been tampered with in transit.

This underpins governance and traceability - you can trust that what the agent is allowed to do is exactly what was assembled.

How Assemblies Are Used via Bridge

A typical flow with the Bridge API looks like:

1. Call Bridge to Assemble

Your service sends a request describing:

  • The role of the current user.
  • The current collection (collection, zone).

2. Receive an AssemblyResponse

Bridge returns an AssemblyResponse with all character, MCP, and agent configuration, plus the signature and mim_graph.

3. Run the Copilot Using the Assembly

Your application:

  • Uses character and mim_graph to construct the LLM system prompt and model configuration.
  • Uses mcps and agents to register tools and remote agents within your runtime.
  • Uses signature and assembly_id for logging, audit, and trust checks.

4. Log and Explain

When you need to explain "what could this copilot do for this user at this time, and why?", you reference assembly_id and logs.

Bridge API Endpoints

Assembly Operations