How to Decide Which Integrations Your AI Actually Needs

Picture a ten-person team on the afternoon they get access to an AI platform with a big integration catalog. The ops lead, reasonably excited, connects HubSpot, Gmail, Slack, Stripe, Notion, Jira, Google Drive, QuickBooks, and a dozen more before dinner. Six weeks later, three of those connections get used daily, five have never been queried once, and two are silently broken because an OAuth token expired and nobody noticed.

This is the normal outcome of deciding which AI integrations to connect by scrolling a catalog. The catalog is the wrong input. The right inputs are two lists you probably already know by heart: where your work stalls, and where your data actually lives. This guide walks through building both lists, deriving a minimum connected set from them, and deliberately leaving everything else disconnected until it earns its place.

The connect-everything trap

Connecting an integration feels like progress. It takes ninety seconds, produces a satisfying green checkmark, and costs nothing up front. That is exactly why teams over-connect.

The costs show up later, and they are real:

• Noise in every answer. An AI reasoning over 30 connected tools has to decide, for every question, which of those tools might be relevant. More connections means more wrong guesses, slower answers, and results that cite a stale Notion page when the live answer was in HubSpot.
• Broken connections you do not see. Tokens expire. Admins rotate credentials. Someone offboards and their Google account, which held half the OAuth grants, gets deactivated. A connection nobody uses fails silently and nobody cares, until the one week you need it. This is the same failure class we cover in why automations fail silently and how to catch it.
• A wider surface to secure. Every grant is scope you have to reason about. Read access to Gmail is not a casual decision. Ten read grants you use are defensible. Thirty grants where twenty are dormant is just risk with no return.
• False confidence. A dashboard full of green checkmarks looks like an AI-enabled company. Usage tells the truth. If nobody asks questions that touch the tool, the connection is theater.

The fix is not connecting less out of fear. It is connecting deliberately, in an order derived from your actual work.

Start with the stalls, not the catalog

Before you look at any integration list, spend thirty minutes writing down where work stalls in a normal week. Not where it fails dramatically. Where it waits.

Stalls are easy to find because they all have the same shape: a person who needs information they cannot see, waiting on a person who can see it. Some archetypal examples:

• The founder asks "did that invoice get paid?" in Slack, and waits four hours for whoever has QuickBooks access to check.
• A support hire escalates a ticket and asks "is this customer on the annual plan?", then waits for someone with Stripe access.
• A PM writing the Monday update spends an hour reconstructing what shipped from GitHub, what closed in Jira, and what customers said in email, because those three views live in three heads.
• Sales asks engineering "did we ever fix that export bug the prospect hit?" and the answer requires someone to search Jira history.
• Anyone, any week: "where is the latest version of the pricing doc?" followed by three people pasting three different Google Drive links.

Write down ten of these. Then annotate each one with the system that holds the answer. You will notice something useful: the same four or five systems keep appearing. Those systems are your integration shortlist, and you found it without opening the catalog.

The stall list beats the catalog because it encodes frequency and pain. A tool that appears in six stalls is worth connecting even if it is boring. A tool that appears in zero stalls can wait indefinitely, no matter how impressive the integration demo looks.

Map where the data actually lives

The second list is about systems of record. For each type of question your team asks, one system holds the truth, and it is often not the system where people look first.

Run through these categories honestly:

• Customer relationships. The truth is in the CRM (HubSpot, Salesforce), but half of it leaks into Gmail threads that never got logged. If your team lives in email and the CRM is an afterthought, Gmail may be the more valuable connection, which surprises people.
• Money. Stripe knows what customers actually paid. QuickBooks knows what the business actually spent. The spreadsheet someone exports monthly knows neither, reliably.
• Work state. Jira or your tracker knows what is in flight. GitHub knows what actually merged. These disagree constantly, and the disagreement is itself valuable information an AI can surface.
• Institutional knowledge. Notion, Google Drive, and Confluence hold the docs. The problem is never that the docs do not exist. It is that nobody can find the right one at the moment of need.
• Operational truth. Sometimes the real answer is only in the production database. No SaaS tool knows your actual signup count for yesterday; PostgreSQL does.

The mapping exercise surfaces a pattern worth naming: connect where truth lives, not where conversation happens. Slack is where questions get asked, but it is almost never where answers live. Teams that connect Slack first, because it feels central, get an AI that can search chatter. Teams that connect Stripe, HubSpot, and Jira first get an AI that can answer the questions the chatter was asking.

If a tool you rely on is niche or internal, that changes the plan but does not break it. There is almost always a route in through an API, a database connection, or an export, covered in detail in how to connect any tool to your AI.

The minimum connected set for most teams

Cross-reference the stall list with the data map and you get a minimum connected set. For most small B2B teams it converges on five to seven connections. Here is how the common candidates compare, and the honest signal for connecting each one now versus deferring it.

Read the "defer if" column seriously. It is not a consolation prize. A two-person team with twelve customers genuinely does not need a CRM integration yet, and connecting one anyway just adds a surface that can rot. The right set for a five-person agency looks different from a fifteen-person SaaS, and both look different from a solo consultant. For a fuller view of sizing the whole toolchain, not just integrations, see the AI stack for small teams.

A simple test for which AI integrations make the cut

When a connection is borderline, run it through three questions. It needs a yes on at least two.

1. Will someone query it weekly? Not "could." Will. Go back to the stall list and count appearances. Weekly-or-better frequency is the bar because anything less frequent means the connection sits unused long enough to break quietly, and the first real query fails at the worst moment.

2. Does it join with something already connected? The compounding value of integrations is in cross-tool questions: "which customers from HubSpot deals closed this quarter have open Jira bugs?" or "does this Stripe churn line up with the support threads in Gmail?" A tool that joins with two existing connections is worth more than a standalone tool with higher individual usage, because it upgrades every question that touches its neighbors. This is the whole argument for orchestration over point solutions, the same case made in why an AI assistant for business needs more than ChatGPT.

3. Would a cited answer from it end a recurring argument? Some connections earn their place not on frequency but on authority. If the team debates "did we tell the customer that?" monthly, a Gmail connection that produces the actual thread with a citation ends the debate permanently. Answers that cite their source change team behavior in a way that answers from memory never do.

A connection that fails all three is a no, regardless of how prominent the tool is in your company. A connection that passes all three should probably have been connected last month.

Which AI integrations to leave disconnected on purpose

Deliberate non-connection is a decision, and writing it down prevents relitigating it every quarter. Common candidates for the do-not-connect list:

• Tools you are about to leave. If the team is halfway through migrating from Asana to Linear, connecting Asana bakes a dying tool into your AI's worldview. Connect the destination, not the departure.
• Duplicate sources of the same truth. If HubSpot syncs to a Google Sheet for reporting, connect HubSpot and skip the sheet. Two sources of one truth means the AI will eventually cite the stale one, and you will trust every answer a little less.
• High-sensitivity, low-frequency systems. Payroll and HR systems hold data with real blast radius and generate questions a few times a year. The math rarely works. Answer those questions by hand.
• Personal accounts. Integrations should be granted through role accounts or the team's workspace, not through one employee's personal login that becomes a single point of failure at offboarding. If people juggle several accounts in the same tool, that needs handling on its own, covered in how AI handles multiple accounts.
• Anything nobody could name a stall for. If the tool did not appear on the stall list and does not join with anything, the burden of proof is on connecting it, not on abstaining.

Review this list quarterly. Tools move on and off as the team changes. The point is that the disconnected state is chosen, not accidental.

Sequence the rollout over two weeks

Order matters more than speed. A rollout that produces a visible win in week one builds the habit that makes every later connection pay off. A rollout that connects eight tools on day one produces confusion and a quiet return to old habits.

Days 1-2: connect the top two. Take the two systems that appeared most on the stall list. For most teams that is the CRM plus billing, or the tracker plus docs. Announce exactly one behavior change: "before you interrupt a teammate for information, ask the AI first."

Days 3-7: watch what people actually ask. The questions people type in week one are better market research than any planning meeting. If half the questions need Gmail context and Gmail is not connected, that is your next connection, decided by evidence instead of debate.

Week 2: add the next two or three, then stop. Resist finishing the shortlist just because momentum feels good. Five well-used connections beat twelve theoretical ones on every axis: answer quality, security surface, and maintenance.

End of week 2: automate one recurring stall. Pick the most repetitive item on the stall list, usually the Monday status reconstruction, and turn it into a standing artifact. A morning briefing that reads your connected tools and reports what moved overnight is the classic first automation, and there is a full walkthrough in the AI morning briefing guide.

This is also the point where platform choice becomes visible. On Skopx, the connection step is the same chat surface as the question step: the catalog covers nearly 1,000 tools, every answer cites which tool and record it came from, and a workflow like the Monday rollup is built by typing one sentence, after which it assembles on a canvas and runs on a schedule with retries and full run history. The citation detail is not cosmetic. It is what lets a skeptical teammate click through to the Stripe charge or the Jira ticket and stop double-checking the AI, which is the moment the stall actually dies.

Keep score, and prune

The audit is not a one-time event. Three numbers, checked monthly, keep the connected set honest:

• Queries per connection. Any connection at zero for a month goes on watch. Two months, disconnect it. You can always reconnect in ninety seconds, and a dormant grant is pure downside.
• Stalls that survived. Re-run the stall list. Anything from the original list that still stalls means either the wrong tool got connected or the team has not built the ask-first habit. Both are fixable; neither fixes itself.
• Connection health. Expired tokens and revoked grants should surface the day they happen, not the day someone needs the answer. If your platform monitors connection state, check that surface weekly. If it does not, put a recurring reminder on a human.

Cost discipline belongs here too. Integration pricing across the industry is frequently per-connection or per-task, which quietly punishes the audit mindset this guide recommends, because every added connection has a visible price and every pruned one feels like waste. Flat per-seat pricing changes the calculus: Skopx's Team plan is $16 per seat per month with 2.3 million AI tokens included per seat, and the connection count does not change the bill, so you can connect exactly what the audit says and prune without ceremony. Details are on the pricing page.

FAQ: deciding which AI integrations you need

How many integrations should a small team start with?

Two on day one, five to seven by the end of month one, for most teams under twenty people. The constraint is not technical. It is behavioral: each connection only pays off once the team habitually asks questions that touch it, and habits form around a small set faster than a large one. Teams that start with fifteen connections usually end up actually using three, and not necessarily the right three.

Should we connect Slack first, since everything happens there?

Usually no, and this is the most common sequencing mistake. Slack is where questions get asked, not where answers live. Connect the systems of record first (CRM, billing, tracker, docs) so the AI can answer the questions Slack is full of. Connect Slack itself once you have a concrete need to search decisions and context that exist only in channels. It earns its place in most stacks eventually, just rarely first.

Is connecting more tools a security risk?

Each grant widens the surface, so the honest answer is yes, marginally, per connection. That is an argument for the audit, not against integration. Grant read scopes where read is enough, use role accounts rather than personal logins, prune dormant connections monthly, and prefer platforms with per-organization isolation and encryption at rest. Twenty dormant grants are strictly worse than eight used ones: same class of risk, none of the return.

What if a tool we depend on is not in any catalog?

This is common with internal tools and niche vertical software, and it is rarely a dead end. Most tools expose an API even when no prebuilt integration exists, databases can be connected directly, and worst case a scheduled export gets you 80% of the value. The options, in order of preference, are laid out in what to do when AI can't access a tool.

How do we know when it is time to add the next integration?

Watch the questions that fail. When people repeatedly ask something the AI cannot answer because the relevant tool is disconnected, that tool has just self-nominated with evidence attached. This is the healthiest possible trigger for expansion: demand observed, then supply added. The unhealthy trigger is a catalog browse that ends with "might as well."

Do read-only connections deliver enough value to bother?

Yes, and they are the right default. The majority of stalls are information stalls: someone needs to see, not to change. Read access answers "did they pay," "what is the deal stage," and "what shipped" with none of the risk of write access. Add write scopes tool by tool, when a specific approved action justifies each one, not as a bundle on day one.

Earn every connection

The teams that get real leverage from AI integrations are not the ones with the longest connection list. They are the ones where every connection maps to a named, recurring stall, gets queried weekly, and would be missed within a day if it broke.

Run the audit: list ten stalls, map the systems of record behind them, connect the top two, and let observed questions pull the rest in. Prune monthly. Leave the do-not-connect list written down where the next ambitious ops lead will find it.

The catalog will still be there when you have earned your way to it.