Skip to main content
The harness command group creates an agent without writing any application code: initialize a harness.yaml, set its fields, then deploy it directly as a runtime.

harness init

Create a harness directory (harness.yaml + .env.example) for a Harness.
harness.yaml is the single source of configuration for a code-free agent; harness deploy expands it into the runtime’s environment variables. In the generated file, common fields are active and each component’s optional params are shown commented-out, grouped by backend — set a component’s type, then uncomment the params under that backend. The complete file looks like this:
harness.yaml
Field reference:
  • harness_name: the harness and runtime name, also used as the knowledge-base and long-term-memory index name (env HARNESS_NAME, flag --name).
  • cloud: deployment cloud provider and region written by harness init; provider is volcengine or byteplus.
  • cloud.network (optional): Runtime networking. enable_public_network controls public ingress, enable_private_network enables private VPC networking, vpc_id, subnet_ids, and security_group_ids select private network resources, and enable_shared_internet_access controls shared internet egress from the private network. VPC and subnet IDs are required when private networking is enabled.
  • model.name: the reasoning model (env MODEL_NAME, flag --model-name).
  • model.credential_mode (optional): set to obo_broker for a shared OAuth Harness with managed model egress. This mode requires auth and the fields model.provider, model.api_base, model.target_alias, model.target_audience, model.workload_discovery_url, and model.workload_issuer; do not set a model API key in this mode.
  • capacity (optional): Runtime resources, concurrency, and model-admission settings. Supported fields are cpu_milli, memory_mb, min_instance, max_instance, max_concurrency, model_max_inflight, model_max_inflight_per_user, model_queue_timeout_seconds, model_request_timeout_seconds, model_max_output_tokens, session_db_pool_size, session_db_max_overflow, session_db_pool_timeout_seconds, and session_db_pool_recycle_seconds.
  • tools: built-in tool names (env TOOLS, flag --tools).
  • skills: Skill Hub slugs, spaces, or space:skill references (env SKILLS, flag --skills).
  • system_prompt: the agent instruction; empty uses the server default (env SYSTEM_PROMPT, flag --system-prompt).
  • description: agent description used for discovery and generated AgentCards (env DESCRIPTION, flag --description).
  • runtime: the agent runtime backend, adk (default) or codex (env RUNTIME, flag --runtime).
  • max_llm_calls: default maximum LLM calls per run; agentkit harness invoke --max-llm-calls can override it for one request.
  • structured_tool_calls / include_tools_every_turn: control the tool-call format and whether tool definitions are sent on every model turn.
  • sidecar (optional): managed Harness Sidecar configuration. profile selects the component profile, and component_overrides controls components such as context_engine, compressor, verifier, long_run_control, and mcp_resilience.
  • registry: optional A2A registry. space_id selects a space, top_k limits AgentCard retrieval, and endpoint plus region locate the service.
  • knowledgebase: a knowledge base. An empty type disables it; supported backends are viking, opensearch, redis — set type, then uncomment that backend’s connection params.
  • long_term_memory: long-term memory. An empty type disables it; supported backends are viking, opensearch, redis, mem0.
  • short_term_memory: the session store. type is local (default), sqlite, mysql, or postgresql.
  • auth (optional): omit it to use the default API-key auth (key_auth); set discovery_url and allowed_ids to switch to OAuth2/JWT (custom_jwt), where the gateway only accepts tokens issued by that user pool whose audience is on the allow-list.
The following fields are edited directly in harness.yaml; harness set does not currently generate them.
harness deploy and harness dev load the project .env and resolve ${VAR} in harness.yaml; existing shell environment values take precedence. Use variable references for database passwords and other secrets, and exclude .env from version control. .env.example contains optional cloud credential placeholders; configure models, components, networking, and capacity in harness.yaml

harness set

Set fields in harness.yaml (partial update; only the flags you pass are changed). Run with no flags to list the current fields. Fields fall into groups: core (model / tools / skills / prompt / runtime), knowledgebase, long-term-memory, short-term-memory, and auth. When configuring a component, set its --<comp>-type first, then its connection parameters.
Only the flags you pass are changed. To configure a component, set its --<comp>-type first, then supply its connection parameters.

harness dev

Start the Harness service locally from harness.yaml for development and debugging. By default, it listens on 127.0.0.1:8000. Set a different host explicitly if other devices need to access it. Prepare Python 3 and the Harness server dependencies first. Startup output identifies the dependency file; if modules are missing, install that file with the same --python interpreter and retry. This command does not create a Python environment or install dependencies. Restart after editing harness.yaml; --reload watches server code A local listener does not make calls offline: models, MCP services, knowledge bases, and remote databases still require their own credentials and network access and may incur charges

harness deploy

Build the harness image and create or update the runtime from harness.yaml.
Deployment requires control-plane credentials for the selected provider. It builds an image and creates or updates a cloud Runtime, which may incur charges and change production behavior. Verify model availability, component connections, region, and project first. Replace your-model-name in examples with a model or endpoint ID available to your account
When auth is configured, deployment creates a custom_jwt Runtime. After deployment, publish the returned Runtime ID and HTTPS endpoint in shared_harnesses on the tenant login discovery document; users can then access it with agentkit chat <alias>.

harness invoke

Invoke a deployed Harness and optionally override its model, system prompt, tools, skills, runtime backend, or A2A registry for this request. Overrides affect only the current request and do not modify harness.yaml.
For a Harness protected by custom_jwt, pass a bearer token explicitly with --token, or first run agentkit login --identity-only <sso-address> to save the OIDC session. The CLI forwards the cached id_token only when the Runtime endpoint uses HTTPS, the Runtime discovery URL matches the active login issuer, and the active OAuth client ID is in the allowed list.

harness sidecar catalog

Print the Harness Sidecar Product Component Catalog. This command only prints JSON and does not create or modify cloud resources. Use it from Studio, CI, or scripts to show selectable components, availability, and the default selection for a profile.
The output includes schema_version, catalog_version, profiles, selected_profile, components, total_component_count, and selectable_component_count. components[].selected_by_profile indicates whether the current profile selects the component by default, and components[].availability.available indicates whether the current Runtime contract can use it.

harness sidecar resolve

Resolve a profile and component switches into a deterministic Harness Sidecar plan. This command only prints the JSON plan. It exits non-zero when the plan is invalid, which makes it suitable for validating harness_sidecar.component_overrides before release.
In the output, effective_components is the final enabled component list, activation_targets describes whether runtime components, the model proxy, and the MCP gateway are enabled, warnings lists valid selections that need attention, and plan_hash is used after release to verify the plan loaded by the runtime. mcp_resilience automatically includes SQL read-only protection; sql_readonly cannot be selected directly with --component. When you use the ops profile but disable mcp_resilience, the plan warns that SQL read-only protection is disabled.

Remote MCP servers

Configure mcp_servers in harness.yaml to use remote MCP services alongside built-in tools. harness init and harness set save configuration; harness dev and harness deploy load it, while harness invoke can override it for a single request
harness.yaml
Set MCP_API_KEY in the project .env and exclude that file from version control. init and set preserve placeholders; deployment, local execution, and invocation resolve them. Command-line MCP servers replace the entire list from the invocation config. An empty list cannot be combined with another --mcp-server. Omitted MCP settings inherit the deployment; an explicit empty list removes remote MCP servers while keeping built-in tools Shared OAuth Harnesses accept only mcp_servers as Harness overrides and reject other override fields

Invocation configuration file

Use --config for reusable invocation settings. Command-line values take precedence over the file. Fields from the file are sent for this request, and omitted agent settings follow the target runtime defaults. The file does not modify harness.yaml or redeploy the runtime
invoke.yaml
Model, tools, skills, system prompt, and runtime settings may also appear at the top level, where they override nested fields. model.name can supply the model name. Environment expansion is supported for MCP credentials; do not assume arbitrary invocation fields expand placeholders. Prefer login sessions or supported default credential sources

Scheduled tasks

With cronjob enabled, use harness cronjob to create recurring or one-time invocations, inspect results, and pause, resume, or cancel work. See Harness scheduled tasks for configuration, options, and limitations

Verification and session storage

After deployment, run agentkit runtime show my-harness to check the active version, then invoke it with agentkit harness invoke my-harness "hello". Runtime readiness alone does not verify model credentials, MCP services, or databases. Inspect agentkit runtime logs my-harness --limit 200 if invocation fails In-memory sessions disappear when the process ends; SQLite sessions depend on one instance’s files. Before scaling a shared OAuth Harness across replicas, configure MySQL or PostgreSQL short-term memory and reachable private networking. See Harness Sidecar for managed Sidecar region, capacity, and authentication limits
Last modified on September 19, 2026