Connectors, Explained: How Your AI Agent Talks to Gmail, Slack, and Everything Else

If an AI agent is the brain, connectors are the hands. This post is about the hands — how they work, what they can and can't do, and how to decide which ones are worth setting up for your particular business.

At the simplest level, a connector is a bridge between your agent and an outside service — Gmail, Slack, Notion, a spreadsheet, a CRM. Once connected, the agent can call specific, well-defined actions on that service: read the last 10 emails, post a message to a channel, look up a contact record, add a row to a sheet. The agent doesn't get free rein over your account; it gets a narrow, specific set of capabilities that you've explicitly turned on.

This is where the read versus send distinction matters. Almost every connector on a well-built platform lets you choose whether the agent can only read from a service, or also send/write to it. Read-only access means the agent can look things up — check your calendar, search your Drive, pull a Notion page — but can't change anything. Send access means the agent can also take action — send an email, post to Slack, create an event, update a CRM deal.

The right default, especially early on, is read-only wherever the task allows it. If your agent's job is to answer "what's on my calendar tomorrow," it never needs send access to your calendar. Save send permissions for the connectors where the agent's whole value is doing something on your behalf — like an inbox-triage agent that needs to actually reply, or a scheduling agent that needs to actually create the event.

A second thing worth understanding is that connectors are per-agent, not global. If you have three different agents — one for customer support, one for internal scheduling, one for lead qualification — each one gets its own explicit set of connectors and permissions. Your support agent doesn't automatically get access to your calendar just because some other agent in your account does. This matters for security: a public-facing chat widget answering customer questions should generally have far fewer, more tightly scoped connectors than an internal tool only your team uses.

Some connectors are worth calling out individually because of how they change what an agent can do:

Incoming webhooks flip the direction. Instead of the agent reaching out to another app, an outside system — a website form, a Zapier flow, an n8n automation — can trigger the agent directly. This is how a lot of "AI on my website" setups actually work under the hood: the form submits to a webhook URL, and the agent processes it and replies, all without you writing a line of integration code.

HTTP Request connectors are the escape hatch. If a service you use doesn't have a dedicated connector yet, but does have any kind of web API, a generic HTTP Request connector lets the agent call it directly — you supply the base URL and any auth header it needs, and the agent handles the rest.

Deployment-oriented connectors, like one that pushes generated content live to a hosting provider, turn the agent from something that only talks into something that ships. Ask it to draft a landing page, and instead of getting text back that you'd still have to publish yourself, you get back a working URL.

The practical advice for anyone setting this up for the first time: start with one agent and one or two connectors, both read-only, and get comfortable with what the agent actually does with that access before opening anything else up. Add send permissions one at a time, and only for the specific action you actually need automated. It's much easier to loosen restrictions later than to realize in hindsight you gave an agent more reach than the task ever required.