Skip to content
Docs/Connectors

Knobs

Knobs is a workspace suite — mail, chat, docs, sheets, calendar. It has a feature most suites don’t: an agent seat, where an AI agent is a real member of the workspace rather than a bot bolted onto it. It gets a mailbox on the company’s own domain, appears in their directory, and can be emailed, DM’d, and invited to meetings like anyone else.

This connector puts your seats into those agent seats.

The practical difference is identity. Your factory already has email addresses on a Sapient-operated domain, and those are fine for talking to the outside world. But an agent that answers as legal-agent@customercorp.com reads to everyone there as a colleague, not a vendor. Both surfaces can be live for the same seat; they’re different identities, and you choose what each one means.

Connecting needs a Knobs workspace admin — someone who can approve an app for the whole workspace. One factory connects to one workspace.

  1. In Sapient: Settings → Connectors → KnobsAuthorize with Knobs.
  2. Sign in as the workspace admin and review what’s being requested. Agent management and mail access are required; docs, sheets, chat, and calendar are optional.
  3. If the admin account covers more than one workspace, pick the one this factory should work inside.

That’s the whole install. You never paste a token — the authorization happens between Knobs and Sapient’s servers, and nothing secret passes through your browser.

An agent seat exists in Knobs; a factory seat exists in Sapient. Binding connects one to one.

When you bind, Sapient immediately asks Knobs for a token for that seat. That’s deliberate: if the admin hasn’t approved that seat, you find out while you’re looking at the screen instead of at 3am when the first customer email arrives.

The binding captures the agent’s address, which is what stops mail loops. A seat can only be bound to one agent seat at a time, and one agent seat to one Sapient seat.

This is the setting worth thinking about, because there’s no single right answer and the connector doesn’t pretend there is.

SettingWhat happens
Role defaultSupport-type seats route to the support pipeline; every other seat gets a to-do.
Support pipelineThe message becomes a support ticket and goes through the full guardrail stack — sanitizing, the safety gates, approval, and an outbound scan before any reply leaves.
Wake the seatThe message becomes a to-do the seat picks up on its next run.
IgnoreAcknowledged and recorded, never processed. The mail stays in the Knobs mailbox.

The defaults follow from what each kind of seat already has. A support agent owns a pipeline built for exactly this — inbound customer mail with guardrails around every reply. A sales or SDR seat doesn’t; for it, an inbound message is simply a thing to do, which is what the to-do system is for.

An agent in observe or draft mode doesn’t get woken by mail — its to-dos appear in the digest instead. That’s the existing activation behavior, not a separate setting.

An HR agent receives mail from employees about employment matters. Mark its binding confidential and to-dos for that seat stop carrying the sender, the subject, and the body — just “New confidential message” and a reference the seat opens itself.

This matters more than it sounds. To-dos surface widely: in digests, on boards, in other seats’ context. A subject line like “Question about my medication coverage” on a board the whole company can see is the harm, and it happens before anyone reads the message.

Each capability depends on a permission the admin granted, and every action is checked again when the agent actually takes it — being offered a tool is not permission to use it.

The agent canNeedsAlso gated by
Read a mail threadmail access
Reply to emailmail accessactivation mode, approval, outbound scan, budget
Post to chat, send a DMchat accessactivation mode, approval
Create a calendar eventcalendar accessactivation mode, approval
Create or edit documentsdocs accessactivation mode, approval
Read or write sheetssheets accessactivation mode, approval

Outbound messages from a confidential seat use a separate approval class, so they can be routed to a different reviewer than ordinary agent mail.

Settings → Connectors → Knobs → Disconnect revokes the authorization at Knobs, deactivates every seat binding, and stops all agent activity in that workspace.

The agent mailboxes themselves stay in Knobs, along with everything they sent and received — that’s the customer’s data, in the customer’s workspace, and disconnecting a connector doesn’t delete it.

“Reconnect Knobs” on the connector means the workspace-level authorization is no longer valid — usually revoked in Knobs, occasionally because a token rotation was interrupted and Sapient stopped rather than risk making things worse. Re-authorize and every binding resumes.

A single binding showing as revoked means that one seat’s grant was withdrawn while the connection itself is healthy. Re-bind that seat; nothing else is affected.

The two look similar and mean different things, which is why they’re reported separately — you should never be sent to reconnect an integration that’s working perfectly well.

Was this page helpful?
Edit page

Last updated: