← AgentsGitHub
PHASE 2 / RUNTIME BOUNDARY

Define the adapter before the runtime.

Phase 2 fixes the engineering semantics that a future agent runtime must preserve, while leaving transport and implementation choices open.

Lifecycle

prepare → execute → verify → accept

prepare

Load and validate the Agent Context. Resolve the boundary, contracts, allowed change surface, constraints, authority, and acceptance conditions. Preparation must not silently expand authority.

execute

Run the agent inside the declared context. The runtime is responsible for enforcing the host's actual tool, filesystem, network, credential, and approval controls.

verify

Evaluate the Agent Result against the Verification Plan and produce observable evidence. Verification may include schema, contract, unit, integration, static, policy, and human checks.

accept

Acceptance is a governing decision. A successful technical check does not itself authorize merge, release, deployment, or a boundary change.

Transport neutrality

The same artifact semantics may be carried by an MCP server, plugin, CLI, CI action, service, or another future mechanism. Phase 3 may select a transport without changing the BOUND artifact contract.

Adapter contract

The proposed machine-readable contract is available here, with its JSON Schema beside it.

Phase-3 invariant: runtime capability, authority, verification, and human acceptance remain distinct concerns.