Skip to main content
Use harnest-threadify to connect Harnest sessions to Threadify threads. The package is optional: Harnest does not install, import, or connect to Threadify unless you configure it.
This integration is unreleased and requires the upcoming Harnest 0.23 lifecycle hooks. Its source is in packages/harnest-threadify in the Harnest repository; it has not been published to PyPI yet. The native SDK dependency is threadify-sdk==0.2.10.

Configure the agent

For development from the Harnest checkout, install into the environment running that checkout:
Copy the following into your existing agent’s lifecycle/telemetry.py. Keep its session storage configuration. Change service_name to a stable application/environment identity and select your business tools and attribute names.
lifecycle/telemetry.py
Provide THREADIFY_API_KEY through the server environment or deployment secret store, then start the agent. Compilation never reads the key or opens a connection.

Business data only

ADK and LangGraph use the same filter. Exact attribute names are required; attribute wildcards are rejected. Strings are limited to 256 characters by default. Framework payload namespaces such as gen_ai.*, llm.*, and exception.* stay excluded even if named in the attribute allowlist. Other telemetry destinations receive their original spans. Use static business-step names and deliberately select non-sensitive attribute values:

Session ownership

A committed Harnest session creates or recovers a Threadify thread. Agent invocations also recover links for sessions that predate the integration. sessionId is recorded as a Threadify reference; lookup uses a hash of the application identity, authenticated user, and session ID, so equal session IDs from different users do not share a thread. HTTP scopes cover the full streamed response and unwind on cancellation. Agent hooks also correlate supported non-HTTP invocations. Native framework session endpoints that bypass Harnest’s session creation boundary are linked when the agent is first invoked. Request completion does not complete the Threadify thread: subsequent turns reuse it. Concurrent creation is serialized within one integration instance. Existing threads are recovered by reference after restart. A failed lookup never causes a replacement creation, and an ambiguous start is not retried in the same instance unless lookup finds its thread. Threadify’s SDK does not expose atomic creation by reference; route a session to one worker and avoid overlapping workers during creation. This integration does not claim distributed exactly-once creation or recovery across an eventually consistent lookup immediately after a crash. The default capacity is 10,000 linked or unresolved sessions per instance. At capacity, new links are skipped rather than evicting live ownership. Missing credentials fail startup; remote connection/link failures log a fixed message and let the agent continue. A failed startup connection remains disabled until restart. Shutdown flushes spans while the SDK event loop is still running, then closes the connection. Export is best effort and is not a durable audit ledger.

Native SDK access

Use native async operations on the application’s event loop. Native SDK operations are explicit application actions and bypass the telemetry filter. Completing a native thread ends that business workflow; the integration does not automatically start a replacement for the same session.

OTLP/HTTP Protobuf

The default transport uses Threadify’s native SDK. If your deployment supplies a standard OTLP/HTTP traces endpoint, select it when constructing the class:
Import os in that module. Use your deployment’s exact URL and authentication header format; the bearer header above is an example. The SDK still owns session thread creation and native access. The same business filter runs before Protobuf serialization, and exported spans carry threadify.thread_id and the session reference. Your receiver must honor that thread mapping. No Threadify OTLP endpoint is assumed or discovered automatically.