Skip to main content

Integrations

Giving an agent access to an integration

Updated June 1, 2026 · 3 min read

Giving an agent access to an integration

Connecting an integration in Settings adds it to the available list for your workspace. The agent doesn't automatically get to use it. Per-agent tool toggles are the second half of the flow — and the part that keeps an agent's tool list small, focused, and effective.

Why per-agent toggles exist

An agent's behaviour is shaped by the tools it has. Give it Gmail and it'll think in terms of mail. Give it Jira and it'll think in terms of tickets. Give it twelve integrations at once and it spreads thin — every choice costs the model attention, and tool lists that try to cover everything tend to produce work that covers nothing well.

The pattern that lands: one agent, one job, the tools that job needs. Your Customer Reply Drafter agent needs Gmail and your support knowledge base; it doesn't need GitHub. Your Code Review agent needs GitHub and Linear; it doesn't need Gmail.

Where the toggle lives

Open the agent's settings (Agents page → click the agent → open the side panel). Inside the Tools & Access section there are two groupings:

  • Workspace. Tools that act inside Claos — search, create page, create task, comment.
  • External. Tools from connected integrations. Each integration is its own block, with the individual actions listed underneath.

Toggle a block on and every action inside the integration becomes available to the agent. Some integrations let you toggle individual actions if you want to grant read access but not write access; most are simpler than that.

The available list is dynamic — it reflects what's connected at the moment you open the builder. If you connect a new integration while the builder is open, refresh to see it.

What changes when you toggle on

The agent's tool list grows by however many actions the integration exposes. The agent doesn't get briefed about the integration unless you also update its instructions — if you want the agent to actually use the new tools, mention them in the prompt. "Read inbound mail to draft replies" is a real instruction; "you have access to Gmail" is not.

A common pattern when adding an integration to an existing agent:

  1. Toggle the integration on in Tools & Access.
  2. Edit Instructions to describe when and how to use it ("Each morning, read mail from the last 24h and summarise customer-flagged threads to the inbox").
  3. Run the agent once. Watch the run timeline to see whether it picked the right tool calls.
  4. Tighten the instructions if it didn't.

Choosing which integrations an agent gets

Some heuristics that keep tool lists small:

  • The same job repeated is a tool-list job — pick the tools the work needs, hold the line, leave the others off.
  • A new domain usually means a new agent, not adding more tools to an existing one. The Marketing Lead doesn't also need GitHub; build a new agent.
  • Read vs. write matters. If the agent only ever needs to read from a system, give it read tools only. Cuts the surface area for mistakes.

Tips and gotchas

  • Connecting in Settings is necessary but not sufficient. Agents only see integrations that are both connected and toggled on in their Tools & Access list. Forgetting the second step is the most common reason an agent "can't see" an integration.
  • The catalog agents inherit a sensible default tool set. When you start a custom agent from a catalog template, the template's tool toggles come along — adjust from there.
  • Removing a tool doesn't break old runs. Agent runs are snapshots of the agent's state at run time; toggling a tool off only affects future runs.

Was this article helpful?

Back to Integrations

Support

Still need help?

Can't find what you're looking for? Start a conversation and our support team will help.

Open your laptop.The work is already done.

Free to start. No credit card required.