Skip to main content

Concepts

ECP (Execution Control Protocol) centers on three runtime ideas: a portable workflow, a host environment, and an operational Ecp instance. A workflow is a reasoned approach, captured — you design it once and run it many times, placing each step where it belongs on the determinism spectrum.

Workflow

A workflow is a portable graph of steps. You author it with the Fluent API or as JSON.
Canonical manifests use:
Workflows should stay portable: no host secrets, no environment-only helpers in the graph. Use ref() to read prior step state.

Workflow contract

The contract is separate from steps. Same verbs in Fluent and JSON: ecp.run(..., { input }) validates accepts before execute. The Graph Editor shows Inputs / Outputs from those schemas — they are projections, not dummy capabilities. See Fluent API and Schemas.

Environment

An environment binds what can run a workflow: runtime, extensions, policies, harnesses, and secrets access on the host.
Lifecycle (simplified): configure → bind extensions → environment:ready → runs may emit environment:beforeRunecp.terminate() ends the session.

Ecp instance

Call await env.init() to get an Ecp instance. Operational APIs live here — not on the environment builder:
  • run, validate, describe, search
  • encode, decode, patch
  • invoke (when used by hosts/harnesses)
  • terminate

Definitions, bindings, invocations

IDs use @namespace/name for extensions and @namespace/name.capability for capabilities.

State and refs

.as("echo") writes step output into run state. Later steps read it with ref("echo.field") (stored as $ref paths under state). Optional mode controls how state is written.

Hosts

Next steps