Skip to content
RULITH DOCS
Browse documentation

Agents and Workers

One Rulith installation can manage several Agents. Each Agent keeps its own identity, conversation history, model settings, Worker configuration and working files.

Local workbench and Console

In Rulith on your computerIn Console
Select an Agent and converseCreate, enable or disable Agents
Configure local model defaults and overridesInstall capabilities and review active configuration
Start and stop Agent and Worker rolesManage Connections and Source bindings
Attach files and inspect local activityInspect Cases, evidence and terminal receipts
Review a checked local draftEdit, publish and install Releases

Selecting another Agent does not stop one that is running. A shared installation does not merge their Connections, credentials, tool permissions or working directories.

Models

Set Default model from the account menu once. Select Model settings in an Agent's gear menu to use that default or save an override.

Changing the default affects inheriting Agents the next time they start. Stop an Agent before changing its override. Its Worker can be controlled independently, but a model destination change may also require restarting the Worker before using new attachments; follow the message in the workspace.

Provider default leaves the thinking setting to the model service. Off and On request explicit settings where supported. A truncated or empty model reply is a failure to resolve, not a successful tool call.

A blank API-key field keeps a saved key only for the same service. Changing providers requires the new provider's key or an explicit key removal for a service that needs none. Saved keys are not displayed back to the page.

Agent directory and conversations

The workbench checks the account's enabled Agents periodically. Refresh enabled Agents requests a check immediately. An unavailable network preserves the last received list and reports the sync problem.

Disabling an Agent removes its permission to run and asks its local roles to stop. Local profiles and conversation history are retained. Deleting an Agent is a separate Console operation.

Conversations opens your saved local history. Starting a new conversation does not close a Case. Archiving a conversation preserves its messages and is also separate from Case closure. Export view exports the currently loaded view, not a complete Board proof or a backup of local material.

Connections and replacement keys

Connections belong to an Agent. A Worker Connection authenticates the runtime that claims work; a Sensor Connection authenticates an observation producer. Start from the selected Agent's Runtime page in Console.

Use Replace when you need a new Connection key. The previous key becomes invalid. Stop the affected Worker, open Replace Connection key in its local settings, save the replacement for that same Agent and Connection, then restart it.

Replacing a Worker key does not replace the Agent's MCP token or the model API key. Keep those credentials separate. All connections provides the account-wide inventory.

Use an existing MCP client

Your MCP client can run the model while a Rulith Worker runs tools on your computer or inside your data environment.

  1. Create or select an Agent in Console.
  2. Obtain that Agent's MCP setup details from its Runtime page.
  3. Configure the client to use https://api.rulith.ai/mcp with the Agent token as a Bearer credential.
  4. Prepare a Worker for that Agent, configure the required Sources and Tools, and start it.
  5. Let the client discover the current tools through MCP. See the protocol reference.

The account's device sign-in credential is for local management. Never use it as the MCP token, a Worker key or a model key. Avoid running two clients with the same Agent token.

For headless environments, follow the runtime setup reference for explicit role selection, configuration and the tool manifest. The interactive workbench is the recommended first run.

Sign out

Sign out and stop this computer stops managed roles, confirms device revocation and clears the credentials issued to that device. If stopping or revocation is incomplete, the UI reports it and retains the request for retry.

Model settings, user files and local history remain. Revoking a device remotely blocks its credentials; it cannot undo an external effect that already happened.