tamag0
FR
Documentation

Integrations

View Markdown llms.txt llms-full.txt

Companions act where the company already works — Slack, email, calendar, issue trackers, code — and anything else through MCP.

Built-in integrations

  • Slack: companions are reachable teammates — they read channels, reply in threads, react, upload files, open DMs. An incoming Slack message routes to the right companion, and the answer goes back to the originating thread.
  • Google — Gmail, Calendar and Drive: one click from the desktop app, no Google Cloud setup (see Google below).
  • Jira: fetch, search (JQL), create, update, and transition issues.
  • GitHub: follow pull requests and CI runs (the watchdog wakes a companion when a check completes or a PR merges), and react to repository events. GitHub access works through your machine's local gh CLI — there is no separate connection to set up beyond a one-time gh auth login (see Best practices).
  • Sentry: production errors become work items a companion can pick up and fix.

Google: Gmail, Calendar and Drive

Connect a Google account from the card a companion shows in a conversation when it needs one, or from Settings → Integrations in the desktop app. Google's own consent page opens in your browser; there is no Google Cloud project to create and no client ID or secret to paste.

  • What the companion can do: Gmail — search, read, send and reply; Google Calendar — list, create, update and cancel events; Google Drive — search, list and read files (read-only: Docs and Slides as text, Sheets as CSV).
  • Sensitive actions ask first: sending or replying to an email and changing a calendar event ask for your consent in a conversation you are taking part in, and are refused in a run where nobody can answer — unless you allowed them for that conversation or turned off permission prompts. Reading never asks.
  • What Google grants is what you get: Google's page lets you untick a service. The card then shows which services are granted and which are not; reconnect and tick the missing one to grant it.
  • One companion, one work context: a connection belongs to the companion you connected and to the context you connected it in — home, or one client context. A client context is connected from a conversation of that client; Settings connects the home context and lists every client context that holds a connection, including clients the companion no longer works for. A connection is never used anywhere else, and the same companion can use a home account and a client account at the same time.
  • It stays on your computer: the authorization is kept on the desktop, in your operating system's secret store (macOS Keychain, Windows credential protection, GNOME Keyring or KWallet on Linux), and Google is called from your computer. Without such a store the desktop refuses to connect — on Linux, see Linux keyring.
  • Disconnect removes it from one context only: disconnecting removes the connection for that companion in that context; other companions and contexts keep theirs. Your Google account keeps the authorization it gave tamag0 until you remove it from your Google account's connected apps, which removes it everywhere at once.
  • When Google withdraws the access (password change, revocation from your account, expiry), the card says the access was cut and offers Reconnect; other contexts are unaffected.
  • Earlier setup with your own Google Cloud credentials: companions connected that way keep working. Settings shows that configuration read-only — it can no longer be created or changed there — and a companion that has one can also connect Google the new way.

Email intelligence

Beyond raw email access, companions track business email: senders are classified automatically, threads needing a response are tracked and reminded, newsletter knowledge is extracted, and emails are mapped to the right project domain by pattern — so "waiting on a reply about the Acme contract" is something your companion knows.

Events and routing

External events (Slack, GitHub, Sentry, email) flow into a prioritized queue with per-company routing rules deciding which companion handles what — urgent events first, retries handled automatically.

Extensible through MCP

Any Model Context Protocol server adds new tools to a companion:

  • Third-party or in-house servers, over stdio, HTTP, or SSE — OAuth-based authentication supported.
  • Scoped sharing: an MCP server can be kept for one companion ("Only me"), shared with your personal agents of the same workspace on this computer ("Personal agents"), or added to the company's list ("Workspace"): a company admin publishes it directly, anyone else proposes it and an admin accepts it in the admin back office. Every member computer then receives it, including newly invited companions before their first conversation starts. Passwords, API keys and OAuth secrets are never shared: whoever shares a server keeps using it without signing in again, and every other member enters their own values, which stay on their computer.
  • Per-tool permissions: tool access is managed from the desktop settings, with sensitive outbound actions requiring human consent (see Security).