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:
Author & check (on your machine)
Write the manifest, then
validateit. Nothing leaves your laptop yet.Shell$ phrony init ./weather-assistant
$ phrony agents validate ./weather-assistant/agent.yamlPublish (freeze a version)
publishsends 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)Deploy (make one version live)
deployflips a switch: this published version is now the active one that new runs will use.rollbackflips 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 activeRun (execute the live version)
runstarts 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:
$ make install-cli-pathOr build and place on your PATH manually — see Install binaries.
Connect to the runtime
The CLI resolves the runtime address in this order:
--runtime-addron the command linePHRONY_RUNTIME_ADDRin the environment- Default
127.0.0.1:7777
$ phrony --runtime-addr 127.0.0.1:7777 statusLoad .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:
demo/echo-agentVersioned 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
| Step | CLI | Runnable? |
|---|---|---|
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
| Command | Server required | Summary |
|---|---|---|
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)
| Command | Server required | Summary |
|---|---|---|
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.
| Command | Server required | Summary |
|---|---|---|
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
| Flag | Description |
|---|---|
--runtime-addr | Runtime gRPC address (overrides PHRONY_RUNTIME_ADDR) |
Typical workflow
$ 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