Skip to main content
A project-local Harnest Extension is discovered from extensions/<name>/extension.yaml. You do not add it to a central registry or manually attach it to the root agent. After compilation, Harnest exposes the extension module as harnest.extensions.<name>. Import the singleton from a discovered Agent Tool and call its bounded API:
tools/query_warehouse.py
The call runs inside a managed invocation, so warehouse.context resolves the typed WarehouseContext created for that request. Retaining it after the invocation ends fails closed.

Resolve the typed context explicitly

Trusted application code can ask Harnest for the same invocation-scoped view:
lib/warehouse_service.py
Keep application clients and connection pools private on the singleton. Expose domain operations through the typed context instead of returning the raw SDK object.

Find published extensions

Search public PyPI for compatible harnest-extension-* packages:
Search verifies package naming, one harnest.extensions entry point, the bundled extension.yaml and extension.py, release identity, and the published wheel digest without importing package code. official means Fused controls and explicitly recognizes that package name; community means only that the wheel satisfies the structural contract. Neither label is a security review.
Search does not install an extension. The current compiler discovers Harnest Extensions from the project-local extensions/<name>/ folder. Merely adding or installing a PyPI package does not register its entry point as a project extension. Obtain and review the publisher’s source bundle, place it under the local extensions/ directory, then run harnest env sync before compiling.

Create your own extension

Define the local manifest, singleton, typed context, and dependencies.

Use extension lifecycle

Add only the hooks and factories declared by the manifest.