Agents should reuse capabilities, not rewrite shell scripts

October 5, 2026 · Kishore Babu Gutta

AI agents are getting very good at generating shell scripts.

That is useful when a problem has never been solved before.

It is much less useful when the engineering task has already been understood, reviewed and encoded once.

If an organization already knows how to create a repository, configure a cloud workload, deploy a service, update DNS and verify the result, why should every new agent reconstruct that logic from scratch?

That question leads to a different model for agent execution:

If a governed capability already exists, the agent should discover it and execute it instead of regenerating imperative automation.

The common pattern today

A typical agent workflow still looks like this:

User intent
   ↓
Agent
   ↓
write shell / Python
   ↓
figure out provider CLIs and APIs
   ↓
handle credentials
   ↓
handle ordering
   ↓
handle retries and failures
   ↓
hope the final state is correct

The generated code may be perfectly reasonable.

But the next agent often has to reason through the same problem again.

The execution knowledge lives inside a transient conversation or temporary script instead of becoming a durable engineering asset.

Move execution knowledge into a capability

Engineering Runtime capabilities are intended to capture reusable engineering intent as executable contracts.

Instead of repeatedly asking an agent to generate:

gh ...
gcloud ...
kubectl ...
curl ...
jq ...
if ...
retry ...

the desired shape is:

User intent
   ↓
AI agent reasons
   ↓
find an existing capability
   ↓
inspect its inputs and contract
   ↓
execute it through Engineering Runtime

A larger capability can represent one coherent engineering task even when the implementation crosses several providers.

For example:

provision-service
   ↓
GitHub operation
   ↓
GCP operation
   ↓
Kubernetes operation
   ↓
DNS operation
   ↓
verification

The agent chooses the intent and supplies the parameters.

Runtime owns the execution contract.

Why this is more than stored automation

A reusable script is already valuable.

A governed capability can go further because every step re-enters the Runtime execution boundary.

That boundary can provide:

• provider and operation resolution;
• authentication and context;
• policy admission;
• credential mediation;
• structured step outputs;
• bounded dependencies between steps;
• verification;
• sanitized results;
• audit and evidence.

The capability does not create a privileged execution path.

Its provider steps use the same Runtime-owned provider operations as direct execution.

That matters because reusable engineering knowledge should not require a second security model.

Capabilities can already carry step-to-step knowledge

The current result grammar can expose typed outputs from one step to later steps.

A later step may reference an earlier step only through declared dependencies.

Conceptually:

create repository
   ↓ output: repository_id

configure workload
   needs: create repository
   ↓

deploy service
   needs: configure workload
   ↓

verify

The goal is not to recreate a general-purpose programming language.

It is to give capabilities enough bounded data flow to represent real engineering intent without falling back to arbitrary shell interpolation.

Verification belongs where the intent needs proof

Not every step needs a live verification read.

Some steps are read-only discovery, parameter preparation, or intermediate data gathering. Some mutations may already have a provider contract whose result is sufficient for that part of the flow. Other operations are important enough that the capability should explicitly read authoritative state back and prove the desired condition.

So the useful model is selective:

step
  ↓
does this part of the intent require authoritative proof?
  ├─ no  → keep the normal governed result/evidence
  └─ yes → observe / mutate if needed / verify live state

The capability author chooses where verification is required by the engineering intent and the operation semantics. Runtime then enforces the declared grammar and records whether that proof passed, failed or was unavailable.

This avoids turning every workflow into a redundant sequence of write-then-read operations while still allowing the important state transitions to be proven.

The important part: rerun from live state

Long workflows become much more useful to agents if failure does not automatically mean "start debugging a half-finished script."

Engineering Runtime's current capability result model supports a stronger pattern for operations that have the required observation and verification semantics:

observe live provider state
        ↓
is the desired state already satisfied?
        ├─ yes → SATISFIED
        │
        └─ no
            ↓
        mutation required?
            ↓
          execute
            ↓
        read live state again
            ↓
          verify
            ↓
   APPLIED / RECONCILED

On a later run, Runtime observes the provider again.

It does not rely on a Runtime-owned resource-state database or a workflow checkpoint to decide that the external system is correct.

This is stateless reconciliation.

Why this differs from replaying a script

Imagine a long capability has already completed the first twenty operations and then a later provider is temporarily unavailable.

A naive retry model might replay every command blindly.

That can be dangerous.

The stronger model is:

rerun capability from the beginning
        ↓
each reconcilable operation reads live state
        ↓
already correct → SATISFIED
drifted         → RECONCILED
missing         → APPLIED
        ↓
continue

That does not mean every arbitrary command is automatically safe to rerun.

The guarantee exists only where the capability uses operations whose observation, mutation and verification semantics make reconciliation explicit.

That distinction is important.

The Runtime should refuse to pretend an opaque side effect is idempotent merely because it appears inside a capability.

No Runtime state file as the authority

This is also different from systems whose execution model depends on an authoritative local state file.

For capability reconciliation, the provider remains the source of truth.

Capability
   = reviewed intent

Provider
   = live reality

Runtime
   = compare + govern + execute + verify

The Runtime may keep evidence about what happened.

That evidence is not the resource state used to decide what reality is on the next run.

The next run reads reality again.

Why this matters for large multi-provider workflows

Suppose an organization eventually has a capability with dozens of steps across several systems.

The interesting property is not the number of steps.

It is that the workflow can carry one coherent intent while each operation remains governed individually.

one engineering intent
        ↓
many bounded provider operations
        ↓
each step:
  auth/context
  policy
  typed result
  evidence
        ↓
reconcilable operations:
  observe
  mutate only when needed
  verify

That means an agent does not need to become the workflow's execution engine.

The agent can remain the reasoning layer.

Where MCP becomes natural

MCP gives agents a standard way to discover and invoke tools.

That makes it a natural future interface for the capability ecosystem.

The desired flow is:

User intent
   ↓
AI agent reasons
   ↓
ENGRT MCP
   ↓
search capabilities
   ↓
inspect capability contract
   ↓
select compatible version
   ↓
execute capability
   ↓
Engineering Runtime
   ├─ auth/context
   ├─ policy
   ├─ credential mediation
   ├─ deterministic execution
   ├─ verification
   └─ evidence
   ↓
GitHub + cloud + Kubernetes + SaaS

The agent does not need to know whether one operation underneath uses REST, GraphQL, a native CLI or another bounded MCP transport.

Those are execution details below the capability contract.

MCP is the interface, not the execution model

This distinction matters.

MCP can tell an agent:

search_capabilities(...)
inspect_capability(...)
execute_capability(...)

But Engineering Runtime still needs to decide:

• which identity is used;
• which target is active;
• whether the operation is allowed;
• what provider operation is actually executed;
• whether credentials remain outside the agent-facing interface;
• how failures are represented;
• whether live state proves success;
• what evidence is retained.

So the long-term division of responsibility is:

MCP helps the agent reach the capability. Engineering Runtime governs what happens after the capability is invoked.

The broad inbound capability-search/inspect/execute MCP surface is a product direction, not a claim that every part of this interface is already shipped today.

Reuse first — then self-author when the intent is new

Capability-first execution does not mean agents are limited to capabilities that were written months earlier.

A capable agent should first search for an existing trusted capability. If none expresses the engineering intent well enough, the next move can be to author a new capability against the exact contract installed with the current Runtime.

ENGRT already publishes its capability grammar/specification with the installed Runtime under Runtime Home. That gives an agent a version-matched authoring source instead of forcing it to guess syntax from training data or stale documentation.

Conceptually:

engineering intent
   ↓
search existing capabilities
   ↓
suitable capability found?
   ├─ yes → inspect → execute
   │
   └─ no
       ↓
   read installed ENGRT capability spec
       ↓
   author capability for this Runtime version
       ↓
   validate
       ↓
   test / plan / bounded execution
       ↓
   run
       ↓
   preserve reviewed capability for reuse

This also gives the agent a useful failure mode.

If the desired engineering intent cannot be represented safely by the current capability grammar, the agent should explain why instead of escaping immediately into an opaque script.

For example, it should be able to say that the current grammar lacks a required orchestration primitive, provider operation, typed data shape, or other contract needed to represent the task safely.

That creates a better boundary:

Use the capability grammar where it can express the intent. Explain the missing contract when it cannot. Use lower-level escape hatches only deliberately.

The agent can therefore participate in expanding the capability ecosystem:

new engineering intent
        ↓
agent discovers no suitable capability
        ↓
agent reads version-matched Runtime specs
        ↓
agent authors a new capability
        ↓
Runtime validates and executes it
        ↓
tests/evidence prove the behavior
        ↓
capability becomes reusable engineering knowledge

The long-term goal is not a static catalog.

It is a self-growing catalog constrained by the Runtime contract.

Reuse before re-reasoning

The agent's default decision hierarchy can eventually become:

1. Search for and reuse an existing trusted capability
        ↓ if insufficient
2. Read the installed ENGRT capability grammar/spec for this Runtime version
        ↓
3. Self-author and validate a new capability
        ↓ if the grammar/operations cannot express the intent safely
4. Explain the missing contract and use a bounded lower-level operation/escape hatch
        ↓
5. Turn the proven solution into reviewed reusable capability knowledge

That final step is what creates compounding value.

One solved task can become reusable engineering knowledge

The loop becomes:

one agent solves a new engineering task
        ↓
solution becomes a capability
        ↓
capability is reviewed / tested / versioned
        ↓
future agents discover it
        ↓
future agents reuse it
        ↓
less regenerated shell
        ↓
more consistent execution
        ↓
more evidence

The value of a large capability ecosystem is therefore not the number of YAML or Markdown files.

It is the amount of engineering reasoning that no longer has to be rediscovered during execution.

The larger thesis

The ambitious end state is:

Agents should reason about engineering intent, not continuously reinvent engineering execution.

If a trusted capability already captures the task, an agent should be able to discover it, understand its inputs, execute it and inspect the result without knowing every provider CLI flag or rewriting the workflow in shell or Python.

That is why capabilities, reconciliation and MCP fit together naturally:

MCP
  → discovery and invocation

Capabilities
  → reusable engineering intent

Engineering Runtime
  → governed deterministic execution

Live provider state
  → truth for verification and reconciliation

Evidence
  → proof of what happened

The agent remains responsible for reasoning.

The Runtime becomes responsible for reliable execution.

And every solved engineering task has the opportunity to become easier for the next agent instead of being forgotten when the conversation ends.