Add supervision without changing your runtime

Keep your runtime and framework

Toolcaise does not run your agent or replace your framework. The agent stays where it is, in a container, a worker queue, a scheduled job or a developer’s laptop, and reports what it does over outbound HTTPS. There is nothing to host, no inbound port to open and no model-provider key to hand over.

Pick the path that fits the code

• Python or Node.js SDK: runs, spans, model calls through an instrumented client, outcomes, checkpoints and approvals.
• OpenTelemetry: point the exporter your framework already has at Toolcaise with three environment variables. It observes only.
• HTTP contract: for any runtime that can make an HTTPS request, described in the OpenAPI document the API is tested against.
• Toolcaise Connect: wrap a command to meter every model call on the machine and enforce cost, token, call and runtime limits, or put its gateway in front of an MCP server.

Debugging a bad result

The worker finished and the output is wrong. With spans around retrieval, model calls and tools, you can see which step produced the bad input, what each model call consumed and whether a retry quietly changed the result. That is usually enough to find the cause without reproducing the run.

Controls that fail safe

Reporting is fire-and-forget: if Toolcaise is down, your agent keeps running and reports catch up later. Controls work the other way. A guarded action or checkpoint that cannot confirm a decision raises instead of proceeding, so an outage never turns into an unapproved action.

Test the failure paths before production

Trigger a controlled failure in a test environment: kill the process mid-run, return an empty result, hit a cost limit on purpose, deny an approval. Confirm each one shows up the way the person on call will need to see it. The pilot checklist walks through these one at a time.