Use Rivet with Sazabi: inspect live actors from an investigation

Last verified on Nov 8, 2026.

An actor is a small stateful process with its own queue, connections and, sometimes, its own database. When one misbehaves, the logs tell you that a request failed. They rarely tell you what that specific actor was holding when it did. That lives in the actor, and to see it you normally open the dashboard and click through.

Sazabi is AI-native observability and security. With Rivet connected, the Sazabi agent can look inside the actor from the same thread where it is reading your service logs, so the log line and the actor's state get read together.

What the Sazabi agent can do with Rivet

The Rivet connector page lists what the agent can do once you authorize with OAuth:

• List and inspect running actors, their lifecycles and statuses.
• Execute actor actions and query actor history.
• Inspect actor state, connections, queues, workflows and database tables.
• Manage Rivet compute pools and runners.
• Monitor compute metrics and server performance.

Rivet's own server exposes this through just two tools. search looks at the namespace you connected and returns only the operations that fit the request, such as rivet.actors.list or rivet.actor.action. execute writes and runs one piece of JavaScript that combines those operations and returns a single answer. Rivet says that code runs with no network, files, environment variables or way to start a process, and that every call is checked against the access you approved.

The Actor Inspector is the dashboard's actor view with State, Connections, Queue, Workflow and Database tabs. It opens for one actor you name, and clients that cannot render it get the same details as text.

Questions it answers

• Which actors with a given name are running right now, and which have stopped?
• What does this one actor's state hold, and what is in its queue?
• Which connections are open to a specific actor?
• What does an action return for this actor key?
• Are the compute pools and runners healthy, and what do the compute metrics show?

A worked example: one stuck session

Say a support ticket reports that one customer's cart is frozen, and your API logs show repeated timeouts for the same session key. In a thread you ask:

Using Rivet, list the running cart-session actors and find the one with
key sess-4821. Show its queue and connections, and call its getStatus
action. Then find the matching timeouts in the API logs.

The agent uses search to find rivet.actors.list, filters on the actor name and checks the status of the one keyed sess-4821. It then calls rivet.actor.action with the action name getStatus. That action is one your own actor defines, since Rivet's docs use getHistory on a chat-room actor as an illustration of the pattern. For queue and connection details it opens the Actor Inspector for that actor alone.

The agent's answer is a comparison. The queue length and open connections are read from Rivet, and the timeouts come from your logs. If the queue is backed up while the actor sits in a running state, you have a place to look.

Scoping access

By default the connector points at https://mcp.rivet.dev/mcp. Add organization, project and namespace query parameters to the server URL to limit it, using the slugs in your dashboard URL (/orgs/ORG/projects/PROJECT/ns/NS). Rivet also states that a hosted connection's grant expires after 15 minutes. For debugging, point it at the production namespace and turn on Sazabi's read-only toggle so actions that change state stay off.

How it fits with other integrations

Rivet covers state inside the running system, and your logs cover what the system said. If actors run alongside durable workflows, see the durable execution category. Logs from a cloud host come in through AWS or Cloudflare, and the full catalog is under integrations. Sazabi plans are on the pricing page.