Software automation is good at turning instructions into actions.

A pipeline can deploy a release, Terraform can provision infrastructure, a runbook can restart a service, or an agent can inspect telemetry and choose a remediation step.

But all of those systems share the same weakness: they're usually better at executing instructions than at representing the intent behind those instructions.

That gap is easy to ignore while automation is simple. If a script only runs one command, the script itself may be enough to explain what should happen.

But as systems become more distributed, more policy-driven, and more autonomous, execution logic starts carrying responsibilities it was never designed to own.

A deployment workflow may now encode:

what should be deployed where it may run which constraints must hold which evidence must be checked who may approve the change when rollback is required which failures are acceptable

At that point, the automation is no longer just executing. It's also becoming the place where operational intent is defined.

And that's a problem.

Because when intent and execution are fused together, changing the executor can also change the meaning of the operation.

In my previous article, I introduced the idea of an executable operational specification: a machine-readable description of what an operation is supposed to achieve and how its outcome can be evaluated.

In this article, I want to go one level deeper.

The central question is:

What should exist between human intent and the system that executes it?

I will explore:

  • why automation tools often become accidental specifications

  • why intent and execution evolve at different speeds

  • what gets lost when intent is embedded in pipelines and scripts

  • why desired state is useful but still incomplete

  • how to introduce an explicit operational intent layer

  • how preconditions, constraints, evidence, and recovery rules fit into that layer

  • how execution plans differ from operational specifications

  • how this structure helps with AI agents

  • and what this separation still can't solve

The goal isn't to add another abstraction for its own sake. The goal is to make operational decisions easier to understand, evaluate, and change without rewriting the meaning of the operation every time the execution mechanism changes.

Prerequisites

You should be comfortable with:

  • key software architecture concepts

  • CI/CD

  • infrastructure automation

  • observability

  • distributed systems

  • basic policy concepts

  • TypeScript or a similar language

You don't need a specific orchestration tool or cloud platform. The examples are deliberately small and tool-independent.

Table of Contents

Automation Tools Often Become Accidental Specifications

Consider a deployment workflow. It may begin as something simple:

steps: - build - test - deploy

Then production requirements appear.

You add:

approval region validation health checks canary percentage rollback logic error-rate thresholds latency thresholds artifact verification

Eventually, the pipeline becomes the only place where the operation is fully described.

That creates an accidental architecture:

Operational intent ↓ pipeline configuration ↓ execution

The pipeline is now doing two jobs: it describes what the operation means and how the operation is executed.

Those responsibilities are related, but they're not identical.

Suppose this workflow says:

deploy: image: orders:v42 verify: errorRateBelow: 0.01 rollback: whenVerificationFails: true

That may work perfectly. But now imagine moving the deployment to another platform.

If the operational rules only exist inside this pipeline, you must rediscover and reimplement them while moving the executor.

The real migration becomes:

move execution mechanism + reconstruct operational intent

That's much more dangerous than just changing tooling.

Intent and Execution Change at Different Speeds

Operational intent is often relatively stable.

For example:

Deploy the approved version. Maintain availability. Do not exceed the error-rate threshold. Keep rollback possible. Do not deploy outside the approved region.

Those expectations may remain valid for years. But execution mechanisms change much more frequently.

A team may move through:

shell scripts Jenkins GitHub Actions Argo CD Kubernetes operators cloud-native deployment services AI agents

If intent is tightly coupled to those mechanisms, every tooling change risks becoming an operational redesign.

That creates unnecessary churn.

You want:

stable intent ↓ replaceable execution

not:

new executor ↓ rediscover the meaning of the operation

This separation becomes more important as automation becomes more sophisticated.

The more intelligence the executor contains, the easier it becomes for intent to disappear inside implementation details.

What Gets Lost When Intent Lives Inside the Executor

When operational intent is embedded directly in scripts and pipelines, several things become harder.

1. Review

A reviewer may see:

if: error_rate < 0.01

but not know whether that threshold is:

a business requirement an SRE policy a temporary rollout rule a historical workaround

The value is executable. Its meaning isn't explicit.

2. Auditability

Six months later, somebody asks:

Why was this deployment allowed?

The answer may require reconstructing:

pipeline version feature flags runtime variables dashboards approvals operator decisions

3. Portability

Changing tools means reimplementing rules.

4. Testing

You can test whether the pipeline works. But it's harder to test whether the operational intent itself is complete.

5. Governance

Authorization rules may become buried in workflow code.

For example:

production changes require approval

may be implemented as a platform-specific branch protection rule instead of being represented as part of the operation.

6. AI Execution

An AI agent may generate a valid sequence of commands while violating an unstated operational constraint.

The problem isn't that the executor is weak. It's that the intent isn't independently represented.

Desired State Helps, But It's Not the Whole Intent

Many modern systems already use desired-state models.

For example:

replicas: 3 image: orders:v42

That's useful.

The system can compare:

desired state vs. observed state

and reconcile the difference.

But operational intent often includes more than final configuration.

Suppose the desired state is:

orders:v42 replicas: 3

The operation may also require:

do not reduce availability below 99.9% do not deploy if payment dependency is degraded keep error rate below 1% require approval for production rollback if latency exceeds 400 ms

Those aren't simply target-state properties.

Some are:

preconditions runtime constraints evidence requirements governance rules recovery rules

Desired state is part of operational intent, but it's not always the entire operational intent.

The Missing Layer

A more explicit architecture looks like this:

Human / organizational intent ↓ Operational specification ↓ Execution planning / binding ↓ Executor ↓ Actions ↓ Evidence ↓ Evaluation

The operational specification is the missing layer.

Its job is not to execute commands. Its job is to preserve the meaning of the operation independently from the mechanism performing it.

That layer can contain:

objective scope preconditions constraints required evidence authorization rules recovery conditions

The executor then answers a different question:

How can I satisfy this specification using the tools available to me?

That's a cleaner separation.

A Small Deployment Example

Suppose we want to deploy version v42 of the Orders service.

The operational objective is:

Deploy Orders v42 to production.

But that's not enough.

We also know:

the payment dependency must be healthy at least 3 replicas must remain available error rate must remain below 1% p95 latency must remain below 400 ms production deployment requires approval rollback must remain possible

We can represent those concerns separately.

type DeploymentIntent = { service: string; version: string; environment: string; preconditions: { paymentDependencyHealthy: boolean; approved: boolean; }; constraints: { minAvailableReplicas: number; maxErrorRate: number; maxP95LatencyMs: number; }; recovery: { rollbackOnViolation: boolean; }; };

Then:

const intent: DeploymentIntent = { service: "orders", version: "v42", environment: "production", preconditions: { paymentDependencyHealthy: true, approved: true, }, constraints: { minAvailableReplicas: 3, maxErrorRate: 0.01, maxP95LatencyMs: 400, }, recovery: { rollbackOnViolation: true, }, };

Notice what's missing. There's no:

kubectl Terraform GitHub Actions Argo cloud API

The intent doesn't yet care how the deployment happens.

That's deliberate.

Separate Preconditions from Execution Steps

A precondition answers:

Is this operation allowed to start?

That's different from:

Which step should run first?

For example:

payment dependency must be healthy production approval must exist artifact must be signed maintenance window must be open

These aren't execution instructions. They're conditions that should be true before execution begins.

A simple evaluator might look like this:

type Preconditions = { paymentDependencyHealthy: boolean; approved: boolean; }; function canStart( preconditions: Preconditions ): boolean { return ( preconditions.paymentDependencyHealthy && preconditions.approved ); }

If:

canStart({ paymentDependencyHealthy: false, approved: true, });

returns:

false

the operation shouldn't begin.

That decision shouldn't depend on whether the executor is Kubernetes, a script, or an AI agent. The precondition belongs to the operational intent.

Separate Constraints from the Mechanism

Constraints answer what must remain true while or after this operation runs.

Examples:

replicas >= 3 error rate <= 1% latency <= 400 ms cost increase <= 20% region must remain us-east-1

An executor may use many different strategies to satisfy them.

For example, to maintain three replicas:

Kubernetes may use a rolling deployment another platform may use blue/green deployment an agent may temporarily scale capacity before switching traffic

The mechanism differs, but the constraint does not.

That's exactly why the constraint should live outside the executor.

Make Evidence Requirements Explicit

A constraint is only useful if you can evaluate it.

Suppose you define:

error rate <= 1%

Then you need a source of evidence.

For example:

Prometheus Datadog CloudWatch OpenTelemetry custom application metrics

The specification shouldn't necessarily hard-code one vendor. But it should say that evidence is required.

For example:

type EvidenceRequirement = { name: string; metric: string; }; const evidenceRequirements: EvidenceRequirement[] = [ { name: "availability", metric: "availableReplicas", }, { name: "errors", metric: "errorRate", }, { name: "latency", metric: "p95LatencyMs", }, ];

The executor or evidence collector can decide where those values come from. The specification defines what must be known. That distinction is important.

Define Recovery Before Execution Starts

Many operational workflows define rollback only after something goes wrong. But that's too late. Recovery is part of operational intent.

For example:

If error rate exceeds 1%, stop rollout. If p95 latency exceeds 400 ms, restore previous version. If evidence is unavailable, require human review.

These aren't just implementation details. They express acceptable operational behavior.

A simple representation might be:

type RecoveryPolicy = { rollbackOnConstraintViolation: boolean; requireHumanReviewWhenEvidenceMissing: boolean; };

The executor can implement rollback differently. The policy still belongs to the operation.

Operational Specification vs Execution Plan

This distinction is important.

An operational specification answers:

What should happen? What must be true? What evidence is required? What happens if constraints fail?

An execution plan answers:

Which actions will we perform? In what order? Using which tools?

For example:

Specification

Deploy Orders v42. Keep at least 3 replicas available. Error rate <= 1%. Rollback if the constraint is violated.

Execution plan

1. Scale Orders to 6 replicas. 2. Deploy v42 to 1 replica. 3. Route 10% of traffic. 4. Wait 5 minutes. 5. Check metrics. 6. Increase traffic. 7. Remove old replicas.

The plan is one possible way to satisfy the specification.

Another executor might produce a different plan. That's useful. It means the same operational intent can survive changes in tooling and execution strategy.

Why This Matters for AI Agents

This separation becomes especially important when the executor is an AI agent.

A traditional script usually has a predictable path while an agent may decide dynamically.

For the same incident, it might choose:

restart scale reroute disable feature change configuration

If correctness is defined by following one exact sequence, dynamic execution becomes difficult to verify.

But if correctness is defined by an operational specification, the agent has flexibility.

For example:

Objective: restore checkout availability Preconditions: payment database reachable Constraints: authentication remains enabled no payment duplication error rate <= 1% cost increase <= 20% Evidence: checkout success rate duplicate payment count error rate cost delta Recovery: escalate if constraints cannot be satisfied

The agent can choose different actions, but its behavior is still bounded.

That gives us:

Intent ↓ Specification ↓ Agent-generated plan ↓ Execution ↓ Evidence ↓ Evaluation

The agent is free to decide how. It's not free to redefine what success means.

That distinction will become increasingly important as autonomous systems gain more operational authority.

A Minimal TypeScript Model

We can combine these ideas into a small generic model.

type OperationalSpec<TContext, TEvidence> = { name: string; canStart( context: TContext ): boolean; evaluate( evidence: TEvidence ): EvaluationResult; recovery: RecoveryPolicy; }; type EvaluationResult = { conformant: boolean; failures: string[]; }; type RecoveryPolicy = { rollbackOnConstraintViolation: boolean; };

For a deployment:

type DeploymentContext = { paymentDependencyHealthy: boolean; approved: boolean; }; type DeploymentEvidence = { version: string; replicas: number; errorRate: number; p95LatencyMs: number; };

Then:

const deploymentSpec: OperationalSpec< DeploymentContext, DeploymentEvidence > = { name: "deploy-orders-v42", canStart: (context) => context.paymentDependencyHealthy && context.approved, evaluate: (evidence) => { const failures: string[] = []; if (evidence.version !== "v42") { failures.push( "wrong-version" ); } if (evidence.replicas < 3) { failures.push( "insufficient-replicas" ); } if (evidence.errorRate > 0.01) { failures.push( "error-rate-too-high" ); } if ( evidence.p95LatencyMs > 400 ) { failures.push( "latency-too-high" ); } return { conformant: failures.length === 0, failures, }; }, recovery: { rollbackOnConstraintViolation: true, }, };

Now execution can be handled elsewhere.

For example:

interface DeploymentExecutor { execute( spec: typeof deploymentSpec ): Promise<DeploymentEvidence>; }

That executor could be backed by:

Kubernetes a cloud platform a test harness a local simulator an AI agent

The specification remains the reference point.

A Practical Workflow

If you want to introduce this separation into an existing automation system, start with one operation.

1. Pick a Repeated Operation

For example:

deploy service rotate certificate scale worker pool restore backup

2. Extract the Objective

Write down what the operation is trying to achieve. Avoid commands.

3. Extract Preconditions

Ask:

What must already be true before this operation can begin?

4. Extract Constraints

Ask:

What must remain true during or after execution?

5. Define Evidence

For every constraint, identify the observation required to evaluate it.

6. Define Recovery

Decide what should happen when evidence shows that a constraint was violated.

7. Leave Execution Separate

Let the current automation tool remain the executor. Don't rewrite everything at once.

8. Evaluate the Existing Executor

Ask whether the current script, pipeline, or agent satisfies the extracted specification.

This is useful because the separation can be introduced incrementally. You don't need a new operations platform to begin.

What This Separation Doesn't Solve

Separating intent from execution doesn't automatically make operations correct.

You can still have:

wrong objectives bad thresholds missing evidence misleading metrics conflicting constraints unsafe executors security bugs incorrect recovery policies

The specification itself can be wrong. That matters.

A formal representation doesn't make an assumption true. It only makes the assumption easier to inspect and evaluate.

There's also a cost. More explicit operational intent means more artifacts to maintain.

If specifications aren't versioned and reviewed, they can become stale. If evidence definitions are weak, conformance results can become misleading. And some operational decisions remain difficult to formalize.

Human judgment doesn't disappear. The value comes from making more of that judgment explicit.

From Automation Logic to Operational Contracts

There's another way to think about this separation.

A mature operational specification starts to behave like a contract.

It says:

This operation may begin under these conditions. It must preserve these constraints. It must produce this evidence. Its outcome will be evaluated using these rules. If it fails, these recovery conditions apply.

That's much stronger than:

run this workflow

The workflow is an implementation. The operational contract describes what that implementation is responsible for achieving.

This gives us a structure like:

Intent ↓ Operational contract ↓ Execution plan ↓ Executor ↓ Evidence ↓ Evaluation

That separation creates room for something important:

multiple execution strategies for the same operational intent

And once that's possible, another question appears:

Can two different executors satisfy the same operational specification?

That's the question I want to explore next.

Conclusion

Automation has made software operations faster and more repeatable.

But execution is only one part of an operation. We still need to know:

why the operation is allowed what outcome is intended what constraints must hold what evidence is required what happens when the constraints fail

When all of that logic lives inside a pipeline, script, or agent, the executor becomes the accidental owner of operational meaning.

That coupling makes systems harder to review, migrate, audit, and verify.

A better separation is:

Intent ↓ Operational specification ↓ Execution plan ↓ Executor ↓ Evidence ↓ Evaluation

The specification describes what success means. The executor decides how to achieve it.

That distinction becomes increasingly valuable as execution mechanisms become more dynamic. Especially when those executors are AI agents.

Because the more freedom we give a system to decide how work gets done, the more explicit we need to be about what the work is supposed to achieve.