Self-authoring capabilities — let AI help capture engineering knowledge

October 4, 2026 · Kishore Babu Gutta

Engineering Runtime is built around reusable capabilities.

That creates an obvious question:

If a capability does not exist yet, how should a human or AI agent create one safely?

The answer is not to let a model improvise against whatever command surface it remembers.

The Runtime should describe the exact contract it supports, and the authoring process should work from that contract.

The authoring loop

The intended loop is:

new engineering need
      ↓
human or AI reasons about the outcome
      ↓
read the installed Runtime contract
      ↓
check whether a capability already exists
      ↓
author a capability
      ↓
validate
      ↓
plan / inspect
      ↓
execute
      ↓
observe evidence
      ↓
review + version in Git

The important boundary is that reasoning helps create the contract; Runtime still governs execution of the resulting contract.

The Runtime teaches the author

Engineering Runtime exposes an authoring context for the exact binary installed:

engrt capability authoring-context

That authoring context points the author or assistant at the Runtime-owned contracts for:

• the capability grammar,
• provider operations,
• command surfaces,
• selected capability source,
• Runtime Home paths,
• version-specific rules.

The author does not have to rely on what an AI model happened to learn months earlier.

A new Runtime release should be able to teach the author how to write for that release.

Search before creating

Self-authoring should not mean generating a new capability for every request.

The first question is:

Does a capability for this already exist?

If the answer is yes, reuse it.

If not, then create one.

That gives the loop a very different shape from ordinary prompt-driven automation:

intent
  ↓
discover existing knowledge
  ├─ found → reuse
  └─ missing → author → validate → prove → version

The goal is to reduce regeneration of solved engineering problems.

Human-authored and AI-assisted are the same contract

A capability is still a file.

It does not become a different artifact because an AI helped write it.

The same reviewable contract should work whether it was authored by:

• an engineer,
• an AI assistant under an engineer's direction,
• automation generating a bounded template,
• or a future agent workflow.

The authorship path can vary.

The execution contract should not.

AI can help author engineering knowledge. Runtime makes that knowledge executable.

The author owns intent

Self-authoring also matters for reconciliation.

Runtime should not infer desired state from an arbitrary command.

The capability author expresses the outcome and selects operations whose contracts can support observation, execution and verification.

For state-aware steps:

author declares intended outcome
        ↓
Runtime/provider observes authoritative state
        ↓
already correct? → SATISFIED
missing?         → APPLIED
drifted?         → RECONCILED

For steps where that model does not make sense, the operation remains read-only or imperative.

This keeps the capability readable:

the author says what should happen; Runtime says whether and how it can execute.

Validation is not proof

A capability can be syntactically valid and still be wrong.

So authoring should not stop at validation.

A stronger authoring loop is:

author
  ↓
validate contract
  ↓
inspect / plan
  ↓
execute against a bounded target
  ↓
read structured results
  ↓
verify actual provider outcome where supported
  ↓
review the evidence

That is especially important when an AI wrote the first draft.

The model's confidence is not evidence.

The execution result is not automatically evidence of final state either.

Evidence already exists

This is not only a future idea.

The Engineering Runtime capability documentation already demonstrates an AI-assisted authoring flow in which an assistant is instructed to:

1. query engrt capability authoring-context;
2. read the installed agent/authoring contract;
3. search existing capabilities first;
4. write against the exact installed release;
5. validate, plan and execute;
6. inspect structured results rather than assuming validation proves correctness.

That flow produced a capability that was subsequently added to the capability library.

The broader autonomous lifecycle can evolve further, but the core authoring contract is already demonstrable.

Why this matters

If AI makes authoring cheaper, the number of useful capabilities can grow much faster.

But cheap generation without a stable contract would just create another pile of one-off automation.

Self-authoring becomes valuable when it produces durable engineering knowledge:

reason
  ↓
author
  ↓
validate
  ↓
prove
  ↓
review
  ↓
version
  ↓
reuse

That is how generation becomes compounding knowledge rather than disposable output.

The design principle

A compact version is:

Reason about new work. Reuse solved work. Author the missing capability. Govern execution with Runtime.

The long-term opportunity is not merely agents that can run commands.

It is humans and agents that can turn newly solved engineering problems into reusable, reviewed execution contracts for the next caller.