Why Your Team Barely Uses the AI You Bought: It Can’t Reach the Work

Almost every leader we’ve interviewed this autumn has asked for more AI: more Copilot seats, ChatGPT Enterprise for the sales team, an agent for finance because someone saw a demo. Ten minutes into the same conversation, the same leader tells us the AI they already have barely gets used.

The reason is the same every time. The tool they bought can see documents and email, and the work they want done lives in the ERP, the CRM, the ticket queue or the HR system. Nobody has connected the two, so people use the AI for emails and meeting summaries and leave it alone for everything else. Then the leader asks for a different tool, hoping that one can reach further.

It won’t, on its own. The connectors exist now, and the thing missing is a decision about what the AI may touch. That decision can only be made one task at a time.

Why Does the AI You Bought Go Unused?

Because it can only reach documents and email, and most of the work happens somewhere else.

Pull the usage report in the organisations we work with and the pattern repeats. A small group uses the tool every day, and most people have gone back to the odd question when they remember it’s there. The use that does happen clusters in the same places: meeting summaries, tidier emails, a first draft of a document. That is the work the tool can reach. Copilot sees your inbox, your calendar and your SharePoint. A ChatGPT seat sees whatever you paste into it. Neither can see the open orders in SAP, the pipeline in Salesforce, the tickets in ServiceNow or the candidates in Workday until someone connects it, and in most of the organisations we meet, nobody has.

So the AI sits beside the work. People use it for the parts of their day that happen in documents and give up on the rest. The leader looks at the usage report, decides the tool is wrong, and asks for a different one.

Can AI Agents Connect to Your Systems Yet?

Yes. This year the main business platforms started letting an AI agent in through a common standard, switched on by an administrator and limited to what the user could already see. Most of the leadership teams we meet haven’t caught up with that.

The standard is called MCP, the Model Context Protocol, and it works like a plug socket. A system publishes what an AI is allowed to do inside it, and any AI tool that speaks the standard can plug in. Salesforce made hosted MCP servers available to every Enterprise Edition customer in April. ServiceNow made its ITSM, ITOM, CMDB and SPM servers generally available on 10 September. Microsoft is rolling out a Tools page in the Microsoft 365 admin centre where an administrator can see every MCP server in the tenant and allow or block each one. In all three, the AI runs under the user’s own login and sees only what that person could already see.

So if the plumbing is there, why do the leaders we meet still say the agent can’t connect?

Because switching on the connector is the quick bit. Somebody still has to decide which systems the AI may read, which it may change, under whose login, and who takes the call when it gets something wrong. Your IT team is being asked to decide that for “AI agents” in general, and the honest answer to that question is no.

They’re right to say it. Nearly a third of organisations say an AI tool has already surfaced data it should never have reached (ShareGate, 2026). In the businesses we see, the cause is usually permissions that were too loose long before the AI arrived. An AI that runs under those permissions will reach whatever they already allow, including the folders nobody meant to leave open.

So when a leader tells us the agent can’t connect to their systems, what they usually mean is that nobody has decided what it’s allowed to connect to. And nobody can decide that in the abstract.

How Do You Get IT to Say Yes to an AI Agent?

Ask for one task, in one system, read-only, under the user’s own login. Put that in front of the same IT team and the answer changes.

An agent that reads open orders and delivery dates in the ERP, and drafts the Monday backlog note for the operations lead. Read-only access to two tables, under her login, with a log.

Now security can review it in an afternoon. IT can switch on one connector with one scope. The operations lead can be trained on that one note, in her real system, with her real orders. A month later you can check whether the note still gets made that way and what it took.

The three complaints we hear in every interview, no named task, no training on that task, and tools that can’t reach the systems, all come back to the first one. Without the task, the access can’t be scoped and the training has nothing to land on. With a task, both become routine.

Pick the system your team’s work lives in. Each one has a task that IT can say yes to this month.

We build these connections for clients and train the teams who use them. In that work, switching on the connector is quick. Getting the access decision made is slow, and it only gets made once someone names the task.

What to Do With the Next Licence Request

Make every request name a task, a system and an owner before anyone looks at the price. Then work through it in this order.

Next time someone asks for more licences, ask which task and which system. If they can answer, give them the access and the training, and watch it get used. If they can’t, the licence would have sat there too.

Sources & References

Frequently Asked Questions

Roy Murphy is co-founder of G3NR8. This post draws on G3NR8’s pre-programme leadership interviews in October and November 2026 (anonymised, no individual quoted) and the published research listed above. Published 6 November 2026.