Skip to content

Vision

Engineering knowledge should become reusable execution

When a problem has already been solved, the next engineer, pipeline, or AI agent should be able to reuse that solution rather than recreate it.

That sentence is the whole argument. Everything below is what it takes to make it true.

The problem is not the tools

A single engineering task now touches source control, CI/CD, cloud platforms, Kubernetes, infrastructure tooling, security platforms, issue trackers, and whatever internal platform your company built. Each of those tools is good at its job.

The knowledge about how to combine them into a reliable operation is what has no home. It ends up scattered:

shell scriptsCI workflowswiki pagesrunbooks
repo utilitiesAI conversationsone engineer's memorynowhere at all

So the same problem gets solved four times, once per caller — an engineer writes a script, a pipeline reimplements it as workflow logic, an automation platform builds an integration, and an AI generates a fresh set of commands.

Each one works. Together they drift, and none of them is the place the knowledge lives.

The shift: change the unit of reuse

Engineering Runtime moves the reusable unit from a command or script to an Engineering Capability.

Engineering intent Capability Engineering Runtime Engineering systems

A capability captures the operation. The Runtime provides the deterministic boundary that executes it. The systems underneath stay exactly the systems your teams already use.

Engineering Runtime does not replace GitHub, Kubernetes, Terraform, your cloud, or their CLIs. It is a layer above them:

  • Providers expose curated Runtime operations for a system
  • Engines provide execution primitives, including governed use of existing binaries where a native CLI is still the right interface
  • Capabilities compose those into an outcome someone actually wants

What a capability is

A reusable engineering operation, written as a file. Things like updating CODEOWNERS across repositories, applying repository governance, validating configuration, preparing a release, or bootstrapping a service.

One capability can compose several Runtime operations while presenting a single outcome to whoever called it:

Capability — "apply repository governance"

apply repository governance
inspectupdatevalidatereport
Engineering Runtime

The caller never reproduces the implementation.

Because capabilities are files, engineering automation inherits everything files already have: version control, review, tests, documentation, sharing, diffing, and improvement over time. Operational knowledge stops evaporating into a one-off script or a chat log and becomes a durable asset.

What that changes

Three things follow from moving the unit of reuse, and each already works today rather than being a promise:

  1. A capability stops caring who called it. What you run by hand today, CI runs tomorrow and an agent discovers next year — no second implementation. The overview shows that contract.
  2. Execution becomes predictable enough to trust an agent with. Policy is evaluated before the operation, authentication is the platform's own, and the outcome is recorded — the same lifecycle whoever asked. See the technical documentation.
  3. Knowledge stops evaporating. Capabilities are files, so they get review, version history, tests and improvement instead of living in a chat log.

The rest of this page is about where that leads.

Reuse before regeneration

This is the part the industry has not settled yet.

AI is genuinely good at turning intent into engineering action, and that is most valuable when the problem is new. But generation is now cheap enough that the default response to any task is to generate something — including tasks that were solved, correctly, last quarter.

Generating a fresh implementation of a solved problem is not speed. It is re-earning risk somebody already paid for.

The goal is not to give AI less to do. It is to make "has this been solved?" the cheapest question to ask, so that reasoning gets spent on genuinely new problems. A capability that already exists, is documented, and has been reviewed should win against a fresh generation every time — and an agent should be able to find that out in one step.

That only works if the library is worth searching.

The ecosystem this builds toward

The opportunity is larger than any single capability: a growing library of executable engineering knowledge, covering the problems most teams solve repeatedly.

Capability ecosystem

Repository governanceSecurity operationsPlatform operationsRelease workflows
Engineering Runtime Engineering systems

An engineer or an agent facing a task asks one question first:

Does a capability for this already exist?

If it does, use it. If it does not, create one, validate it, document it, and the next person inherits it.

Critically, this does not require every workflow to become a new command inside the binary. The Runtime stays a focused execution foundation; providers and engines expose primitives; capabilities are the extensible layer. The number of useful operations can grow without the Runtime growing with it.

What we are deliberately not building

A direction is only credible if it says what it excludes. These are commitments, not omissions waiting to be filled in.

Not a replacement for your platforms

GitHub, Kubernetes, Terraform and your cloud stay authoritative for the resources they own. Runtime is a layer above them, and the moment it starts hiding them it has failed.

Not a second execution path

The Control Plane governs; it never executes. Runtime keeps working when the Control Plane is unreachable, and anything that breaks that is not shipped.

Not tied to one AI vendor

The contract is public and any capable assistant can read it. No customer-facing page will name one vendor as the way in.

Not a binary that grows forever

Every new workflow does not become a new built-in command. The Runtime stays a focused execution foundation; capabilities are the layer that grows.

That last one is the load-bearing constraint. It is what allows the number of useful engineering operations to grow without the thing executing them growing with it.

Local first, throughout. Engineering Runtime is useful on one laptop with no central platform involved. Organisations that later need fleet-level management add the optional Control Plane around it — never inside the execution path.

See what Runtime offers

What success looks like

Success is a change in the first question people ask.

Engineers "How do I script this?" "Is there already a capability for this?"
Agents generate → debug → execute → discard discover → execute → interpret
Teams "who knows how we do this?" "it is in the library, and it is reviewed"

New automation will always be needed. The goal is narrower and more achievable than "no more scripts": once useful engineering knowledge has been captured, it should not have to be rediscovered.

A capability ecosystem

Engineering knowledge should compound.
Not be rediscovered.

  • Humans and AIReason
  • CapabilitiesEncode knowledge
  • TeamsShare and improve
  • RuntimeExecutes consistently

Reason with AI. Execute with Runtime.