Runtime

Runtime

Overview

Phrony operator CLI — connect to the runtime and manage agents.

Operator CLI

The phrony binary is the operator CLI for a running Phrony runtime. It speaks gRPC to phrony-runtime for publish, deploy, sessions, and agent lifecycle. It also validates manifests locally without contacting the server.

The lifecycle in plain terms

An agent goes through the same short journey every time, and most commands map to one step of it:

  1. Author & check (on your machine)

    Write the manifest, then validate it. Nothing leaves your laptop yet.

    Shell
    $ phrony init ./weather-assistant
    $ phrony agents validate ./weather-assistant/agent.yaml
  2. Publish (freeze a version)

    publish sends a version to the runtime and freezes it forever. Publishing does not make it live — it's a version sitting in the library, ready but not in use.

    Shell
    $ export ANTHROPIC_API_KEY="sk-..."
    $ phrony agents publish ./weather-assistant/agent.yaml
    # → weather/weather-assistant 2.4.0 stored (not runnable until deploy)
  3. Deploy (make one version live)

    deploy flips a switch: this published version is now the active one that new runs will use. rollback flips it back to an earlier version.

    Shell
    $ phrony agents deploy weather/weather-assistant@2.4.0
    $ phrony rollback weather/weather-assistant # optional: back to previous active
  4. Run (execute the live version)

    run starts a session — one execution of the agent — against whatever version is currently active.

    Shell
    $ phrony run weather/weather-assistant
    # → run_abc123 started (uses active 2.4.0)

Why separate "publish" from "deploy"? So you can stage a new version safely and switch to it (or away from it) instantly, without re-uploading anything — the same reason deployments are separated from builds elsewhere in software.

Install

From a runtime repository checkout:

Shell
$ make install-cli-path

Or build and place on your PATH manually — see Install binaries.

Connect to the runtime

The CLI resolves the runtime address in this order:

  1. --runtime-addr on the command line
  2. PHRONY_RUNTIME_ADDR in the environment
  3. Default 127.0.0.1:7777
Shell
$ phrony --runtime-addr 127.0.0.1:7777 status

Load .env from the runtime repo (or set PHRONY_RUNTIME_ADDR) so the CLI matches RUNTIME_GRPC_ADDR where the daemon listens.

Agent references

Commands that take an agent use namespace/name:

Text
demo/echo-agent

Versioned references use namespace/name@semver (for example demo/echo-agent@1.2.0). The semver comes from metadata.version in the published manifest.

Agent lifecycle

Within one runtime instance, an agent version moves through distinct steps:

flowchart LR
  yaml[agent.yaml] -->|validate| ok[valid]
  ok -->|publish| ver["published version\n(immutable)"]
  ver -->|deploy| act["active deployment"]
  act -->|run| sess[session]
  act -->|rollback| act
StepCLIRunnable?
Author locally
Publish immutable version
No
Activate for sessions
Yes (when active)
Execute
Uses active deployment only
Roll back activation
Retire / deprecate version
Blocked for new sessions

Publish validates the bundle, resolves refs, and stores an immutable agent version (ref-only secrets when declared). Deploy appends an activation record so that version becomes the active one for run. Run resolves secret values per session when needed. Published-but-not-deployed versions exist in the registry but cannot be executed.

Bare phrony run demo/echo-agent resolves the active deployed version. An explicit demo/echo-agent@1.2.0 is allowed only when 1.2.0 is the currently active deployment in this runtime.

Each runtime instance is environment-agnostic: promoting between staging and production means publishing and deploying on separate runtime instances (typically via CI/CD), not a target or promote flag on the CLI.

Audit actor

Publish, deploy, and rollback record an actor for audit. Set PHRONY_ACTOR on the operator host (for example ci@github or an email). When unset, the CLI uses the OS username.

Commands

CommandServer requiredSummary
No
Scaffold agent.yaml
Yes
Runtime health and version
Yes
Roll back to a previous active version
Yes
Start a new session (active deployment; no credentials on CLI)
Yes
List, inspect, attach to, and cancel sessions
Yes
List, inspect, and decide pending tool approvals (out of band)
Mixed
Agent manifest and registry lifecycle (see subcommands below)
Mixed
Multi-agent bundle lifecycle (see subcommands below)

Agent commands (agents)

CommandServer requiredSummary
No
Validate an agent manifest locally
Yes
Diff local manifest against a published version
Yes
Publish manifest (immutable version; ref-only secrets)
Yes
List published versions for an agent
Yes
Metadata for a published version
Yes
Mark a version as not runnable
Yes
Retire a published version
Yes
Activate a published version for sessions
Yes
Show the active deployed version
Yes
Deployment activation history
Yes
List agents
Yes
Archive an agent

Bundle commands (bundles)

Multi-agent closures use kind: Bundle. See bundles for the full command reference.

CommandServer requiredSummary
Yes
List bundles registered in the runtime
No
Walk closure and write bundle.lock.json
No
Validate closure; compare lock when present
Yes
Verify committed lock and publish immutable bundle version (semver + lock hash)
Yes
Activate a published bundle semver or lock hash
Yes
List published bundle versions (semver + lock hash)
Yes
Show the active bundle deployment
Yes
Bundle deployment activation history
Yes
Start a session on the bundle root member
Yes
Inspect the union of fromEnv secret requirements for a deployed bundle

Global flags

FlagDescription
--runtime-addr
Runtime gRPC address (overrides PHRONY_RUNTIME_ADDR)

Typical workflow

Shell
$ phrony init ./my-agent
$ phrony agents validate ./my-agent/agent.yaml
$ phrony agents publish ./my-agent/agent.yaml
$ phrony agents deploy demo/my-agent@0.1.0
$ export ANTHROPIC_API_KEY="sk-..." # or: phrony run demo/my-agent -e .env
$ phrony run demo/my-agent