Here is the most common way an AI agent project dies. Someone gets a demo working against a sandbox. It writes a beautiful summary of a fake support ticket. Everyone claps. Then it meets the real stack — a Slack workspace with 4,000 channels, a Salesforce org that three admins have customised since 2019, a Notion database where half the "Status" values are typos — and it falls over.
The model was never the hard part. The integrations are the hard part.
This is the guide we wish existed when we started building Kaer's agent runtime. It covers the order to connect things in, the permissions to refuse, the rate limits that will bite you, and the specific ways each major system misbehaves. It is opinionated, because after enough integrations you stop being neutral.
Why integrations decide whether an agent is useful
An agent's value is bounded by what it can see and what it can change. That is not a philosophical point, it is an arithmetic one. If your agent can read a support ticket but cannot look up the customer's plan in Stripe, cannot check whether there is an existing bug in Linear, and cannot reply in Zendesk, then the human still has to do all three. You have automated the easiest 10% of the job and added a review step.
This is the difference we drew in AI agents vs. chatbots: a chatbot needs a text box, an agent needs credentials. Once you accept that, the project stops being an AI project and becomes an access-management project with an AI attached. That reframe will save you a month.
It also explains why so many pilots stall at 80%. The reasoning works. The permissions request is sitting in an IT queue behind a laptop refresh.
The integration order that actually works
Teams tend to connect tools in the order they feel important: CRM first, because revenue. That is the wrong order. Connect them in order of how easy it is to prove the agent helped, because your pilot's real enemy is ambiguity about whether it worked.
1. Start with a queue that has a visible backlog
Zendesk, Jira, Linear, GitHub Issues, Intercom — anything with a count that goes up when nobody does the work. Queues are the ideal first integration because they come with a built-in metric. First-response time, triage latency, and unassigned-ticket age were all being measured before the agent existed, which means nobody can argue about the baseline afterwards.
Read-only first. An agent that reads every new Linear issue and posts a one-paragraph triage suggestion with a suspected owner is genuinely useful and cannot break anything. Run it for two weeks. Count how often the suggestion was right. That number is your permission to go further.
2. Then the place your team already talks
Slack or Microsoft Teams. Not because it is powerful — because it is where the agent's output gets seen. An agent that writes excellent summaries into a dashboard nobody opens has zero organisational impact. The same agent posting into the channel where the standup happens changes behaviour in a week.
We wrote up the specifics of this one separately, because Slack has more sharp edges than any other integration on this list: how to connect an AI agent to Slack without building another bot nobody uses.
3. Then the system of record — read only
Salesforce, HubSpot, Postgres, Snowflake, BigQuery. This is where the agent stops guessing. "Customer is angry about billing" becomes "customer is on the $499 Growth plan, has three open tickets this month, and their card failed on the 4th." Same ticket, completely different reply.
Keep it read-only for longer than feels necessary. See the CRM section below for why.
4. Then documents and knowledge
Notion, Confluence, Google Drive, SharePoint. Deliberately fourth, which surprises people, because knowledge-base retrieval is what most demos lead with. The problem is that your knowledge base is probably wrong. Not maliciously — just stale. Runbooks describing a service you renamed. Two competing onboarding docs from different quarters. An agent that confidently cites the wrong doc is worse than one that says "I don't know," and you will not discover the staleness until the agent surfaces it.
Connecting documents fourth means you have already got the reliability basics working, so when the agent starts producing confidently wrong answers you will correctly blame the corpus rather than the model.
5. Write scopes, one at a time, each with an audit trail
By now you have weeks of evidence about where the agent is accurate. Grant write access exactly there. Not everywhere.
This staged order is the practical version of the argument in why most AI automation projects fail. Almost every failure we have watched came from granting broad capability before establishing narrow accuracy.
The systems, one at a time
Slack: the API is generous, the etiquette is not
Technically Slack is one of the friendlier integrations. OAuth 2.0, well-documented scopes, Socket Mode so you do not need a public URL during development, and a Web API that mostly does what the docs say. Tier 3 methods allow roughly 50 requests per minute, which is plenty for an agent and nowhere near enough for a backfill — so if you plan to read history, page it slowly and cache aggressively.
The hard parts are social. channels:history sounds innocuous and grants your agent the ability to read every message in every public channel it joins, which includes the channel where someone pasted a production credential in 2023. chat:write plus a broad read scope is the combination that turns an agent into a data-exfiltration path. Ask for channels:history on specific channels via conversations.join, not workspace-wide, and keep the agent out of channels it has no business in.
The other trap: threading. Agents that reply in-channel instead of in-thread generate so much noise that people mute the channel, and a muted channel is a dead integration. Always reply with thread_ts. Use reply_broadcast approximately never.
Notion: lovely to read from, painful to write to
Notion's API is clean and its data model is not. A Notion database is a schema that anyone on your team can change on a Tuesday. Rename a select option from "In Progress" to "In progress" and every agent filter matching the old string silently returns zero results. No error. Just an agent that has stopped finding work and does not know it.
Two defences. First, resolve property names and select options at runtime from the database schema rather than hardcoding strings — GET /v1/databases/{id} gives you the current shape. Second, treat a sudden drop to zero results as an alert condition, not a normal empty state. Silent zero is the single most common Notion integration failure and it looks exactly like "nothing to do."
Also budget for pagination. Notion caps page size at 100 and its rate limit is around three requests per second averaged. A 5,000-row database is 50 sequential calls, which is roughly 20 seconds of wall clock before your agent has even started thinking.
Salesforce and HubSpot: read first, and mean it
CRMs are where integration mistakes become expensive, because CRM data feeds forecasting, commission, and board reporting. An agent that mislabels 400 opportunities does not cause an outage. It causes a quarter of bad numbers that somebody notices in a board meeting.
Salesforce specifics worth knowing: the REST API is fine, but your org is almost certainly not vanilla. Custom objects with __c suffixes, validation rules that reject writes for reasons no error message explains, required fields added by an admin who left, and Apex triggers that fire on update and do something surprising. Query with SOQL against the fields you have actually verified exist in that org, and expect API limits per 24-hour rolling window that a chatty agent can genuinely exhaust.
HubSpot is more forgiving and has a cleaner object model, but its rate limits are stricter than people expect — roughly 100 requests per 10 seconds on standard plans — and it will happily let an agent create duplicate contacts if you match on the wrong property. Match on email, always, and use the batch endpoints.
For both: the highest-value pattern is not "agent updates CRM." It is "agent drafts the update, a human approves it in one click." You keep the time saving and lose the risk of silent corruption. Nobody regrets this decision.
Jira and Linear: the same job, opposite philosophies
Linear's API is a genuine pleasure — GraphQL, consistent, fast, and it treats API consumers as first-class. If you get to choose, choose Linear. Its rate limits are generous and its webhook payloads actually contain what you need, so an agent can react to state changes without polling.
Jira is more work and more common. The REST API is versioned in a way that makes docs hard to trust, custom fields arrive as customfield_10042 rather than a name, and the same Jira Cloud instance can behave differently across projects because project-level configuration is deep. Fetch the field metadata once per project and build a name-to-id map at startup. Hardcoding customfield_10042 works until someone provisions a new project.
For both: prefer webhooks over polling. An agent polling Jira every 30 seconds across ten projects burns your rate limit and still reacts late. This is exactly the kind of plumbing that Kaer Workflows exists to make boring.
Zendesk and Intercom: rich data, aggressive limits
Support platforms hold the best raw material an agent can get — real customer language, full conversation history, resolution outcomes. They also rate-limit hard. Zendesk's Ticketing API commonly sits around 700 requests per minute at the account level, shared across every integration you have, so your agent is competing with your analytics sync and whatever else marketing installed.
Use the incremental export endpoints for history rather than walking tickets. Subscribe to webhooks for new events. And cache the customer lookup, because an agent that re-fetches the same organisation record for each of eight tickets in a thread is doing eight times the necessary work.
The specifics of building a support agent that actually reduces first-response time are their own topic: AI agents for customer support.
Google Workspace and Microsoft 365: the scope conversation
Gmail, Google Calendar, Drive, Outlook, SharePoint. These are the integrations where your security team gets involved, and they are right to.
Google's gmail.readonly scope is all-or-nothing across the mailbox, which means an agent that only needs to read invoices from one sender is technically able to read the CEO's mail. Where possible, use a service account with domain-wide delegation restricted to a specific OU, or route mail through a dedicated address and grant access only to that. Microsoft Graph is better here — application permissions can be scoped to specific mailboxes with an application access policy — but almost nobody configures it, so audit yours.
Calendar is the underrated one. Read access to a team's calendars plus the ability to propose times removes a genuinely annoying category of work and carries far less data risk than mail.
Stripe and billing: read-only, permanently
An agent that can check a subscription, a plan, and whether the last payment failed answers a large fraction of support questions on its own. An agent that can issue refunds is a liability with no upside — the refund itself takes a human three seconds once the agent has assembled the context. Use restricted API keys with read permissions on the specific resources, and rotate them.
The part everyone gets wrong: too many tools
There is a strong intuition that more integrations means a more capable agent. In practice the curve bends down, and it bends earlier than people expect.
The mechanism is tool selection. An agent picks which tool to call by reading the tool descriptions. When you have four tools with distinct purposes, that choice is easy. When you have eighteen, and three of them can plausibly "search for a customer" — one in Salesforce, one in Stripe, one in your own Postgres — the agent starts choosing wrong. Not catastrophically wrong. Subtly wrong, in a way that produces a plausible answer from the least authoritative source.
Three things help, in order of effect:
- Write tool descriptions that say when NOT to use the tool. "Search Stripe customers. Use this only for billing and payment questions; for plan entitlements use search_entitlements instead." The negative clause does more work than the positive one.
- Give one agent a narrow toolset. Several specialised agents with five tools each beat one agent with thirty. A support agent does not need repository access.
- Delete tools nobody calls. Log tool-call frequency. Anything at zero after a month is pure interference in the selection prompt.
This is the same discipline as picking your first automations: narrow and reliable beats broad and approximate, every time.
MCP, and why the plumbing is finally standardising
Until recently, every integration was bespoke. Each platform invented its own tool-definition format, so a Notion connector written for one framework was useless in another. The Model Context Protocol changed that — it is an open standard for describing tools, resources and prompts that an agent can consume, and it is now supported broadly enough to matter.
The practical benefit is not elegance, it is reuse. An MCP server for your internal API works with any MCP-capable client. If you are choosing where to invest integration effort in 2026, invest in an MCP server for your own systems rather than a bespoke connector for one vendor's agent framework. It survives you changing your mind about the framework, which — if the last two years are any guide — you will.
What MCP does not solve: authentication, rate limits, data residency, and the fact that your Notion database has typos in it. The protocol standardises the interface, not the mess behind it.
What breaks in month three
Integrations do not fail on day one. Day one is when everyone is watching. They fail in month three, quietly. The recurring causes, roughly in order of frequency:
- Token expiry. A refresh token gets revoked when someone rotates credentials or leaves the company, and the agent starts failing every call. If your failure path is "log and continue," this looks like an agent that has become useless for no reason. Alert on auth failures specifically, separately from other errors.
- Schema drift. Someone renames a Notion select option, adds a required Jira field, or changes a Salesforce picklist. Resolve schemas at runtime and alert on unexpected shapes.
- Rate-limit contention. A new tool gets installed and eats the account-level quota your agent was quietly relying on. Track your own 429 rate as a first-class metric.
- Silent empty results. The most dangerous one, because zero results and zero work look identical. Any query that has never legitimately returned zero should treat zero as an error.
- Permission creep. Scopes accumulate during debugging and nobody removes them. Re-audit quarterly and actually revoke.
None of these are AI problems. They are integration problems, which is the point of this whole article — and a large part of the build vs. buy calculation. Maintaining twelve connectors against upstream APIs that change without asking is a real, permanent cost that build-it-yourself estimates almost always omit.
A checklist you can actually use
Before you connect anything:
- Can I prove this integration helped, using a metric that existed before the agent? If not, pick a different one.
- What is the narrowest scope that delivers the value? Start there, not one step above.
- Does this agent now have both broad read access and outbound-send capability? If yes, split it into two agents.
- Where does an auth failure surface? If the answer is "in the logs," fix that first.
- What happens when this returns zero rows? If the answer is "nothing," you have a silent-failure bug waiting.
- Who revokes this when the agent is retired? Write the name down.
Six questions. They take ten minutes and they prevent most of what goes wrong.
Where to go next
If you are picking your first integration, read the Slack guide — it is the one most teams start with and the one with the most avoidable mistakes. If you are trying to work out whether you need agents at all or whether a workflow tool would do, the comparison against Zapier, Make and n8n is the honest version of that question, including the cases where the answer is "use Zapier." And if you are choosing a platform to build on, the founder's evaluation framework covers what to look for beyond the feature list.
The summary, if you only take one thing: the model is a commodity, the integrations are the product. Spend your effort accordingly.
Frequently asked questions
Which integration should an AI agent get first?
Whichever system your team already complains about in Slack. In practice that is almost always the ticketing or support queue — Zendesk, Jira or Linear — because those queues have measurable backlogs, so you can prove the agent helped. Start with read-only access, watch it for two weeks, then grant write scopes.
Do AI agents need write access to Salesforce or HubSpot?
Not at first, and often not ever. Read access plus the ability to draft a change for human approval covers most of the value. Full write access to a CRM means an agent can silently corrupt pipeline data that your forecasting depends on, and CRM records are notoriously hard to un-corrupt because downstream reports cache them.
What is the difference between an integration and a tool call?
An integration is the credentialed connection to a system — the OAuth grant, the token, the webhook subscription. A tool call is one specific action the agent can take through it, like create_issue or search_contacts. One Slack integration might expose eight tool calls. Scoping matters at the tool-call level, not the integration level.
How many integrations does an agent need to be useful?
Two or three, connected properly. Teams routinely wire up fifteen and then discover the agent picks the wrong tool because the descriptions overlap. Every additional tool with a vague description measurably degrades selection accuracy, so breadth costs you reliability.
How do you stop an AI agent from leaking data between integrations?
Scope credentials per agent rather than per workspace, and never give one agent both a broad read scope on a private system and any outbound-send capability. That specific combination — read everything, message anyone — is how data walks out. Audit the pairing, not just the individual permissions.