Runs and traces
Every invocation has a run correlation id. Whether Agntz persists a Run (the top-level execution record), a Trace (the span tree below it), or a session is controlled by the runtime store in embedded mode and the explicit retention policy in hosted mode.
A trace's spans cover three kinds of work:
agent.invokeorrun— the root span for an agent run.model.callormodel— each LLM API call.tool.executeortool— each tool execution.
Spans nest. A sequential pipeline's trace looks like:
Listing and inspecting
The resource shape is intentionally similar across local and hosted clients. TypeScript uses camelCase option names; Python uses snake_case.
Live trace streams
The hosted Python client streams worker SSE events. The local Python SDK currently exposes trace snapshots rather than token-level span updates.
Storage
Embedded
Runs and traces live in memory by default. For durable storage, use SQLite:
The same store backs sessions, messages, runs, and trace spans.
Hosted
Hosted persistence is tenant-scoped and retention-aware:
| Mode | Durable result | Session messages | Complete trace |
|---|---|---|---|
none | No | No | No |
result | Redacted result record | No | No |
session | Yes | Yes | Yes |
ttlSeconds controls record expiry where supported. artifactTtlSeconds controls managed media separately, so deleting a run never implicitly extends an artifact's lifetime. See Content, artifacts, and retention.
OpenTelemetry
TypeScript embedded runs can pipe spans into an existing observability stack:
Python local trace spans are stored through the configured Agntz store in this first package slice. OpenTelemetry export can be added on top of that store protocol later.
Cancellation
Hosted and TypeScript long-running runs are cancellable:
Cancellation is best-effort: in-flight model calls finish, but no further steps execute and cancellation propagates through nested pipelines.