Putting Agents to Work: A Governed Execution Layer with CLI, Dry Run, and SSE

Language models are good at understanding goals and producing plans. Enterprise systems depend on deterministic interfaces, parameters, and state. A governed execution layer connects the two. A CLI is a useful agent interface because commands are explicit, inputs and outputs can be serialized, and execution fits existing scripts, containers, and audit systems.

Having a CLI is not enough. An agent-oriented execution layer must reduce the choice space, expose stable schemas, and provide separate controls for writes and long-running tasks.

Skills Map Business Language to Commands

An agent CLI should not expose hundreds of unrelated commands and expect the model to assemble them. Skills organize capabilities around data, permissions, dashboards, and workflows while documenting prerequisites, parameter constraints, and failure handling. The agent selects a business capability before invoking a command. This reduces the chance that “let this user view the dashboard” becomes “make the dashboard public.”

A Skill contract should identify:

• tasks inside and outside its boundary;
• required identity, tenant, and resource context;
• parameter schemas, enumerations, and defaults;
• read or write risk, approval, and rollback requirements;
• error categories and recovery guidance;
• resource IDs, status, and next steps returned on success.

The router chooses a capability; it does not widen authority. The command still executes with the current user and tenant context.

Structured Output Stops the Agent from Guessing

A person can infer from a log that an operation probably succeeded. An agent needs a stable contract. Success should return a resource ID, state, version, and follow-up actions. Failure should distinguish authorization, invalid parameters, network timeout, resource conflict, and policy denial.

Result field	Purpose
operation_id	Correlate the command, event stream, and audit record
status	Distinguish accepted, running, succeeded, failed, and cancelled
resource	Return resource type, ID, and version
error_code	Let the agent choose behavior by failure category
recoverable	Indicate whether retry or parameter correction is appropriate
next_actions	Offer executable recovery paths instead of vague prose

If human-readable logs are the only interface, the model has to guess what errors mean and automated retries become unsafe.

Dry Run Makes a Write Visible Before It Happens

Before an agent creates, changes, or deletes a resource, Dry Run calculates the impact. A user can review target objects, permission changes, dependencies, planned calls, and irreversible risk. Policy can also block cross-tenant sharing, restrict bulk export, or require production approval at this stage.

A preview needs resource and policy versions plus an expiration time. At execution, the platform confirms that the target has not changed. If someone edits the resource after preview, the agent must generate a new plan instead of overwriting newer state.

High-risk writes also need these controls:

1. Approval binds to a specific preview, not to a general one-time authorization.
2. An idempotency key prevents network retries from creating duplicates.
3. A multi-step workflow defines failure boundaries and compensation.
4. Deletion and wider permissions require human confirmation by default.
5. The execution receipt records actual changes, not only the plan.

SSE Provides Continuous State for Long Tasks

Modeling, batch queries, and workflows can run for tens of seconds or longer. SSE can stream the plan, progress, tool results, and errors so both the user and agent know where work is blocked. A client can reconnect and resume from the last event position.

Event	Required payload
started	Task ID, operation type, and parameter summary
progress	Step ID, progress, and current state
warning	Risk code, explanation, and intervention requirement
error	Error code, recoverability, and suggested action
completed	Result resource, version, and receipt
cancelled	Cancelling principal, reason, and cleanup state

SSE transports state; it is not the source of truth. The server must still persist task state, event sequence, and final result for reconnection, audit, and recovery.

A Governed Execution State Machine

The complete flow can be expressed as seven stages:

1. The agent selects a Skill and produces structured intent.
2. The CLI validates schema, identity, and resource scope.
3. Reads proceed to execution; writes produce a Dry Run.
4. Policy allows, requests approval, or denies the action.
5. The executor calls a Headless API with an idempotency key.
6. SSE streams progress while the task store persists state.
7. The system returns resource and audit receipts; failures trigger compensation or handoff.

The state machine must allow cancellation and human takeover. If the agent disconnects, the operation should not remain in an unknowable intermediate state.

Four Hard Constraints for the Execution Layer

• Every command has an explicit schema; the agent cannot concatenate arbitrary scripts.
• Every call uses current user and tenant permissions; tools do not inherit an overprivileged service account.
• Writes support preview, approval, idempotency, and rollback so failure does not leave unknown state.
• Long tasks provide progress, cancellation, and audit so a user can take over.

Models will change, but the execution contract should remain stable. Once business capabilities are available through governed CLI and API tools, teams can replace the model above them and let different agents reuse the same security boundary. Production value comes from work that is complete, observable, and accountable.

Further reading: HENGSHI SENSE Product and Technology White Paper.