Turning Agents & Tools On/Off

Agents and individual tools can be toggled on or off at each tier of the access control hierarchy. This page covers where to find those settings, how toggling affects the planner, and how Thallus caches availability for performance.

Toggling agents

Administrators can enable or disable entire agents. When an agent is disabled, it disappears from the planner's available agents list — queries that would normally use that agent will be routed to other agents or the planner will report that it can't complete that part of the request.

Agent Settings
web_research
Internet search and extraction
data_analyzer
Business intelligence analytics
slack
Channels, messages, search
slack_send_message
slack_list_channels
slack_search

In this example, the Slack agent is enabled but its slack_send_message tool is disabled — the agent can read messages but not send them.

Toggling individual tools

You can enable or disable specific tools within an agent without turning off the entire agent. This is useful when you want an agent's capabilities but need to restrict certain actions:

  • Read but not write — Enable Slack but disable slack_send_message
  • Query but not modify — Enable Jira but disable jira_create_issue
  • Browse but not send — Enable Google but disable google_send_email

Tool toggles follow the same 4-tier hierarchy as agent toggles, plus an additional User Preference tier that lets individual users opt out of specific tools without needing an admin.

Some tools also have a confirmation setting — even when enabled, they'll ask for approval before executing. See Tool Confirmations for details.

Where to configure settings

Settings are managed through the admin interface at each tier:

Tier Location Who can access
Platform Platform Admin → Agent Settings Superadmins only
Organization Org Settings → Agent Settings Org admins and superadmins
Group Org Settings → Groups → [Group] → Agent Settings Org admins and superadmins
User Override Org Settings → Members → [User] → Agent Settings Org admins and superadmins
User Preference Personal Settings → Agent Preferences The user themselves

Availability states

An agent's availability depends on more than just access control settings. Thallus tracks several states:

web_research
Available
jira
Requires connection
data_router
Blocked by admin
data_explorer
No data connections

The four availability states:

State Meaning How to resolve
Available Agent is enabled and all requirements are met Ready to use
Requires connection Integration agent needs an OAuth connection Connect the integration
Blocked by admin An access control setting denies this agent Ask your org admin to change the setting
No data connections Data agent needs at least one data connection in the org Add a database connection in Settings

Integration agents (Google, Slack, Jira, etc.) automatically become unavailable when their OAuth connection is disconnected, and available again when reconnected. Data agents (data_explorer, data_router, data_analyzer) require at least one active data connection in the organization.

Availability caching

Checking agent availability involves querying access control settings, OAuth connections, and data connections. To avoid doing this on every request, Thallus caches availability results per user and organization.

The cache is automatically invalidated when relevant state changes:

Integration connected
→
Cache cleared
→
Agent now available

Events that trigger cache invalidation:

  • Integration connected — An OAuth connection is established
  • Integration disconnected — An OAuth connection is removed
  • Data connection created — A new database connection is added to the org
  • Data connection deleted — A database connection is removed from the org

Admin settings changes (toggling agents at any tier) also invalidate the relevant cache entries, so changes take effect immediately.

Effect on planning

When the planner builds an execution plan, it only sees agents that are both allowed and available for the current user. Disabled or unavailable agents are simply not in the list, so:

  • The planner never assigns work to an agent the user can't access
  • If a query needs an unavailable agent, the planner either routes to an alternative or reports the limitation
  • Re-enabling an agent or connecting an integration makes it immediately available for the next query (after cache invalidation)

Next steps