Skip to main content
A Harnest release bundles three matching parts: the native CLI, the Python runtime wheel, and uv. The installer verifies the release checksum before it changes your machine. Harnest requires Python 3.11 or newer. New agents and the managed fallback runtime use Python 3.12.

​
Install

Verify the CLI and managed runtime:

​
Diagnose an agent

From your agent folder:
doctor detects the framework from config.yaml. It checks the existing runtime environment, or a development/eval environment if runtime has not been synchronized yet. It does not install or update dependencies. Run harnest env sync . to create or refresh the runtime environment, then retry. With no directory argument, doctor detects an agent in the current folder; otherwise it checks core packages only. --framework adk or --framework langgraph explicitly adds that framework’s checks. --python and HARNEST_PYTHON select an explicit interpreter for diagnosis, and the output shows which interpreter was checked. A missing framework in the shared core runtime does not mean it is missing from an agent’s isolated environment.

​
Installer properties

You run harnest; you do not activate the private runtime or call python -m harnest.cli.
If no Python 3.11 or newer is available, embedded uv installs a pinned CPython 3.12 under the Harnest data directory. It does not modify the system Python.

​
Upgrade

Run the installer again to replace the CLI and its matching managed runtime. Then upgrade each project separately:
The first upgrade is a read-only plan. Apply handles supported source and Python-version migrations, verifies the planned source hashes, and writes backups before changing project files.

​
Compatibility

Each Harnest release declares the ADK and LangGraph versions it supports. Authored dependencies live in the project’s pyproject.toml; environment sync resolves them with the Harnest release, selected framework, extensions, task runtime, and all transitives. Production runtime, development, and eval profiles have separate hash-verified locks so compiled deployment artifacts exclude pytest, evaluation, and unused MCP packages.

​
Publish a release

Release publishing is a maintainer workflow:
1

Run the complete gate

2

Prepare release notes and version metadata

Keep the native CLI, embedded wheel, and compatibility metadata on the same version.
3

Tag the release

The release workflow builds the supported macOS and Linux archives, creates checksums.txt, and publishes the artifacts.
4

Verify a clean install

Test the public installer and run harnest doctor on at least one supported platform.
Do not publish a CLI with a wheel from another version. The executable rejects mismatched embedded metadata.