Connecting an AI Assistant to Your Business Tools

Search for an AI assistant that connects to your business tools and every result is a vendor counting its own connectors. Lindy advertises over 3,000 tools. Everyone else quotes a number of their own. Not one of those pages explains what happens after you connect them, which is the only part that decides whether the thing is useful in week six.

I run a connected assistant across my own email, calendar, invoicing app and messaging every working day, and I have fixed each of the failures below on live client systems. This is the operator version of the topic: what a connection actually is, the four ways it breaks, the questions that expose a vendor who has not thought about it, and honest cost bands at the end.

What a connection actually is

Strip the jargon away and a connection is one thing: a way for the assistant to log into your tool on your behalf. You approve it once, in a consent screen you have seen a hundred times, and the tool hands the assistant a key. The key is not your password. It is limited to specific actions, it belongs to your account, and you can cancel it from your account settings without changing anything else.

Two properties of that key cause almost every problem in this article. First, it expires, on a schedule the tool’s vendor sets and rarely advertises. Second, it carries a fixed list of what the assistant is allowed to do, chosen at the moment you clicked approve, and nobody reads that list.

Everything else is detail. If you understand those two properties, you can evaluate any vendor on your shortlist in about four questions.

The four failures, and how each one shows up

These are in the order they tend to bite. The middle column is the part vendors leave out: what you see is almost never what is happening.

Failure 1: the login quietly expires

This is the most common failure by a distance, and the most misdiagnosed, because it does not look like a failure. The assistant does not say “I am locked out of your inbox.” It says nothing, or it says there is no new work. People conclude the AI has got lazy. The AI has been evicted.

Google publishes the rules for its own tools, and they are worth reading once because most vendors work the same way. Per Google’s OAuth 2.0 documentation, the key stops working when:

• It has not been used for six months. A connection you only need at quarter-end can die between quarters.
• The app is still in “Testing” publishing status, in which case Google issues a key that expires in seven days. This one catches almost every self-built integration, because Testing is where every project starts and nobody remembers to leave it.
• The user changed their password and the key includes Gmail access.
• You cross 100 keys per Google account per app, at which point creating a new one “automatically invalidates the oldest refresh token without warning.” Re-authorise on a whim often enough and you silently kill your own oldest connection.

Other systems run shorter clocks. Xero, to take an accounting example, expires an unused connection after 60 days and hands back a brand-new key every time the old one is refreshed, with a 30-minute grace period if your side never receives the response (Xero’s authorisation flow documentation). Store the replacement wrongly once and you are re-authorising by hand. Nobody sends you an email about any of it.

The fix costs a few hours and eliminates the whole class of problem: a daily heartbeat that makes one cheap, read-only call to every connected tool and messages a human the moment one fails. Not a dashboard nobody opens. A message, to a person, naming the tool. On my own setup that check runs every morning before I am awake, and the two times a connection has dropped in the last year I knew before I opened my laptop. And before go-live, take the app out of Testing status, or you are shipping a system with a seven-day fuse.

Failure 2: the permission is wider than the job

When you approve a connection, you approve a specific list of allowed actions. Vendors tend to request the broadest option available, because one wide permission covers every feature they might ship later and saves them asking you again. That convenience is yours to refuse.

Email is the clearest example, because Google splits the permissions apart deliberately. From the Gmail API permission list:

Google’s own guidance is to request the full-access option “only if your application needs to immediately and permanently delete threads and messages, bypassing the trash.” An assistant that triages your inbox and drafts replies does not need that. Ever. Yet it is routinely what gets requested, and once granted, a confused assistant on a bad day has the same destructive reach as a disgruntled employee.

Four rules I apply to every system I build or run:

• Give the assistant its own login, never a shared staff account. Then the audit log tells you which actions were the machine and which were a person, and revoking it takes one click and breaks nothing else.
• Read-only until write is proven necessary. Most assistants earn their keep summarising and drafting long before they need to change anything.
• Never grant the delete-capable permission unless deletion is the job. The trash exists. Let it work.
• Put destructive verbs behind a human confirm. On my own stack the assistant can draft and send email as me, but it cannot permanently delete anything; it can create an invoice and mark it paid, but voiding one comes to me first. Nothing irreversible happens without a person in the loop.

Failure 3: it has no memory of what it already did

This is the failure that embarrasses you in front of a customer. The assistant answers the same email twice. The same lead gets chased on Monday and again on Tuesday. An invoice goes out, the process crashes before it records the fact, and the assistant sends it again on the next run.

The cause is structural, not a bug in the model. Each run starts with a clean head. Unless you built it somewhere, there is no record of what the assistant did last time. Reading the tool back is not the same as knowing: an email you sent five minutes ago may not be in the sent folder yet, and a payment may sit in a pending state that reads as “not done”.

Two mechanisms fix it, and every serious system uses both.

A unique key per action

Attach a unique identifier to every action before it is attempted, so a retry can be recognised as the same action rather than a new one. Payment systems have done this for years. Stripe’s idempotent requests documentation describes exactly the behaviour you want everywhere: a repeated request with the same key returns the result of the first one instead of doing the work twice. Worth noting from that same page: Stripe keeps those keys for at least 24 hours. Beyond that window you are on your own, which is precisely why the second mechanism is not optional.

The assistant’s own action log

A table the assistant owns, in your database, where it writes a row before it attempts an action and updates that row after, storing the external record ID the tool gave back. On restart it reads its own log first and skips anything already marked done. Rows stuck in the “attempted” state are exactly the crash cases, and they are the first thing a human should look at.

That log is worth more than the deduplication. It is the only complete answer to “what has this thing actually been doing all week”, and it is the difference between a system you trust with real work and a system you have to check behind.

Failure 4: some of your tools cannot be connected at all

Every SMB stack I have looked at contains at least one tool with no way in. It is never the famous ones. It is the software that runs the actual business:

• An on-premise ERP or accounts package from the era before anyone shipped an API.
• Industry-specific software: dispatch, booking, case management, practice management. The vendor sells to 400 companies and has no reason to build an API for them.
• Banks. Many still offer a download and a portal, and nothing else.
• Supplier, insurer, and government portals, where the login is yours but the system is not.
• A key supplier who takes orders on WhatsApp and only on WhatsApp.

There are four honest options, in descending order of how much I like them:

1. A scheduled export. Plenty of these systems can email or drop a report on a timer. Have the assistant read the report instead of the system. Boring, cheap, and it almost never breaks.
2. Email parsing. If the system already emails confirmations, notifications, or statements, that email stream is a usable one-way feed. Half the “impossible” connections I have solved were solved this way.
3. Browser automation. The assistant drives the screen the way a person would: logs in, clicks, reads, types. It works, and it is genuinely the answer for portals. Be clear-eyed about it: it breaks when they redesign a page, it fights with two-factor prompts, and it needs its own monitoring. Browser automation on a system you do not control is a maintenance subscription, not a one-off build.
4. A human step. The assistant does everything up to the door: prepares the batch, drafts the message, fills the numbers. A person clicks the final button. This is the right answer far more often than the industry admits, particularly for anything that moves money.

The tell for a serious vendor or developer is whether they volunteer this list before you ask. Anyone selling you a connector count will find the awkward tool in your stack during week three, at your expense.

What it looks like once the plumbing holds

The reward for getting all four right is unremarkable, which is the point. My assistant reads my inbox before I do and tells me what actually needs me. It knows what is in my calendar and what I promised on a call last Thursday. It raises invoices in my finance system, chases the ones that go past due, and logs every touch. It reads and sends WhatsApp. Nothing irreversible happens without me, and nothing gets done twice.

My bias, stated up front: I did not build a bespoke set of connections for myself. I run Nora, which is my own product, and the connections to the common tools arrive already made and already maintained. The part worth taking from that is not the price. It is that expiry handling, permission scoping, retry logic and monitoring stop being a per-project build and become somebody’s standing job. Any managed assistant with a real trial gives you the same structural advantage, so discount the recommendation accordingly and go and compare a few. (Nora’s public terms, 26 July 2026: two-week free trial, from $59 a month.)

Custom connection work still earns its price, and I still build it. It earns it when a tool in your stack is genuinely yours alone, when compliance dictates where the data may travel, or when the workflow spanning those tools is the thing customers pay you for. It does not earn its price when you needed Gmail, a calendar and an invoicing tool wired together like everyone else.

Five questions to ask before you connect anything

Take these to any vendor on your shortlist, or to whoever is quoting you for the work. The answers separate people who have run these systems from people who have only sold them.

1. When a login expires, who finds out first, you or me?

The only good answer names a proactive check and an alert to a named human. “It will reconnect automatically” is not an answer; the whole failure mode is that reconnecting requires a person to click approve.

2. Show me the exact permission list for each tool.

Not a summary. The list. Then ask why each one is needed. Anything that permits permanent deletion or account-wide administration needs a specific justification, and “so we can add features later” is not one.

3. If it crashes halfway through a batch, what happens on restart?

You are listening for a record of what was already done, kept outside the tools it is acting on. If the answer is that it checks the tool to see whether the work is there, ask what happens when the tool has not caught up yet.

4. What happens when one of these tools changes?

Vendors deprecate, rename fields, and redesign pages. Ask who watches for that, how it gets noticed, and whether fixing it is included or billed. For anything driven through a browser, ask specifically.

5. Which of my tools are you not going to connect?

The single most useful question in the list. Anyone who answers “all of them” has not looked at your stack. You want the awkward one named in the first conversation, with a plan attached, not discovered halfway through the build.

What connection work actually costs

These are the bands I quote for the connection work itself, as a line item inside a larger build. Treat them as a sanity check on somebody else’s quote rather than a price list. Model usage and hosting sit on top and are usually modest by comparison.

A useful assistant across a normal SMB stack is five to eight connections, not one. That is why “connect our AI to our tools” projects land in the multi-system automation band rather than the chatbot band. For where a whole project lands, the 30-second cost estimator gives a range in three questions, and custom AI development and integration covers how a build-and-connect engagement runs week by week.

Two cost notes that people get wrong in opposite directions. Enterprise buyers assume the connections are the expensive part; they are usually not. Security review, sandbox environments, single sign-on, audit logging and waiting for access approvals are what stretch the budget, and none of that is engineering. Smaller buyers assume the opposite, that connecting is trivial because the vendor said so, and then pay for it in the four failures above. The realistic view sits between: connecting is cheap, keeping it connected is the actual product.

Frequently asked questions

Related reading

• AI assistant cost for small business: rent, commission or build
• What an AI employee really costs in 2026
• How to integrate AI into your business: the 2026 playbook
• Custom AI development in 2026: real costs and timelines
• AI employees: how they get set up
• AI automation agency services for SMBs
• The 30-second custom AI cost estimator