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: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.
Complete lifecycle configuration
Complete lifecycle configuration
lifecycle/telemetry.py
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
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: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.