Reason with AI.
Execute with ENGRT.
One execution layer for engineers, CI/CD, automation and AI agents. Run operations against real systems with consistent policy enforcement, authentication and audit—independent of who or what invokes them.
Free Community Runtime · No account or server needed
One governed boundary Operations through REST, GraphQL, native CLI and file interfaces follow Runtime policy, identity/context and audit controls. MCP is an integration path, not a separate execution trust boundary.
Scope of the diagram The provider landscape above illustrates the architectural direction, not a claim that every depicted provider or operation is available or qualified today. Check supported providers and operations →
Demonstrated today GitHub APIs · local files · approved CLIs including kubectl, terraform and gcloud
30-second product read
What Engineering Runtime is — and why it exists
Engineering Runtime is a deterministic execution layer for operations against real systems. Humans, CI/CD, automation and AI agents can invoke the same reusable capability while Runtime applies one execution contract for policy, authentication, context, sanitization and audit. Engineering platforms are the first proving ground, not the product boundary.
Who needs it
Anyone building reliable execution for humans, CI/CD, automation or AI agents across real systems. Platform and engineering teams are an initial wedge, but the Runtime model is broader: reasoning can stay flexible while execution follows one deterministic, governed and evidenced contract.
Why now
AI can increasingly understand engineering intent and invoke tools. The harder problem is moving from reasoning to real infrastructure without giving every caller a different auth, policy, context and audit path.
What is already built
A working local Runtime with REST, GraphQL, Command and File engines; reusable capabilities; GitHub API execution; approved native CLI execution; policy checks; structured results; and local audit/evidence.
Why this approach
The product does not replace provider tools. It puts one governed execution boundary around them: reasoning stays with humans or AI; execution guarantees stay with Runtime. Why I am building it →
How it works
From install to governed execution in minutes
Install the Runtime
One local Runtime for macOS, Linux and Windows. No account or server.
brew install engineeringruntime/tap/engineering-runtimeWrite a capability
Describe a repeatable engineering operation as a Markdown capability with a deterministic Runtime block. Capabilities can live with the team that owns them and be reviewed like code.
Invoke the same operation
A human, CI job, automation or AI assistant can request the capability. The caller reasons about intent; Runtime performs the deterministic execution, checks policy first and records the outcome.
$ engrt bootstrap
Runtime Home: ~/.engrt
Runtime is ready.
# inside the working directory: allowed
$ engrt files write ./notes.txt hello
Status: success
Message: wrote 5 bytes to notes.txt
# outside it: refused before anything runs
$ engrt files write ../outside.txt hello
Status: denied
Execution: not dispatched
# verify the retained evidence chain
$ engrt --output json audit verify
{ "intact": true, ... }
How Runtime reaches your platforms
Five engines, one set of rules
Runtime reaches your platforms through REST, GraphQL, command-line, file and MCP engines, under the same policy, authentication, context and audit. It works with your existing systems; it does not replace them.
REST
HTTP APIs
Today: GitHub
GraphQL
GraphQL APIs
Today: GitHub
Command
Approved CLIs
Today: kubectl, terraform, gcloud and any CLI your policy approves
File
Files and config
Today: the files provider
MCP
Model Context Protocol
Today: initial bounded GitHub MCP task integration; broader coverage and qualification in progress
Every engine, including MCP, shares the same policy, authentication, context and audit, subject to the compiled safety floor. How providers use engines →
What Runtime provides
Governed automation without the rewrite
One implementation, every caller
Engineers, CI/CD, automation and AI agents run the same capability — not four copies that drift apart.
AI without vendor lock-in
AI stays on the reasoning side of the boundary. Runtime exposes a deterministic contract that assistants can invoke through supported execution surfaces without making the model the executor.
Policy before execution
Every request is checked against your policy before it reaches GitHub, cloud or the file system.
Audit by default
Allowed or denied, every operation leaves a local record you can tail, verify and export as JSON.
Reusable execution for agents
Do not make every agent rediscover solved engineering execution
Capabilities capture engineering intent once so humans, CI/CD, automation and AI agents can reuse the same governed execution. The long-term direction is capability-first: search and reuse a trusted capability when one already exists, author and validate one when it does not, and preserve proven execution as reusable engineering knowledge.
Reuse before re-reasoning
Solved operations should become durable capability knowledge instead of being regenerated as fresh shell or Python on every run.
Reasoning stays flexible
Humans and AI decide what should happen. Runtime owns the bounded execution contract that reaches the real system.
Engineering Runtime · Long-term vision
Executable Engineering Standards.
Turn your organisation's engineering standards into reusable, governed and verifiable execution.
Beyond running a script: encode approved procedures as reusable capabilities, enforce execution boundaries, and verify the resulting state. This is a product direction, not a claim of complete standards enforcement today. Explore the vision →
Execution evidence
Verify against reality where proof matters
For operations with explicit observation and verification semantics, Runtime can read authoritative provider state before and after execution, distinguish already-satisfied work from applied or reconciled work, and record evidence of the resulting state. Runtime does not claim that arbitrary opaque workflows are automatically retry-safe.
One product, four surfaces
Intent can start anywhere.
Execution stays deterministic.
Free Community Runtime for macOS, Linux and Windows. No account or server required.