Docs / Concepts

Composition

Composition is using multiple governed capabilities together while preserving host, policy, context, and evidence boundaries.

Plain English

Composition is chaining useful hosted abilities without hiding who owns each step or why a step can fail.

Why it exists

Agents and applications need to combine capabilities, but operational trust depends on preserving each host boundary.

Formal definition

Composition is a protocol-level relationship between invocations where one capability result becomes context for another while keeping lifecycle, policy, and evidence explicit.

Concrete example

Ground the concept before the schema.

schedule_technician can compose with query_inventory and notify_customer to complete a field-service workflow.

complete_service_visitDeclared

Finds an available qualified technician and reserves a service window.

host: ServiceWorkflowpolicy: restrictedv0.3.0

Invocation trace

  1. 01 Actor

    Planning Agent

  2. 02 Capability

    complete_service_visit

  3. 03 Host

    ServiceWorkflow

  4. 04 Policy

    restricted

  5. 05 Context

    job_context + inventory_snapshot

  6. 06 Result

    Customer Notified

composition.json
json
{  "invocation_id": "inv_session_abc_001",  "capability_id": "schedule_technician",  "version": "1.0.0",  "mode": "sync",  "correlation": { "correlation_id": "session-abc" },  "subject": {    "id": "agent://planning-assistant",    "roles": ["dispatcher"]  },  "payload": {    "job_id": "job_456",    "window": "tomorrow"  },  "requested_at": "2026-06-16T15:14:20.000Z"}

Relationships

Where this sits in the protocol.

Each concept should explain its neighbors so implementation teams can preserve the boundary across manifests, invocation, evidence, and tests.

Composition uses capability results as context for later invocations.

Each host keeps its own policy and evidence boundary.

Failures must identify which capability and host caused the break.

Visual model

  1. 01Planning Agent invokes query_inventory.
  2. 02Result becomes context for schedule_technician.
  3. 03Confirmed Appointment becomes context for notify_customer.

Implementation notes

  • Keep correlation IDs across related invocations.
  • Represent each step as a separate capability outcome.
  • Expose partial failure instead of collapsing a composed flow into one error.

Common mistakes

  • Hiding multiple host calls behind a single opaque tool.
  • Losing policy state between steps.
  • Returning a generic workflow failure without capability evidence.

Related concepts

Keep reading through the boundary.