runx

An agent can know exactly how to do a job and still have far too much access to do it safely. Reading a repository, drafting a release, publishing it, and paying an invoice are different acts. Each needs its own authority, even when one conversation contains all four.

Runx checks the operation before dispatch, supplies the credentials it needs, supervises execution and seals the result. A skill carries the instructions for the job; the Rust runtime supplies the shared execution machinery. It is published under Apache-2.0.

Stop reconstructing the job from the chat

A release manager needs to know which revision was checked, what was approved and whether the release appeared at its destination. The next agent needs the same information before it can safely continue the work.

Runx keeps those references with the execution record. Graphs can pass typed results from one skill to another, while authority is admitted separately for each step. Research can feed a release draft without giving the research step permission to publish it.

The ambition is for useful work to accumulate. A later job should be able to reuse a checked result with its evidence, rather than repeating the investigation or trusting an earlier agent’s confidence.

The skill carries the work

A skill packages instructions, declared inputs, and an execution profile around a specific capability. Its SKILL.md explains the judgment involved: what evidence matters, what can proceed, and when the operator should stop. A run.yaml execution profile can declare typed inputs, steps and the contracts those steps must satisfy. The runtime supplies the mechanics shared across skills: provider calls, credential delivery, process supervision and receipt sealing.

An agent can discover a skill through a URL, use a local package, or invoke it through the CLI. The same package can participate in a larger graph. Research can lead to a draft, a draft to a review, and an approved result to publication, with each step retaining its own boundary.

Authority gets narrower

A child step receives only the authority admitted for that step. Access to one repository does not become access to every repository. Permission to prepare a campaign does not imply permission to send it. Credentials reach the execution path without becoming material the model has to carry in its prompt.

Approval gates belong at the consequential act. That lets preparation continue while preserving a human decision over the actual send, spend, or publication. The runtime specification defines the contracts behind those decisions.

Prepare the release, then authorise publication

Consider an agent preparing a software release. It reads the repository and test evidence, drafts the release material, and presents the exact result for approval. Publication is a separate act with its own destination and authority. After publication, a readback from that destination supplies evidence of the result.

repository + test evidence
          |
     release draft
          |
   approval for publication
          |
   permitted provider operation
          |
   readback + execution record

The graph passes the draft and evidence between steps. Publication uses a connector operation for the named destination. The agent makes the judgments described by the skill, and the runtime admits the operation under the available grant.

The execution boundary also depends on what runs. Native capabilities enforce their declared contracts. Deterministic JavaScript runs without host APIs. A CLI tool is trusted code on the host: Runx controls its invocation, credentials and lifecycle, but does not turn it into an operating-system sandbox. That distinction is recorded with the result.

Start on your own machine

The local runtime can execute a skill and seal a receipt without a hosted account. This example uses the repository’s local echo skill:

npm install -g @runxhq/cli
git clone --depth 1 https://github.com/runxhq/runx.git
cd runx
runx skill ./examples/hello-world -i message="hello, runx" --json

The result includes a receipt identifier. Use runx history with that identifier to inspect its record. The repository quickstart covers the expected output and other invocation paths.

A receipt has a specific job

The record keeps the inputs, authority, decisions, outputs, and lineage attached to an execution. A signature lets a verifier check the record’s integrity and signer. It does not, on its own, establish that an external service behaved correctly or that the work was useful; those claims need their own evidence.

Skills, local operator loops, execution and default local state belong to the open-source runtime. The hosted catalog and connectors extend discovery and provider access; using a hosted connector does not move the operator onto a hosted service. Frantic puts Runx to work beneath its public bounty venue.