agentcli

agentcli is an agent-native workflow manifest standard, execution identity framework, and reference CLI. It gives agents and operators a declarative way to describe workflows, bind execution identity, acquire credentials, produce verifiable evidence, and compile manifests into runtime-specific artifacts.

Use agentcli on its own when you want a clean authoring, validation, local execution, and audit surface.

Use agentcli with openclaw-scheduler when you want that same manifest contract backed by a durable runtime with scheduling, queueing, retries, approvals, delivery, and SQLite state.

Together, agentcli is the control plane and openclaw-scheduler is the runtime.

If you need...	Start here
Fast local authoring, validation, and execution	`agentcli`
Durable schedules, retries, approvals, and runtime state	`agentcli` + `openclaw-scheduler`

Quick Start

If you just want to try the manifest model locally, start with the first path.

If you want to run the same workflows on a durable scheduler, use the second path.

`agentcli` on its own

# Install
npm install -g @amittell/agentcli

# Create a local home directory with a starter manifest
agentcli init

# Validate a simple manifest
agentcli validate examples/hello-world.json

# See the portable standalone plan
agentcli compile examples/hello-world.json --target standalone --explain

# Run a task locally
agentcli exec examples/trust-enforcement.json collect-data --dry-run --signer none

# Run a shell-only workflow DAG locally
agentcli run examples/trust-enforcement.json --root collect-data --signer none

# Inspect identity resolution
agentcli identity resolve examples/identity-v2.json echo-identity

# View recent audit records
agentcli audit --limit 10

# Verify execution evidence
agentcli verify <execution-id>

npm install -g @amittell/agentcli installs the agentcli command on your PATH so you can run agentcli ... from any directory. If you install the scoped package into a project instead, run the local binary with npx agentcli ....

`agentcli` with `openclaw-scheduler`

# Install and initialize the scheduler runtime
mkdir -p ~/.openclaw/scheduler
npm install --prefix ~/.openclaw/scheduler openclaw-scheduler@latest
npm exec --prefix ~/.openclaw/scheduler openclaw-scheduler -- setup

# Compile the same manifest for the durable runtime
agentcli compile examples/hello-world.json --target openclaw-scheduler --explain

# Preview the jobs that would be created or updated
agentcli apply examples/hello-world.json \
  --db ~/.openclaw/scheduler/scheduler.db \
  --scheduler-prefix ~/.openclaw/scheduler \
  --dry-run

# Ask the runtime which capability surface and handoff version it supports
agentcli apply examples/hello-world.json \
  --db ~/.openclaw/scheduler/scheduler.db \
  --scheduler-prefix ~/.openclaw/scheduler \
  --check-capabilities

# Inspect the runtime state through agentcli
AGENTCLI_SCHEDULER_DB=~/.openclaw/scheduler/scheduler.db \
  agentcli inspect jobs --fields id,name,last_status

Node 22.5.0 or newer is required. Scheduler inspection uses node:sqlite, which became stable in Node 23.4.0.

Better Together

agentcli and openclaw-scheduler are complementary:

agentcli gives you the authoring contract: schema, validation, examples, discovery, identity binding, local execution, audit, and machine-readable CLI / JSON-RPC surfaces.
openclaw-scheduler gives you the durable runtime: schedules, queueing, retries, approvals, delivery, and persistent state.
The same manifest can start as a local, portable workflow in agentcli and then be compiled and applied into openclaw-scheduler without rewriting it into a runtime-specific format.

If you want to start simple, start with agentcli alone. If you want durable operation, pair it with openclaw-scheduler.

Wrapping Existing CLI Tools

agentcli works well as a stable wrapper around existing CLI tools such as flyctl, kubectl, gh, terraform, and the Stripe CLI. See Wrapping CLI Tools for the full guide, including a complete multi-tool deployment pipeline that chains Stripe Projects, Prisma, and Fly.io under agentcli governance.

The pattern is:

Put the exact tool invocation in shell.program and shell.args[].
Bind credentials declaratively when the tool expects environment variables or temp files.
Validate and run the workflow locally with agentcli exec.
Compile and apply the same manifest into openclaw-scheduler when you want durable execution.

For example, flyctl-ops.json wraps a simple flyctl status --app my-app check, binds FLY_API_TOKEN through an identity profile, and escalates failures into a read-only triage step.

agentcli validate examples/flyctl-ops.json
agentcli exec examples/flyctl-ops.json check-app-status --dry-run --identity-debug
agentcli compile examples/flyctl-ops.json --target openclaw-scheduler --explain

For shell-only manifests with trigger chains, use agentcli run to execute the local DAG from one or more scheduled roots:

agentcli run examples/trust-enforcement.json --root collect-data --signer none
agentcli run examples/trust-enforcement.json --all-roots --dry-run --signer none

stripe-ops.json wraps the Stripe CLI with three operations: list recent charges, check balance, and list failed payment intents. It binds STRIPE_API_KEY through an identity profile with strict trust enforcement, parses JSON output, generates SSH evidence, and escalates API failures into an agent-based triage step.

export STRIPE_API_KEY="sk_test_..."
agentcli validate examples/stripe-ops.json
agentcli exec examples/stripe-ops.json check-balance --signer none
agentcli exec examples/stripe-ops.json list-recent-charges --signer none
agentcli audit --limit 3

The same pattern works for any CLI tool that reads credentials from the environment: kubectl with KUBECONFIG, gh with GH_TOKEN, terraform with TF_TOKEN_app_terraform_io, aws with AWS_ACCESS_KEY_ID, and so on. Put the tool invocation in shell, bind the credential through an identity profile, and agentcli handles the rest.

If the tool only needs a direct wrapper, you can also scaffold the starting point with:

agentcli init --tool flyctl

Dynamic credentials via `command`

When credentials are managed by an external tool, use value_from: { command } to acquire them at execution time:

"inputs": {
  "client_secret": {
    "value_from": {
      "command": "vault kv get -field=api_key secret/myapp"
    }
  }
}

This works with any CLI that prints a credential to stdout: Vault, 1Password, AWS SSM, Stripe Projects, Doppler, macOS Keychain, and others. See stripe-projects.json for a full example and docs/guide-identity.md for the complete reference.

Core Model

A manifest is a declarative description of one or more workflows. Each workflow contains tasks that define what to execute, when, and under what identity and constraints.

manifest
  version: "0.2"
  identity_profiles[]         # reusable identity declarations
  authorization_proof_profiles[]  # manifest approval methods
  evidence_profiles[]         # post-execution attestation methods
  workflows[]
    identity                  # workflow-level identity binding
    contract                  # execution boundaries and trust requirements
    tasks[]
      shell / prompt          # what to execute
      schedule / trigger      # when to execute
      identity                # task-level identity override
      evidence                # attestation binding
      contract                # task-level execution boundaries
      model_policy            # LLM provider, model, thinking level
      intent                  # plan/read-only execution mode
      output                  # preview, offload, format hints
      budgets                 # fan-out, queue, context limits
      approval                # manual/auto approval policy
      delivery                # notification routing
      reliability             # retry, overlap, guarantee
      on_failure              # failure triage sub-task

Tasks use structured execution fields (shell.program, shell.args[]) instead of opaque command strings. Each task defines exactly one invocation mode: schedule (cron) or trigger (parent task dependency).

See the manifest spec for field-level detail.

Execution Identity (v0.2)

Every agentcli execution answers five questions:

Who is running this? (identity profile with a stable principal URI)
How did they authenticate? (pluggable provider: env var, file, OIDC, cloud workload, or CLI command)
What are they allowed to do? (contract: trust level, sandbox, network, allowed paths)
Can we prove it happened? (evidence: SSH-signed attestation of command + result)
Is there an audit trail? (structured, append-only, secrets-redacted records)

{
  "identity_profiles": [
    {
      "id": "deploy-agent",
      "provider": "oidc-client-credentials",
      "subject": { "kind": "service", "principal": "agent://acme.com/deploy-bot" },
      "auth": {
        "mode": "service",
        "scopes": ["deploy:staging"],
        "provider_config": { "token_endpoint": "https://auth.acme.com/oauth2/token", "client_id": "deploy-bot" },
        "inputs": { "client_secret": { "value_from": { "env": "DEPLOY_CLIENT_SECRET" } } }
      },
      "trust": { "level": "supervised" },
      "presentation": {
        "bindings": [{ "source": "credentials.access_token.value", "target": { "kind": "env", "name": "DEPLOY_TOKEN" }, "redact": true }],
        "cleanup": "always"
      }
    }
  ]
}

Trust levels (untrusted, restricted, supervised, autonomous) are enforced against the contract's required_trust_level. When a task's trust is below the floor and trust_enforcement is strict, execution is blocked.

For the full guide: Identity Setup | Wrapping CLI Tools | Spec Reference

Identity Providers

Provider	Description
`none`	No credentials. Declares identity for audit and contract enforcement only.
`env-bearer`	Reads a bearer token from an environment variable at execution time.
`file-bearer`	Reads a bearer token from a file at execution time.
`oidc-client-credentials`	Acquires an access token using the OAuth 2.0 Client Credentials grant.
`oidc-token-exchange`	Exchanges an existing token for a new one using RFC 8693 Token Exchange.
`azure-managed-identity`	Acquires a token from the Azure Instance Metadata Service (IMDS). Works on Azure VMs, App Service, and Container Instances.
`aws-sts-assume-role`	Assumes an AWS IAM role via STS and returns temporary credentials. Includes AWS Signature V4 signing.
`gcp-workload-identity`	Acquires a token from the GCP metadata server. Works on Compute Engine, Cloud Run, and GKE.
`spiffe-jwt-svid`	Acquires a JWT-SVID from the SPIFFE Workload API or a projected volume file. Works in SPIFFE-enabled Kubernetes clusters.
`entra-agent-id`	Acquires a token via Microsoft Entra Agent ID using JWT bearer client assertion. Supports Agent Registry, Conditional Access, and IMDS fallback.
`stripe-api-key`	Resolves Stripe API keys with scope-aware permissions. Supports precreated restricted keys by scope name and dynamic key minting via the Stripe API.

Use agentcli identity providers to list registered providers and agentcli identity schema <provider> to inspect the current provider metadata surface, including capabilities.

Authorization Proof Methods

Authorization proof verifies that the manifest itself was approved before execution.

Method	Description
`none`	No proof required.
`jwt`	Manifest approval encoded as a signed JWT verified with a configured `public_key` or `jwks_uri`.
`detached-signature`	Manifest approval via a detached cryptographic signature.
`certificate`	Manifest approval via an X.509 certificate chain.

Use agentcli authorization-proof methods to list available methods and agentcli authorization-proof schema <method> to inspect verifier metadata for a method.

Authorization Providers

Provider	Description
`none`	No external authorization. Contract enforcement still applies.
`opa`	Evaluates policy using Open Policy Agent.

Use agentcli authorization providers to list registered providers and agentcli authorization schema <provider> to inspect provider metadata and capabilities.

Evidence Providers

Provider	Description
`none`	No evidence produced. Audit records are still written.
`ssh`	Signs evidence payloads using SSH keys. Verifiable with `agentcli verify`.

Use agentcli evidence providers to list registered providers and agentcli evidence schema <provider> to inspect provider metadata.

Signing Providers

agentcli exec and agentcli run use signing providers for execution attestations.

Use agentcli signing providers to list the registered signing providers and the attestation methods they expose.

CLI Reference

General

Command	Description
`version`	Show package and manifest spec version.
`init [--tool program] [--output path] [--workflow-id id] [--task-id id]`	Initialize agentcli home directory with starter manifests.
`paths`	Show resolved agentcli home, manifest, output, state, and audit paths.
`schema [target]`	Emit JSON schema for manifest, workflow, task, schedulerJob, standalonePlan, rpcRequest, or rpcResponse.
`describe [target]`	Describe manifest, workflow, task, targets, commands, or rpc surfaces as structured JSON.
`targets`	List available compilation targets.
`skill-path`	Print the path to the agentcli skill manifest for MCP tool registration.

Manifest Operations

Command	Description
`validate <path-or-json\|->`	Validate a manifest against the spec. Accepts file path, inline JSON, or stdin.
`compile <path> [--target t] [--write path] [--explain]`	Compile a manifest to a target format. Targets: `standalone`, `openclaw-scheduler`.
`convert <path-or-json\|-> [--output path]`	Convert a v0.1 manifest to v0.2 with safe defaults.
`merge <manifest1> <manifest2> [--output path]`	Merge two manifests into one.
`import <directory> [--name name]`	Import a manifest directory into the registry.

Execution

Command	Description
`exec <path> <task-id> [--workflow id] [--dry-run] [--timeout ms] [--signer ssh\|none] [--signing-key path] [--db path] [--scheduler-prefix path\|--scheduler-bin path]`	Execute shell tasks locally with identity resolution, contract enforcement, and attestation, or delegate non-shell tasks to the scheduler when configured.
`run <path> [--workflow id] [--root task-id\|--all-roots] [--dry-run] [--timeout ms] [--signer ssh\|none] [--signing-key path]`	Execute a shell-only workflow DAG locally. Trigger edges, `contains:` / `regex:` conditions, and `on_failure` handlers are evaluated in-process.
`apply <path> [--db path] [--scheduler-prefix path\|--scheduler-bin path] [--dry-run] [--explain] [--adopt-by id\|name] [--check-capabilities]`	Apply a manifest to the scheduler runtime, or inspect runtime capability negotiation without writing jobs.

agentcli run is intentionally narrow:

It only executes tasks with target.session_target: "shell".
It runs one workflow DAG locally from a selected scheduled root, or from every root when --all-roots is set.
It does not add queueing, retries, approvals, or durable state.
Manifests that include main or isolated tasks still need a runtime adapter such as openclaw-scheduler.

Identity and Authorization

Command	Description
`identity providers`	List registered identity providers.
`identity schema <provider>`	Show provider metadata and capabilities for an identity provider.
`identity resolve <manifest> <task-id> [--workflow id]`	Resolve the effective identity for a task.
`identity validate-delegation <manifest> <task-id> [--workflow id]`	Validate delegation chain for a task.
`authorization-proof methods`	List available authorization proof methods.
`authorization-proof schema <method>`	Show verifier metadata for an authorization proof method.
`authorization-proof verify <manifest> <task-id> [--workflow id]`	Verify authorization proof for a task.
`authorization providers`	List registered authorization providers.
`authorization schema <provider>`	Show provider metadata and capabilities for an authorization provider.
`authorization evaluate <manifest> <task-id> [--workflow id]`	Evaluate authorization policy for a task.
`evidence providers`	List registered evidence providers.
`evidence schema <provider>`	Show provider metadata for an evidence provider.
`whoami <manifest> <task-id> [--workflow id]`	Show the fully resolved identity, trust, and contract for a task.

Inspection and Audit

Command	Description
`inspect <jobs\|runs\|queue\|approvals> [--db path] [--fields a,b,c] [--limit n] [--sanitize basic] [--ndjson]`	Inspect scheduler runtime state with field masks and sanitization.
`audit [--limit n]`	Display recent audit records from the append-only log.
`verify <execution-id> [--allowed-signers path]`	Verify execution evidence for a completed run.
`signing providers`	List registered signing providers and their attestation methods.

Registry

Command	Description
`registry list`	List all registered manifests.
`registry add <path> [--name name]`	Register a manifest by path.
`registry show <name>`	Show a registered manifest.
`registry remove <name>`	Remove a manifest from the registry.

JSON-RPC

Command	Description
`serve [--db path]`	Start a stdio JSON-RPC server.

Global Flags

Flag	Description
`--version`, `-v`	Show package and manifest spec version.
`--json`	Force JSON output.
`--pretty`	Colorize JSON output for human readability.
`--ndjson`	Emit item streams as newline-delimited JSON.

Environment Variables

Variable	Default	Description
`AGENTCLI_HOME`	`~/.agentcli`	Home directory for manifests, output, state, and audit.
`AGENTCLI_OUTPUT`	`json`	Default output format: `json` or `ndjson`.
`AGENTCLI_TARGET`	`standalone`	Default compilation target.
`AGENTCLI_SIGNER`	`ssh`	Default signing provider for execution evidence.
`AGENTCLI_SIGNING_KEY`	(none)	Path to SSH private key for evidence signing.
`AGENTCLI_SCHEDULER_DB`	(none)	Path to scheduler SQLite database for inspection.
`AGENTCLI_SCHEDULER_PREFIX`	(none)	npm prefix path for the scheduler runtime.
`AGENTCLI_SCHEDULER_BIN`	(none)	Direct path to the scheduler binary.

JSON-RPC

agentcli serve exposes the full command surface over stdio JSON-RPC 2.0. This is the preferred integration point for agent systems that need programmatic access without shell parsing.

The server emits an agentcli.ready notification on startup. Use agentcli describe rpc to inspect the machine-readable method and notification surface.

See docs/protocol.md for the full protocol specification.

Compilation Targets

Target	Description
`standalone`	Portable plan for authoring, validation, explanation, and protocol use. No durable runtime required.
`openclaw-scheduler`	Compiler target for the durable scheduler runtime. Supports runtime model policy, plan/read-only intent, output offload budgets, queue/approval/fan-out guardrails, and identity compilation.

# Compile for standalone use
agentcli compile my-workflow.json --target standalone --explain

# Compile for the scheduler runtime
agentcli compile my-workflow.json --target openclaw-scheduler --explain

# Apply to the scheduler (creates or updates jobs)
agentcli apply my-workflow.json --dry-run
agentcli apply my-workflow.json

Migration from v0.1

v0.1 manifests continue to work unchanged. The validator accepts both versions, and the execution path for v0.1 manifests is preserved.

To upgrade a v0.1 manifest to v0.2 and gain access to identity profiles, evidence, and authorization features:

# Preview the conversion
agentcli convert my-v1-workflow.json

# Write the converted manifest to a file
agentcli convert my-v1-workflow.json --output my-v2-workflow.json

The converter applies safe defaults:

Subject kind is set to unknown (update to agent, service, workload, or user as appropriate)
Trust level defaults to supervised
Delegation mode defaults to none
Cleanup policy defaults to always
Attestation strings are mapped to authorization proof profiles with method detection (OIDC to jwt, SSH to detached-signature, cert to certificate)

For scheduler migration (adopting existing jobs), use --adopt-by name during the initial apply:

agentcli apply my-v2-workflow.json --adopt-by name --dry-run
agentcli apply my-v2-workflow.json --adopt-by name

After adoption, subsequent applies use the default --adopt-by id with no flag needed.

Examples

The examples/ directory contains annotated manifests covering the full feature range:

Manifest	Description
hello-world.json	Minimal workflow with a scheduled task and a triggered follow-up.
shell-workflow.json	Shell execution with delivery, reliability, and triggered escalation.
public-shell-failure-triage.json	Shell failure triage with model policy, plan intent, output offload, and budgets.
public-report-publish.json	Multi-step report pipeline: capture, analyze, publish with approval gates.
public-bot-health.json	Bot health monitoring with plan/read-only intent and context retrieval.
flyctl-ops.json	Wrapping `flyctl` as a structured tool invocation with token binding and failure triage.
identity-contract.json	v0.1 identity and contract fields with approval and attestation.
identity-v2.json	Full v0.2 identity: profiles, trust levels, credential presentation, evidence, and authorization proof.
oidc-service-auth.json	OIDC client credentials authentication with token materialization into the process environment.
trust-enforcement.json	Graduated trust levels with strict and advisory enforcement across multiple tasks.
authorization-proof.json	JWT-based manifest authorization proof with signature-backed verification via `jwks_uri`.
stripe-identity-step-up.json	Stripe Identity-style step-up for sensitive commands: normal service auth plus a short-lived signed JWT proof and actor-context audit metadata.
stripe-identity-step-up.rego	Example OPA policy for the Stripe Identity step-up manifest.
cloud-workload.json	Azure managed identity for cloud workload authentication with evidence and compliance context.
stripe-ops.json	Wrapping the Stripe CLI with API key binding, JSON output parsing, evidence, and failure triage.
stripe-projects.json	Wrapping Stripe Projects: credential sync, status checks, and database migrations with two identity profiles at different trust levels.
full-stack-deploy.json	Full deployment pipeline chaining Stripe, Prisma, and Fly.io with three identities, trust enforcement, evidence, and failure triage.
aws-ops.json	AWS infrastructure monitoring: caller identity, S3 buckets, EC2 instances, CloudWatch alarms, and cost estimates with trust enforcement.
kubectl-ops.json	Kubernetes operations: pods, deployments, nodes, warning events, and manifest apply with approval gates.
terraform-ops.json	Terraform pipeline: init, plan, apply, and state show chained via triggers with strict trust on apply.
gh-ops.json	GitHub CLI: list PRs, check CI, list issues, and create releases with approval and trust enforcement.
docker-ops.json	Docker operations: containers, images, disk usage, build, and prune with network isolation on destructive tasks.
gcloud-ops.json	Google Cloud: identity check, compute instances, GKE clusters, and billing with evidence on all tasks.
curl-api.json	Generic REST API operations: health checks, authenticated data fetch, and webhook posts with token binding.
psql-ops.json	PostgreSQL: connection check, table sizes, active queries, and migrations with strict trust and approval.
npm-ops.json	Node.js lifecycle: trigger-chained install/test/build pipeline, security audit, and outdated checks.
git-ops.json	Git operations: status, log, diff, commit, and push with strict trust enforcement on push.
ssh-remote.json	SSH remote ops: uptime, disk, memory monitoring, service restart with approval, and log tailing.
sfdc-ops.json	Salesforce CLI: org status, SOQL queries, metadata listing, deployment validation with triage, and deploy with approval gate.
servicenow-ops.json	ServiceNow CLI: incidents, P1 monitoring with triage, change requests, problems, CMDB servers, and incident creation with approval.
vercel-ops.json	Vercel CLI: deployment listing, domain checks, preview→promote pipeline with approval gate, health verification, and env var audit.

For a step-by-step local walkthrough of the Stripe Identity example, see docs/guide-testing-stripe-identity-step-up.md.

Putting it together: a v0.2 manifest

The following excerpt from identity-v2.json shows the key v0.2 concepts in one manifest. Identity profiles define who the task runs as and how credentials are acquired. Evidence profiles define how execution is proven after the fact. Workflows and tasks reference these profiles by ID.

{
  "version": "0.2",
  "identity_profiles": [
    {
      "id": "env-token-agent",
      "provider": "env-bearer",
      "subject": {
        "kind": "service",
        "principal": "agent://local/env-service",
        "delegation_mode": "none"
      },
      "auth": {
        "mode": "service",
        "scopes": ["read"],
        "provider_config": {
          "token_env": "TEST_BEARER_TOKEN"
        }
      },
      "trust": { "level": "restricted" },
      "presentation": {
        "bindings": [
          {
            "source": "credentials.access_token.value",
            "target": { "kind": "env", "name": "API_TOKEN" },
            "redact": true
          }
        ],
        "cleanup": "always"
      }
    }
  ],
  "evidence_profiles": [
    {
      "id": "ssh-evidence",
      "provider": "ssh",
      "payload": {
        "bind": ["execution_id", "declared_identity", "contract", "command", "result"],
        "format": "canonical-json"
      }
    }
  ],
  "workflows": [
    {
      "id": "identity-demo",
      "name": "Identity Demo Workflow",
      "contract": {
        "sandbox": "permissive",
        "network": "unrestricted",
        "audit": "always",
        "required_trust_level": "restricted",
        "trust_enforcement": "advisory"
      },
      "tasks": [
        {
          "id": "env-token-task",
          "name": "Env Token Task",
          "shell": { "program": "echo", "args": ["token-test"] },
          "target": { "session_target": "shell" },
          "identity": { "ref": "env-token-agent" },
          "schedule": { "cron": "0 * * * *" }
        }
      ]
    }
  ]
}

The identity provider (env-bearer) resolves the bearer token from $TEST_BEARER_TOKEN at execution time, presents it as $API_TOKEN in the task environment, and ensures it is redacted in audit output. The evidence profile signs the execution payload with SSH keys for later verification. The contract requires at least restricted trust and enforces always audit.

Standards Alignment

agentcli's identity architecture is designed to compose with emerging agent identity standards rather than compete with them.

IETF AIMS (draft-klrc-aiagent-auth-00): The Agent Identity Management System defines a layered reference architecture for agent identity. agentcli's six-layer model (subject declaration, manifest authorization proof, credential acquisition, credential presentation, contract enforcement, evidence and audit) is independently aligned with AIMS.
SPIFFE/WIMSE: Identity profiles support URI-formatted principals (agent://, spiffe://) for interoperability with workload identity infrastructure.
OAuth 2.0: Auth modes map to standard OAuth grants. service maps to Client Credentials, delegated to Authorization Code, on-behalf-of to JWT Authorization Grant (RFC 7523), and exchange to Token Exchange (RFC 8693).

See docs/execution-identity.md for the full architecture document, including standards mapping tables.

Documentation

Document	Description
spec.md	Manifest specification
execution-identity.md	Execution identity architecture
protocol.md	JSON-RPC protocol specification
capabilities.md	Capability surface documentation
architecture.md	System architecture
versioning.md	Version strategy
conformance.md	Conformance requirements
adoption.md	Adoption guide
roadmap.md	Roadmap

Installation

# From npm (after publication)
npm install -g @amittell/agentcli
agentcli init
agentcli paths

# Local development
npm install
npm test

agentcli init creates a local home directory (default ~/.agentcli) with:

manifests/ -- manifest storage
output/ -- execution output
state/ -- runtime state
A starter manifest at ~/.agentcli/manifests/bot-health.json

Once initialized, you can refer to manifests by name instead of full path:

agentcli validate bot-health
agentcli compile bot-health --target openclaw-scheduler --explain

Pairing with the scheduler runtime

mkdir -p ~/.openclaw/scheduler
npm install --prefix ~/.openclaw/scheduler openclaw-scheduler@latest
npm exec --prefix ~/.openclaw/scheduler openclaw-scheduler -- setup

Then point inspection commands at the runtime state:

AGENTCLI_SCHEDULER_DB=~/.openclaw/scheduler/scheduler.db agentcli inspect jobs --fields id,name,last_status

Name		Name	Last commit message	Last commit date
Latest commit History 121 Commits
.github/workflows		.github/workflows
bin		bin
docs		docs
examples		examples
manifests		manifests
skills/manifest-authoring		skills/manifest-authoring
src		src
test		test
.gitignore		.gitignore
.npmignore		.npmignore
AGENTS.md		AGENTS.md
CHANGELOG.md		CHANGELOG.md
CODE_OF_CONDUCT.md		CODE_OF_CONDUCT.md
CONTEXT.md		CONTEXT.md
CONTRIBUTING.md		CONTRIBUTING.md
LICENSE		LICENSE
MANIFEST-QUICK-REF.md		MANIFEST-QUICK-REF.md
README.md		README.md
SECURITY.md		SECURITY.md
eslint.config.js		eslint.config.js
package-lock.json		package-lock.json
package.json		package.json

Folders and files

Latest commit

History

Repository files navigation

agentcli

Quick Start

agentcli on its own

agentcli with openclaw-scheduler

Better Together

Wrapping Existing CLI Tools

Dynamic credentials via command

Core Model

Execution Identity (v0.2)

Identity Providers

Authorization Proof Methods

Authorization Providers

Evidence Providers

Signing Providers

CLI Reference

General

Manifest Operations

Execution

Identity and Authorization

Inspection and Audit

Registry

JSON-RPC

Global Flags

Environment Variables

JSON-RPC

Compilation Targets

Migration from v0.1

Examples

Putting it together: a v0.2 manifest

Standards Alignment

Documentation

Installation

Pairing with the scheduler runtime

About

Resources

License

Code of conduct

Contributing

Security policy

Uh oh!

Stars

Watchers

Forks

Releases 2

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

`agentcli` on its own

`agentcli` with `openclaw-scheduler`

Dynamic credentials via `command`

Packages