Connections
A connection links your organization to an outside service once, so every agent that needs it can use it. Agents don't hold their own GitHub or Slack credentials — the organization does.
Who can do what
| Task | User | Agent owner | Admin |
|---|---|---|---|
| Use a tool backed by a connection | ✅ shared in | ✅ | ✅ |
| Connect or disconnect a service | — | — | ✅ |
| View connection details | — | — | ✅ |
| Give one agent its own Slack identity | — as Editor | ✅ | ✅ |
Organization → Integrations.
What can be connected
| Service | Gives agents |
|---|---|
| GitHub | Browse repositories, clone, commit, push, open pull requests |
| Slack | Send messages and files, list channels and users, and be mentioned in channels — see Slack |
| Google Workspace Admin | List, search, create, and update users in your Workspace domain |
| DocWorker | Build document knowledge bases and search them semantically |
Email appears in the same area marked Coming Soon and can't be configured
yet. Agents can already send mail without it — the built-in email tool is how
an agent asks you a question or reports progress mid-task, and it needs no
connection. See Tools.
Connecting
Most connections are OAuth: choose the service, authorize on its site, and you're returned to Delegate with the connection recorded. Credentials are encrypted at rest and never shown back to you or to an agent.
DocWorker is different — it takes an API key and a company ID, which you enter directly along with a connection name.
Disconnecting
Disconnecting asks a question worth reading:
- Yes, revoke all access — also tells the provider to revoke the token. Delegate's access ends everywhere, immediately. This is what you want if a credential may be compromised, or you're ending the relationship.
- No, just disconnect locally — Delegate forgets the connection but the provider-side authorization remains. Use this when you're reconnecting straight away or moving to a different account, and don't want to disturb other integrations sharing that authorization.
If you're unsure, revoke. Reconnecting is a minute's work.
Connections and agent tools
Connecting a service doesn't give any agent access to it. It makes access available; you still add the relevant tool or bundle to each agent. Two steps, deliberately: connecting is an organization decision, attaching is a per-agent one.
So a common confusion — "I connected GitHub but the agent says it can't" — is nearly always a missing tool on the agent, not a broken connection.
Scope is worth thinking about
A connection is organization-wide. Any agent given the matching tool acts with that access, and anyone the agent is shared with can ask it to. Connect an account whose reach matches what you're comfortable with every agent-user being able to trigger — a service account scoped to the repositories that matter, rather than an administrator's personal account.
Your own services
To connect something not listed here, register a custom tool — your own HTTP endpoint or MCP server.