If you handed every person on your team an AI coworker tomorrow, how much of their job could it actually touch?
Most companies have decided they need to become AI-native. Far fewer have a clear picture of what that actually takes.
The usual first move is to buy everyone a seat at a chat tool and wait for the productivity to show up. Some of it does. Then it stalls — and when it stalls, the problem is rarely the AI. Today’s models are more than capable of doing the analytical work your team does every day. What they can’t do is reach it. The conversations, the configurations, the dashboards, the queues, the history: all of it lives inside software your vendors control, and how much of it your AI can touch is a decision those vendors have already made on your behalf.
A quick distinction, since two different projects go by the same name. This isn’t about the agents you build and ship — chatbots, voice assistants, automations whose scope somebody designs up front. It’s about the AI coworker your ops manager or analyst works alongside on whatever landed on their desk this morning, where nobody scoped the job in advance because it didn’t exist until they asked. That’s what an AI-native organization runs on, and it’s the harder of the two to support.
So how does an AI coworker get into your systems? The typical answer is an MCP connector.
There’s been no shortage of criticism aimed at MCP over the past year, most of it from engineers. Tool definitions eat up the AI’s working memory before the conversation even starts. The security model has rough edges. Both complaints are fair, and both are being actively worked on. Neither is the reason your AI-native plans will stall.
The reason is structural, and to see it you have to look at what a typical MCP connector actually is: a set of tools your vendor hosts, that your AI calls over the internet, and that hands back its answers by talking. That last part is the whole ballgame.
Once you can see why that matters, you’ll be able to ask your software vendors far better questions than “do you have an MCP?” — which is what nearly everyone is asking right now, and which tells you remarkably little about whether their product will actually carry your team into an AI-native way of working. Those questions are at the end of this article, and they’re the most useful thing in it. They just don’t mean much until you’ve seen what a typical connector can and can’t do.
Two ordinary tasks
To keep this concrete, here are two jobs somebody on your team already does. We’ll come back to them throughout.
Find the themes. Your analyst wants to know what customers were actually unhappy about last month. Not a ticket count — the themes. That means going through last month’s conversations, a hundred or so, grouping the complaints, ranking them, and noting which queues they came through. A person can absolutely do this. It takes the better part of a day, which is why it happens quarterly instead of weekly.
Fix the bot. The return policy changed, so your AI agent’s configuration needs reworking — the greeting, a few intents, the escalation rules, the fallbacks. Hundreds of lines of interlocking detail, and it usually takes a few passes to get right. Get one rule wrong and the wrong customers start getting escalated.
Both are exactly the kind of work an AI coworker ought to take off your team’s hands. Note too that one is mostly reading and the other is mostly writing — a distinction worth holding on to.
With MCP, Everything happens in the conversation
By now, most of you are probably familiar with the concept of an AI’s context window. This is basically its working memory for your conversation. It’s filled with various things:
As a conversation progresses, the window gradually fills up. In general, you want it used judiciously: as it fills, the AI’s intelligence can become muddled — a phenomenon known as context rot — and if it gets totally maxed out you’re kinda SOL. On top of that, it’s just plain expensive. Unfortunately, MCP tools are unusually greedy with it. Everything going into a tool and everything coming back out lands in the context window exactly like a message does, only these are frequently much, much larger.
Now, the fact that MCP tool calls can chew through a lot of context is well-known and isn’t necessarily a deal breaker in of itself. It’s more of a bummer, especially if you’re remotely concerned about token costs. But, what truly bites is actually a downstream consequence of MCP tools doing everything in-conversation: it’s effectively asking the AI to do everything in its head. This generally works fine for linguistic tasks, but is perilous when it comes to doing mathematical things or modifying complex configurations.
To see how strange that is, imagine Find the themes landed on your desk — and you had to do it the way a typical MCP connector makes an AI do it.
A colleague reads last month’s conversations aloud to you. All hundred of them, cover to cover — the ones about refunds and the ones about nothing at all. You can’t skim and you can’t search; you just listen. You may not take notes. Everything you’ve heard is still in your head somewhere, but that’s recall, not looking something up — and by the eightieth conversation, the first ten are a blur. When the reading stops, you’re asked: how many mentioned a delayed refund, what were the top five themes, and which queue did most of them come through? Answer from memory, and be precise, because your numbers are going in a board deck.
Then it’s time to Fix the bot. There’s no document to mark up and hand back. The only way to submit a change is to recite the entire configuration out loud, from the top — every greeting, every intent, every rule, every fallback, in order, word-perfect, in one take. Drop a line and nothing announces itself. You’ll hear “saved,” and you’ll find out a week later, when the wrong customers start getting escalated.
Then you reread it and want to reword two sentences. Recite the whole thing again.
Nobody would design a job this way. And notice the problem isn’t that the person in the chair is slow or careless — it’s that every part of the job has been forced to happen verbally. No files, no word processor, no spreadsheet, no Ctrl-F — and you asked for precision anyway.
That is, more or less exactly, how a typical MCP connector makes your AI work — and you pay for it three times over. In accuracy, because the answer comes out of memory rather than out of a calculation. In time, above all when writing — taking a hundred conversations in is quick, but reciting a configuration back out happens one word at a time, and happens again on every revision. And in cost, because every one of those words is billed, and goes on being billed for the rest of the conversation.
Giving AI a Workspace
The most obvious fix for all of this is also the most powerful one: stop making the AI do everything verbally. Give it somewhere to work.
That’s what a workspace is — somewhere outside the conversation where the AI can keep files, run a bit of code, and set things down. In Claude Code, your laptop is the workspace. In claude.ai or chatgpt.com, it’s a sandboxed environment running in the cloud. Some AI products have one, some don’t.
And this is worth pausing on, because it’s a decision you make, not your software vendors. Make sure the AI your company standardizes on comes with a workspace. It matters more than benchmark scores or which model is cleverest this month. It has nothing to do with MCP, or with any of your vendors’ connectors. It’s a property of the AI tool itself, and it is an essential power-up either way.
Give it one and four things change:
It can set things down. Notes, drafts, working results — anything the AI produces can live in a file instead of in the conversation. And it can go back and read that file exactly, rather than trying to remember what it wrote an hour ago. Looking something up, instead of recalling it.
It can search. Ctrl-F, essentially — across its own notes, its drafts, anything it’s collected along the way. Finding a line in a file is a lookup. Finding it in the conversation is a memory test.
It can be exact. Rather than counting in its head, the AI writes a few lines of code and runs them. The answer now comes from a computer doing arithmetic, which is a thing computers are known to be good at, instead of from an AI recalling what it heard an hour ago.
Scale stops mattering so much. A hundred conversations or a hundred thousand — if they’re sitting in a file rather than in the window, the difference is a few seconds of processing rather than the difference between possible and impossible.
That’s the files, the search, the spreadsheet, and the desk they all sit on, handed back. It’s a genuinely enormous upgrade — and it’s much of why AI coding tools got good before anything else did: engineers were already working in an environment that had all of it lying around.
So the question arises: since workspaces are so great, am I all set if my SaaS provider has an MCP connector and my AI has a workspace?
Better. But no.
Go back to the person in the chair. You’ve given them a desk now, and a notepad, and a spreadsheet, and Ctrl-F — everything we just said they were missing. But your colleague still reads all hundred conversations aloud, and the only way to get any of it onto that desk is to transcribe every word by hand while they read. And when the escalation rules need changing, the desk doesn’t help submit it: they still have to read the finished document back out loud, in full, costing both time and tokens.
That’s a typical MCP connector plus a workspace. There’s still exactly one route in or out — the conversation — so you have both of the problems you started with, although lessened. It still chews through the context window, because everything crossing the boundary lands there first on the way through. And it still rests on flawless recitation of data into the workspace.
What you’ve gained is real: once something is in the workspace it stays there, and it can be manipulated and analyzed properly. What you haven’t gained is any way to move something large without saying every word of it out loud, in the conversation
MCP: A conversation connector, not a workspace connector
Here’s the thing most of the hot takes miss. Every problem above traces back to a single design decision, and it isn’t a defect: MCP connects your platform to the AI’s conversation, not its workspace.
Everything else follows from that. By default, data arrives by being said out loud, and changes are made by being said out loud. So the window fills up, and anything you want to change has to be reproduced word for word, in one pass. Drop a line and nothing announces itself — you get a green checkmark and a subtly wrong bot.
Which puts a ceiling on what a platform can expose at all. It isn’t that MCP is inefficient — it’s that a conversation connector can only carry what’s small enough to say out loud. And the things worth handing to an AI in an enterprise system are the big ones: an agent’s full definition, a dashboard with two dozen widgets, a routing ruleset that took three people a week to agree on. Those capabilities don’t become slow. They become unavailable.
What you’d want instead is a workspace connector — one that meets the AI where it can actually work.
With one, data moves from your platform into the workspace directly. The conversation carries the instruction — pull last month’s conversations — and nothing else. A hundred transcripts land in a file. The AI then does what you’d do with a folder of files on your laptop: searches them, counts them, keeps the twelve that matter. The window holds just your instruction or the data that the AI actually needed to analyze verbally, no matter how much data was actually transferred, and numerical analysis is done precisely with code/scripts rather than in the AI’s noggin.
Picture it with the person in the chair one last time. Instead of reading a hundred conversations aloud, your colleague emails them to you. You Ctrl-F your way to the twelve that matter and ignore the rest. And when you’ve reworked the escalation rules, you upload the file — you don’t read it down the phone to somebody who types it back in on the other end. That’s the whole fix, and it’s how every office on earth has worked for years.
Solutions
None of this demands a particular technology. What it demands is that the connection meet the AI in its workspace rather than in its chat window. Anything that does that qualifies — and there are three roads there, at different stages of maturity.
1. Better MCP connectors
The first is for vendors to build the best conversation connector they can, working around the limitation wherever possible. Instead of reciting a hundred transcripts, hand back a link and let the workspace fetch the file. Instead of accepting a whole configuration as an argument, hand out an upload URL and take a reference to the finished file. Offer narrow, precise operations so the AI can change one rule without restating the other two hundred.
This genuinely helps, and the better vendors are doing it. But every one of these is a workaround bolted onto a conversation connector, built one case at a time, covering only the situations somebody thought to anticipate. It raises the ceiling. It doesn’t remove it.
2. A CLI
The second is for the vendor to ship a CLI (command line interface) — a small program that runs inside the AI’s workspace and does its work there rather than talking through the chat. This is a workspace connector by construction rather than by workaround.
Give the AI one and the awkward parts stop being awkward. Bulk data lands in a file rather than in the window. Calculations get calculated. A configuration gets written out, revised in place, and submitted with one short instruction pointing at the file. The AI still reads whatever parts of it it needs to — the difference is that it reads what’s useful, instead of being forced to carry the whole thing through the conversation twice. And because a CLI is real software rather than a dumb pipe, it can validate before it sends and fail with an error that actually says something.
The objection people raise is that a CLI sounds like a developer thing, only usable in developer tools. That’s less true than it looks. Any AI product with a workspace can install and run one — including the hosted sandboxes behind claude.ai and its equivalents — and the AI drives it, not your team. Nobody in your CX org has to open a terminal. They ask a question; the AI runs the command. It’s merely another form of connector, one that is strictly superior when it comes to data transfer.
3. Code mode, if it arrives
The third isn’t here yet, but it’s worth watching. Anthropic and others have published a pattern — usually called code mode — where the AI is handed the connector’s tools as code it can call from inside its workspace, rather than as things it talks to in the conversation. Bulk data never materializes in the conversation at all. It’s a genuine fix, and note what it concedes: the answer to a conversation connector is to stop using it like one.
Today it’s mostly confined to development tools and purpose-built agents. If the mainstream AI products your team actually uses adopt it, it would lift every typical connector at once, without those vendors changing a thing. That would be a very good outcome — and it’s entirely out of your software vendors’ hands, and yours.
Make sure your vendors are targeting a fully AI-native future
As your organization attempts to become increasingly AI-native, how far you actually get will depend less on which AI you buy than on how accessible your software vendors are to it. Your AI is only as capable as the systems you let it work in — and right now, most of the systems your team lives in all day were built on the assumption that a human would be the one clicking around.
Which makes “do you have an MCP?” a weaker question than it sounds. A yes tells you a connector exists. It doesn’t tell you what’s on the other side of it — and there are two quite different disappointments hiding behind that answer.
The first is the ceiling this whole article is about. A connector that works through the conversation will always be limited to what can be said out loud, however well it’s built.
The second is more mundane and more common: plenty of connectors expose a thin slice of the product. A few read-only lookups, the handful of endpoints somebody had time to wrap, and nothing like the range of things you can do in the app yourself. It’s a demo, not a platform.
So here are better questions. The first is for whoever chooses your AI tooling. The rest are for your software vendors.
1. Does our AI have a workspace — including in the restricted setups our people actually use?
Not just in the developer tools. If your team lives in claude.ai, Claude Desktop, or a locked-down enterprise deployment, does the AI still get somewhere to put files and run a calculation? A workspace that exists only for engineers isn’t a workspace for your organization.
2. How much of the platform does the connector actually cover?
Ask for the list. A connector with six read-only lookups is a demo. What you want to hear is that the connector reaches most of what a person can do in the product — and if it doesn’t yet, a specific plan for the rest.
3. If it’s built on MCP, does it push work into the workspace instead of the conversation?
This is the question almost nobody asks, and it separates a thoughtfully-built connector from a checkbox. Does it hand back a link and let the AI fetch the data, rather than reciting it? Is there any path for large things to go in that doesn’t involve the AI retyping them? A vendor who has thought about this will know exactly what you’re asking. A vendor who hasn’t will tell you again that they have an MCP.
4. Could an AI coworker do what my people can do in the web app?
The one that matters most. Not will it, and not with identical permissions — but is it possible? If there’s work your team does every day that no AI could ever perform through the connector, you’ve found your ceiling, and no amount of model improvement will raise it. That’s the bar software engineering already cleared, and it’s the bar an AI-native organization needs its vendors to clear too.
At Quiq, we’re committed to making 100% of our platform natively accessible to your AI. The goal is that the people who run CX get to experience the same quantum leap in efficiency that software engineering just went through. Engineers didn’t get there first because they’re smarter. They got there first because their tools were already open, and their AI could work the way they do.
Everyone else deserves the same.
