Connections

Connections are how agents reach outside services — Slack, Gmail, Google Sheets, Notion, Attio, GitHub, and ~1,000 more. An agent declares what it needs in its connections: field; each operator authorizes the accounts their runs act as.

Per-user authorization

Connections are authorized per user, per workspace. Because a run executes as a specific acting user, it uses that user’s authorized accounts. A manual run uses yours; a scheduled run uses the automation owner’s; an event run uses the trigger owner’s. If an agent needs a service nobody has connected, the sidebar surfaces an “Action needed” prompt with a Connect button.

LinkedIn: personal credentials only

Connect LinkedIn through Connections → New connection → Manual credential → LinkedIn. Operators and workspace admins can connect their own account. The session cookie, JSESSIONID, and user-agent are stored as personal secrets, not workspace-shared credentials. Other members cannot see the connection or its masked fields, including admins using View as.

Runs use only the acting user’s LinkedIn credentials. Inbox send/archive actions use only the clicking user’s credentials. Without a personal session, the action fails rather than falling back to someone else’s account. Schedules and triggers use their configured acting owner, as with other per-user connections.

LinkedIn does not support workspace sharing. Its linkedin_li_at, linkedin_jsessionid, and linkedin_user_agent secrets cannot be saved with workspace scope, even by an admin. Other services’ explicit workspace-shared secrets keep their existing behavior.

OAuth endpoint security

Native OAuth discovery, client registration, token exchange, and the initial tool-list request require HTTPS endpoints on the allowed provider origins (or the same origin as a self-hosted instance). These requests do not follow HTTP redirects. DNS answers are checked again at connection time, and private, loopback, link-local, and address-translation targets are rejected. A hostname that changes to a private address during authorization will fail the connection.

Three substrates

Substrate	When to pick it
Composio	The default. ~1,000 services wrapped as REST tools. Lowercase slugs (`slack`, `googlesheets`).
Native MCP	The provider has an official MCP server — richer, schema-aware tools, fewer round trips, and TAS-managed OAuth.
Secrets	A plain API key for a service with no OAuth (e.g. Clay), read by sidecar Python tools.

Prefer Native MCP when the provider is in TAS’s native catalog (below): it uses the provider’s official server with richer, schema-aware tools. Most native providers use TAS-managed OAuth (just click Connect); a couple are bring-your-own OAuth app. Use Composio for anything not in the native catalog.

Native MCP catalog

TAS ships native MCP support for these providers:

Provider	Auth
Attio, Pylon, Fathom, Dialed, Linear, Amplemarket, Clay, Avoma, Metabase, Notion, Intercom, Atlassian (Jira), Asana, monday.com, Guru, Fireflies, Amplitude, Apollo, PostHog, Stripe, Vercel, Canva, ClickUp, Close, Sentry, Mixpanel, Granola, Dropbox, Webflow, Cloudflare, Neon, Cal.com, Klaviyo, PayPal, Square, Airtable, Railway, Resend, Hex, Pendo, Similarweb, Datadog, Common Room, Outreach, Salesloft, Lusha, Hunter, Instantly, Crossbeam, Harmonic, Chili Piper, Day AI, Clarify, Staircase AI, Zendesk, Help Scout, Gorgias, Plain, Lorikeet, Unthread, Enterpret, Dovetail, Missive, Otter.ai, Grain, Krisp, Circleback, tl;dv, Ramp, Brex, Mercury, Expensify, Navan, Carta, Digits, GoCardless, Mercado Pago, PitchBook, Morningstar, CB Insights, Quartr, Daloopa, Consensus, Gusto, Deel, Ashby, Workable, Metaview, Indeed, Udemy Business, SignNow, Vanta, Drata, Figma, Miro, Lucid, Productboard, Aha!, Shortcut, Todoist, Teamwork, Calendly, Superhuman Mail, Craft, Mem, Gamma, Pitch, Eraser, Jotform, Typeform, SurveyMonkey, Egnyte, Mailchimp, Customer.io, Ahrefs, Semrush, Cloudinary, Contentful, Sanity, Wix, WordPress.com, GitBook, Mintlify, DeepL, GitLab, Supabase, Netlify, Heroku, Buildkite, Grafana, New Relic, Honeycomb, incident.io, Rootly, BugSnag, LaunchDarkly, PlanetScale, Prisma Postgres, InstantDB, Algolia, Statsig, Postman, Semgrep, WorkOS, Stytch, Mux, Knock, Lovable, Retool, Telnyx, Jam, Globalping, Airbyte, MotherDuck, Monte Carlo, Atlan, Hugging Face, Zapier, Make, IFTTT, Exa, Tavily, Firecrawl, Apify, Bright Data, Kernel	TAS-managed OAuth — click Connect, authorize, done
GitHub, X, Render	API token — paste a PAT (GitHub), App-only Bearer (X), or API key (Render)
Maxio (Carefeed)	TAS-managed OAuth — Carefeed SSO; confirm the Analyst role in Maxio first (setup below)
HubSpot, Gmail, Slack, Gong, Box, PagerDuty, Zoom, ZoomInfo, DocuSign, Xero, Front, Smartsheet, MongoDB Atlas, CircleCI, Chargebee, BigQuery, Ironclad, Harvey, Tableau, Shopify	Bring-your-own OAuth app — admin sets up once (below)

There’s also a built-in Tembo Agent Studio native connection (TAS’s own MCP server) that agents use to read/produce Tasks Inbox items and trigger other runs.

Optional Tembo Memory

An instance admin can connect a Memory server by setting TAS_MEMORY_URL (the server origin, not /mcp) and TAS_MEMORY_ADMIN_TOKEN on the API service only. Leave both unset to disable the integration. The web app and agent subprocesses never receive the Memory admin credential. Memory must include workspace APIs and short-lived agent keys; use its MEMORY_BOOTSTRAP_TOKEN as the controller token.

Every Pydantic agent then receives memory_ask, memory_search, memory_entities, memory_card, and memory_report automatically, without a connections: entry. Cargo AI is unchanged. The managed connection replaces a manually declared tembo-memory connection; its tool names are reserved for the integration. Agents should memory_ask before acting on people, accounts, deals, or threads, and memory_report once per interesting item inspected — including items they do not surface to a worklist. Pass kind:name entity ids (person:jane@acme.com, org:acme); a bare display name is stored as unknown:, not as a person. Skip bulk, billing, and thanks. Author that into the agent’s own procedure; a “produce nothing else” step otherwise skips Memory.

Use memory_card with an exact entity_id from memory_entities when preparing a person, customer, or project briefing. Entity Cards summarize overview, goals, owners, decisions, constraints, and open questions with claim-level citations. Check those citations before important actions; empty sections do not prove that facts do not exist. Use memory_ask for targeted questions and memory_search for supporting claims. If card generation fails, use those tools and disclose the limitation rather than treating the entity as unknown.

Memory creates cards on demand and owns their permission-scoped cache and lazy refresh after evidence changes or expiry. Studio does not cache card responses. Card requests have a 120-second upstream timeout; the managed tool connection allows 150 seconds for reads, including credential setup. Other upstream request timeouts are unchanged. Avoid fetching the same card repeatedly within a task unless new evidence warrants it.

Studio bundles the managed Memory tool catalog with its API; it does not discover that catalog from the Memory server or the native-connection tool cache. Deploy the updated Studio API and start a new run to pick up card support and guidance. No agent-spec edits or native-connection catalog refresh are required.

Under Workspace Settings → General → Memory, an instance admin who belongs to the workspace can select its Memory workspace. The default is a dedicated workspace created lazily on first upstream use. Selecting an existing one deliberately shares its internal knowledge with agents here. Several Studio workspaces can select the same Memory workspace. Ordinary workspace admins cannot change this cross-workspace sharing boundary. Agent identity includes the originating Studio workspace, stable agent name, and acting user, even when the target Memory workspace is shared.

Studio calls Memory’s HTTP API through a managed MCP bridge. It obtains one-hour, internal-sensitivity agent credentials on the server; it does not grant agents Memory admin rights. Credentials are renewed without changing the filing identity. Within the selected workspace, agents can read internal claims across account scopes, but cannot read higher-sensitivity claims.

Outages and queued reports

Memory outages do not fail runs. Reads return an explicit unavailable result, not an empty knowledge answer. memory_report first commits an encrypted report to Studio’s Postgres outbox and returns a queued receipt. If that commit fails, the tool says it was not queued; it never claims a successful save.

A background worker retries delivery automatically with backoff, including after Studio restarts and when the original agent never runs again. The original event time, source, filing principal and replay identifier are preserved. If Memory accepts a report but its response is lost, retry retrieves that same report. Delivered means accepted for extraction, not that claims are already available. Payload content is removed from the outbox after acknowledgement; receipt metadata remains.

Workspace settings show queue counts and sanitized blocked-item errors. Run pages show report status and Memory warnings; refresh to see delivery after a run finishes. Instance admins can retry blocked reports after fixing authorization/configuration. Removing/demoting the acting user or disabling the integration blocks pending delivery. Reports are never silently moved to a different destination when a mapping or server URL changes: mapping changes affect new runs, existing receipts retain their original target, and changing the server URL blocks old receipts for review.

Dry runs may read Memory but never enqueue or deliver new reports. No prompts or routine outputs are copied automatically. Reports are limited to 64 KiB; prefer durable facts and source pointers. Use the same external_id for retries of the same source item. Memory bootstrap credentials, protected workspaces, and sealing remain under the Memory administrator’s control; sealed workspaces retain pending reports until ready.

Bring-your-own OAuth app (Manage providers)

A few native providers (HubSpot, Gmail) need a confidential OAuth app you create in their console — TAS can’t self-register one. A workspace admin sets this up once, then everyone connects normally:

Connections → Manage providers → find the provider’s card.
Create an OAuth app in the provider’s console (the card links to its guide). Register the redirect URI shown on the card and grant the scopes it lists (e.g. Gmail needs the Gmail API + Gmail MCP API enabled and the https://mail.google.com/ scope).
Paste the app’s client ID + secret into the card, then enable the provider with its toggle.
Members can now Connect it from the normal connect flow.

Until an admin does this, a bring-your-own provider doesn’t appear in the connect list — it shows “needs an OAuth app first.”

Declaring connections on an agent

connections:
  - { type: slack, tools: [SLACK_SEND_MESSAGE] }
  - { type: attio, source: native-mcp, name: default, tools: [run-basic-report] }

type: is the provider slug.
source: defaults to composio; set native-mcp for native providers.
name: is the connection slot (“default” unless you keep multiple accounts of the same provider, e.g. work vs personal).
tools: narrows what the agent can call (works on both substrates).

Authorizing and reconnecting

Authorize and manage connections under Connections. Native MCP OAuth tokens refresh before agent runs, Refresh tools, and native MCP inbox actions when they are near expiry. Rotating refresh tokens are stored atomically, and temporary authorization-service failures (including a cold discovery/token endpoint on the first attempt) are retried in the same run without requiring you to reconnect.

Refresh discovery preserves authorization-server issuer paths, including Stripe’s /mcp path, so renewal uses the correct provider metadata endpoint.

If refresh fails and the access token has already expired, it is not passed to the agent or used for the web action. Retry after the authorization service recovers; a temporary failure does not require reconnecting. Running agents still use the token captured at startup, except for Maxio’s refresh-aware Pydantic transport described below.

When a refresh is temporarily unavailable, the connection shows Retrying and its detail page shows when another attempt is allowed. If consent was revoked, the refresh grant is no longer supported, or the OAuth application is invalid, the connection is marked Stale or Revoked with a safe reason and a Reconnect action. Runs that require one of those connections are blocked with the same actionable reason. Token values and provider response bodies are never shown in the health message.

Reconnecting a Native MCP account normally reuses its existing registered OAuth client instead of consuming another provider registration. If a provider rate-limits a first-time connection, wait and retry later.

See Troubleshooting.

Maxio (Carefeed)

Choose Maxio (Carefeed) in the Native MCP catalog and click Connect. Sign in through Carefeed’s SSO as the user who will own the scheduled runs. The connection uses https://brave-hall-4395.mcp.maxio.com/v3/mcp; it is specific to Carefeed, not a general Maxio tenant selector. No API key is required.

Before connecting, ask the Maxio administrator to enable the MCP connector, choose Custom MCP Client, and confirm the Analyst role. Analyst is the read-only role; Bookkeeper adds write actions and is not the intended setup. The advertised OAuth scope is all: it does not mean read-only. Maxio’s selected role enforces access, so Studio cannot turn a Bookkeeper authorization into Analyst by requesting a narrower OAuth scope.

The endpoint advertises dynamic client registration, PKCE, and refresh-token grants. Studio registers its OAuth client automatically, so a manually supplied client ID or secret is not normally needed. If the Maxio administrator needs the redirect URI for an allowlist, it is https://<your-studio-host>/api/connections/native/maxio/callback. See Maxio’s connector setup guide.

Maxio’s one-minute access tokens are refreshed before runs and, for Pydantic agents, before MCP requests during the run when fewer than ten seconds remain. The run uses a local, capability-protected transport; refresh credentials stay in the API and rotated tokens are persisted under the existing connection lock. Scheduled runs use the schedule owner’s authorization and do not require a new interactive sign-in unless consent or the refresh grant expires or is revoked. Complete an initial SSO connection and a scheduled run to verify the tenant actually issues a reusable refresh grant and has the intended Analyst role.

Declare the connection with source: native-mcp and provider maxio. Do not substitute the Composio Maxio toolkit: this connection deliberately uses Maxio’s own per-user OAuth rather than an API-key toolkit with write/delete actions.

Viewing another member’s connections (admins)

Workspace admins see a Viewing dropdown at the top of the Connections page. Switch it to inspect another member’s authorized accounts. When viewing someone else you can Rename and Refresh their connections; Connect, Reconnect, and Disconnect are hidden because OAuth must be performed by that member themselves.

Use this together with the member detail view when troubleshooting “no active connection” failures for automations or triggers that run as a specific owner.

For doing deterministic I/O over a connection from Python, see Sidecar Python tools.

Secrets (API keys)

Some services — like Clay — authenticate with a plain API key, not OAuth. For these, use a Secret: a free-form key stored under Connections → Secret / API key. Operators can add a personal secret; workspace admins can also add a workspace-wide shared secret. Secrets are read by an agent’s sidecar Python tools via tas_tools.secret("name") — they attach no tools and are invisible to the model.

Add one: Connections → New connection → Secret / API key → name (e.g. clay) + value. Workspace admins choose Me or Workspace; operators create personal secrets. Values are encrypted at rest and shown masked.
Use it in a tool: tas_tools.secret("clay") returns the value.
Resolution: a run uses the acting user’s personal value first. When they do not have one with that name, it falls back to the shared workspace value. LinkedIn’s session secrets are the exception: they are always personal and never fall back to shared values. Other members cannot see or manage a personal secret.
Optionally declare it on the agent so the studio prompts an admin to set a missing one:
```
connections:
  - { type: clay, source: secret }
```