Docs / Concepts

Context

Context is the caller, audience, environment, and payload information a host needs to validate an invocation.

Plain English

Context is the information that makes a capability request meaningful and governable.

Why it exists

The same capability can be safe or unsafe depending on who calls it, why they call it, and which operational situation it touches.

Formal definition

Context is structured invocation metadata and payload state used for validation, authorization, execution, evidence, and replay.

Concrete example

Ground the concept before the schema.

job_context tells ServiceOpsHost which service job the Planning Agent wants to schedule.

schedule_technicianInvokable

Finds an available qualified technician and reserves a service window.

host: ServiceOpsHostpolicy: approval_requiredv1.0.0

Policy boundary

Approval required

manager_approval

A manager must approve technician scheduling before the host returns a confirmed appointment.

Invocation trace

  1. 01 Actor

    Planning Agent

  2. 02 Capability

    schedule_technician

  3. 03 Host

    ServiceOpsHost

  4. 04 Policy

    manager_approval

  5. 05 Context

    job_context

  6. 06 Result

    Confirmed Appointment

invoke.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.

Context travels inside the invocation envelope.

Policy uses context to decide whether execution is allowed.

Evidence records enough context to replay the decision path safely.

Visual model

  1. 01Caller supplies context with the invocation.
  2. 02Host validates the context shape and policy relevance.
  3. 03Result and evidence refer back to the same correlation context.

Implementation notes

  • Name required context fields in capability metadata.
  • Redact sensitive payload fields from evidence by default.
  • Keep subject identity separate from business context.

Common mistakes

  • Putting all context into an untyped blob.
  • Using context for authorization without recording the decision basis.
  • Leaking sensitive context into replayable evidence.

Related concepts

Keep reading through the boundary.

Host →Invocation →Policy →