Skip to main content

Project-owned top-level runs

Create one SovaraClient for a stable project name. Use one top-level run for one user request, conversation turn, eval sample, batch job, or other execution you want to inspect.
The client ensures the exec server is reachable, registers the run, executes the callback in an AsyncLocalStorage scope, and finalizes the run in finally. For a durable conversation or job, pass an application-owned correlation ID. Reusing it within the same project appends to the canonical Sovara run.
Keep prompts and secrets out of clientRunId.

Steps and explicit tracing

Supported provider, framework tool, and MCP calls inside a run become ordered steps. Wrap an important uncaptured application boundary with trace:
Prefer shared tool or dispatch chokepoints. A trace filled with miscellaneous helper calls is harder to understand than one that exposes agent decisions and actions.

Subruns

Use sovara_client.subrun(...) for child agents, delegated branches, parallel work, and coherent multi-step phases:
Nested top-level runs are ignored with a warning. Use a subrun when child work should appear in the run tree.

Run metadata

Metrics accept booleans, integers, and finite numbers.

Lessons

Automatic lesson injection is project-wide by default for supported model calls. Narrow retrieval with the run’s lessonScope option:
Temporarily replace the active scope with sovara_client.lessonScope(...). Use sovara_client.injectLessons(...) only when the application must place the managed lesson block itself.

Logs and concurrency

Log capture is enabled by default. Pass { captureLogs: false } as the third argument to run() for concurrent top-level runs to avoid mixing process output.

Inspect the result

Use the API reference for exact signatures.