ToolingOAuth + permissions

Integrations

Integrations let agents do real work: read context, send messages, create events, update systems, and report what happened. Treat them like production permissions, not decorative features.

Connect first

Users connect accounts from the dashboard before an agent can call the tool.

Scope narrowly

Grant only the actions the bot actually needs. Fewer permissions make the bot safer and easier to debug.

Approve risky actions

Mutations like sending email, creating events, or writing records should use approval policies when needed.

Inspect traces

Every tool call should leave validated arguments, result status, latency, and a useful failure reason.

Available standard integrations

These integrations can be connected from the dashboard and referenced by agents when permissions allow it. The exact action list can vary by workspace configuration.

How agents receive tools

A connected account does not automatically mean every bot can do everything. The runtime should check the workspace, the bot grant, the user authorization boundary, and the action risk before executing a tool.

bot RecruitingAssistant {
  integrations {
    gmail.read
    calendar.create_event
  }

  instructions {
    Help the user coordinate interviews.
    Ask before sending email or creating calendar events.
  }
}

Private integrations

Teams can also create private integrations for internal APIs. Start with a small contract: validated inputs, explicit timeout, retry policy, permission requirement, normalized result, and redacted logs.

Good first private integration

“Look up a customer by email” is safer and easier to validate than “access the whole CRM.” Expand the action list only after the agent proves it can use the first action reliably.

Next reads

How helpful was this page?

Not helpfulExcellent