Skip to main content

Execution and control

An agent system turns a task into actions and checks their effects. This knowledge base uses agent for a system in which a model can choose subsequent actions from observations, and Agent Harness for the surrounding software that runs that process. These are editorial working definitions: industry usage overlaps, and a framework or hosted runtime may supply only part of the harness.

Anthropic distinguishes predefined workflows from model-directed control. Its later hosted design separates the session record, harness loop, and sandbox. These support useful boundaries without requiring that every deployment use separate services. building-agents managed-agents

Responsibility boundaries

ComponentResponsibilityFailure to distinguish it
ModelPropose next actions or outputTreating a prediction as a completed action
HarnessAssemble inputs, dispatch allowed actions, track progressLosing ownership of stopping and errors
EnvironmentExecute operations and expose observationsAssuming a transcript restores files or remote state
Task contractDefine requested result and constraintsDeclaring success because the loop stopped

This decomposition is an engineering model, not a standardized API. A compact local process offers straightforward setup and debugging. Separating services allows different lifetimes and access boundaries, but introduces message delivery, versioning and recovery work.

Task and environment lifecycle

As a design practice, establish inputs, permitted scope, output artifacts and observable completion criteria before an extended run. Initialize the workspace from an identifiable baseline; record which artifacts the run owns and which are shared. A browser session, repository checkout and remote database have different restoration needs. Define retention and cleanup separately from model context disposal.

Use control flow to choose actions and stopping rules, durable execution to survive interruptions, and coordination when work has multiple owners. General release and rollback decisions belong in evaluation and operations.

Established boundary, evolving implementation

Explicit ownership of state and effects is a stable design concern. The best placement of that ownership, and how much model-specific scaffolding is useful, remain deployment-dependent. Benchmark the complete system when replacing either the model or harness.

References