Skip to main content
A Runtime Plugin adapts an SDK or external service to Harnest. It runs in the agent process and can contribute declared lifecycle, context, storage, HTTP, and content capabilities.
Runtime Plugins have plugin.yaml. Manifest-less plugin folders are Agent Plugins: MCP clients plus Agent Skills, with no Python plugin object or lifecycle.

Choose the boundary

Create a plugin

The plugin project name and version must match plugin.yaml. Dependencies are static PEP 621 entries. Use requires.plugins to name local Runtime Plugin dependencies. Harnest rejects missing dependencies and cycles at compile time.
Plugins share the root interpreter, event loop, dependency solve, and lock. Conflicting SDK constraints fail environment synchronization; Harnest does not create plugin-private environments.

Use the plugin

Import the singleton from its compiler-owned namespace:
Inside an invocation, the same typed view is available through:
Plugin context is invocation-scoped and revoked after the call. Keep application clients on the plugin singleton; expose only bounded operations through its context.

Declare capabilities

Declare only what the plugin contributes. Advanced mode composes Harnest-owned boundaries but does not intercept opaque native framework paths.

Lifecycle and auditing

  • Dependencies start before dependants; shutdown reverses that order.
  • Within a lifecycle phase, lower order values run first.
  • Plugin and root extensions form one globally validated lifecycle.
  • Wrap committed user- or agent-triggered writes with plugin_mutation(...) to emit correlated, payload-free OTEL audit events.
Inside a plugin method:
For external work that must survive a replica stopping, declare context.continuations and follow Durable execution.