The Context Bottleneck: Why the AI Conversation Just Shifted, and What It Means for IT Support

The smartest people in AI keep converging on the same point: the model isn’t the bottleneck anymore. What the agent knows about your specific environment is.

• Three of the most-followed voices in enterprise AI (Aaron Levie, Chamath Palihapitiya, Garry Tan) all landed on the same point within days of each other, in late May and early June 2026: models are smart enough already, the missing piece is company-specific context.
• IT support has the worst version of this problem. Every customer environment is different, senior engineers carry tribal knowledge nobody wrote down, and half of what’s documented is already stale.
• SuperIT’s answer is two connected assets: a Digital Twin that holds the live state of each customer’s environment, and an automatically curated knowledge base, structured as a library of agent skills, that codifies how your engineers actually solve problems, both sharpened by every ticket resolved.
• This is the moat, not a feature. Models commoditise and get cheaper every year. The structured knowledge of your specific service desk doesn’t, and it compounds with every ticket your team closes.
• The vendor question that matters going forward isn’t “how smart is your model.” It’s “how do you capture and maintain the context specific to my customers, and what happens to it if I switch vendors.”

Something interesting happened on the AI timeline in late May and early June 2026. Inside a 48-hour window, three of the most-followed voices in enterprise AI all posted the same observation, in slightly different words.

Aaron Levie, the CEO of Box, said the number one problem for AI agents in the enterprise is context. The model is fine. The company-specific knowledge it needs is fragmented across legacy systems, locked behind broken access controls, or trapped in people’s heads.

Chamath Palihapitiya said the same thing, agreeing publicly that the models are smart enough already and that what enterprises need is “a control plane that organises the tribal knowledge while also providing governance, safety and control.”

Garry Tan said it even more directly: “This is the actual bottleneck. The models are smart enough already. What is missing is the company-specific context locked in senior people’s heads.” He put the sharper version in the same breath: “Imagine replacing 90% of your employees with a team of geniuses who have no idea how your company operates. Total chaos. Nothing works. That’s what AI feels like today.”

You don’t usually get three serious operators saying the same thing within days of each other unless something is actually shifting. So this is worth taking seriously, and worth explaining what it means for the people running MSPs and internal IT service desks, because it reshapes what a good AI investment looks like in our industry.

What “the model isn’t the bottleneck” actually means

For the last two years, the AI conversation has been dominated by which model is best. GPT vs Claude vs Gemini. Reasoning benchmarks. Million-token context windows. Benchmark wars between vendors. The public narrative has been “AI is improving fast,” and the implicit assumption underneath that was “and when it gets smart enough, the rest will follow.”

What Levie, Chamath, and Tan are all saying, and what anyone shipping AI in production is now saying out loud, is that the rest has not followed. The models did get smart enough. The smartest models available today are dramatically more capable than the ones from twelve months ago. But the businesses trying to deploy them are not seeing the productivity gains the benchmarks promised.

The reason is not the model. It’s that a brilliant engineer who has no idea how your business actually operates isn’t a useful one.

Aaron Levie’s phrasing of this is worth quoting directly because it lands the point cleanly:

“As we go from agentic coding (where a large amount of context is in the code base, and users are technical enough to get the rest to the agent easily) to a world of knowledge work agents, the context problem becomes much more acute… companies often haven’t captured and digitised some of the critical context that agents need to work with. Decisions, processes, and workflows often live in people’s heads and tribal knowledge that need to get turned into unstructured data for agents.”

— Aaron Levie, June 1 2026

That’s the bottleneck: not raw intelligence or capability, but the plumbing connecting general intelligence to the specific reality of the business it’s supposed to operate inside.

Why this lands harder in IT support than almost anywhere else

There are very few categories of work where the context problem is as severe as it is in IT support. A few reasons.

No two customer environments are the same. An MSP looking after thirty SMBs is looking after thirty different Microsoft 365 tenancies, thirty different network topologies, thirty different mixes of line-of-business software, thirty different versions of the same workflow (how do we onboard a new starter) that have evolved differently inside each customer. The general intelligence of the model doesn’t know any of this. It can’t. The information was never written down.

The senior engineer’s value is mostly tacit. A great Level 3 engineer doesn’t follow a playbook for the hard tickets. They remember that this particular customer’s VPN client has a quirk that only shows up on Tuesdays after the patching window. They remember that the user who just filed the ticket is the CEO’s PA and the queue priority is implicit. They remember that the workaround they used last time turned into a permanent fix that nobody documented. All of that lives in their head. Most of it was never going to live anywhere else.

The artifacts that exist are wrong half the time. Your IT documentation tool has entries from 2021 that haven’t been updated. Your CMDB lists devices that were decommissioned. Your PSA has ticket notes that solved the problem but never made it back into the knowledge base because the engineer was already on the next ticket. The written record exists, and the written record is partially stale, and a general-purpose AI reading it without the live context will confidently apply the stale answer.

The work happens fast. A ticket about a stuck print queue needs an answer in minutes, not hours. There’s no time for an agent to do open-ended research. It either has the right context cached, or it’s making a guess on the customer’s machine.

This is the version of the context problem that Aaron Levie is describing, made unusually severe by the structure of MSP work. It’s why a chatbot trained on general IT knowledge doesn’t actually resolve tickets, even when the model behind it is excellent. The model has no idea who this user is, what device they’re on, what their environment looks like, or what the MSP’s specific way of handling this issue has been historically.

The brilliant engineer arrives, looks around the office, and has no idea where anything is.

The SuperIT answer: the Digital Twin plus the automatically curated knowledge base

Most of how we’ve designed SuperIT is a direct answer to exactly this problem, and the design pre-dates this industry consensus by years. We didn’t see Levie’s post and pivot. We built the architecture this way from the start because our founders had spent careers running service desks and could see clearly that any AI in this space would live or die on context.

The two pieces of the architecture that solve the context bottleneck are the Digital Twin and the automatically curated knowledge base, and they work together.

The Digital Twin is the live state of the environment. Continuously updated. It knows what devices exist, which users own which devices, which apps are installed where, what versions, what’s running, what the network topology looks like, which users have what level of access to what systems. It’s a graph that grows and shifts as the environment grows and shifts. When SuperIT picks up a ticket, the Digital Twin is what tells it the situation: who this user is, what they’re on, what the relevant moving parts are.

The Digital Twin is what’s missing from a generic AI assistant. The smartest model in the world, asked to solve “Sarah’s Outlook is slow,” will start asking Sarah questions to gather context. SuperIT already knows who Sarah is, what laptop she’s on, what add-ins she has installed, which of those add-ins crashed yesterday, and what shared mailboxes she’s connected to. It can start at “let me check the most likely cause first” instead of at “tell me about your computer.”

The knowledge base is the codified way work gets done at this specific desk, and it doesn’t start from nothing. It starts from whatever the desk already has, its existing articles, however thin, and SuperIT continuously folds in the history of resolved tickets on top: updating what’s there, writing new articles where there’s a gap, and retiring what’s gone stale, every day rather than once at onboarding. It’s structured as a library of agent skills: every routine, password reset and verify, clear a stuck print queue, diagnose a Wi-Fi issue, onboard a new starter, ends up as a defined procedure with checks, allowed actions, and completion criteria, curated rather than improvised. SuperIT does not freelance on production environments. It picks a skill that fits the situation, runs that skill, and stays inside the skill’s boundaries.

That’s where the senior engineer’s tacit knowledge gets captured. Not all at once. Not in a big documentation project. Continuously, as a side effect of work getting done, with a person verifying and validating the result before it’s trusted. Every resolved ticket either confirms an existing skill, sharpens it with an edge case, or surfaces a gap that becomes a new one. The knowledge base that handled your tickets in month six is materially better than the one that handled them in month one. The improvement isn’t because we shipped a new version of SuperIT. The improvement is because your service desk’s actual work has been continuously feeding it.

This is what Chamath was describing when he talked about “a control plane that organises the tribal knowledge while also providing governance, safety and control.” For our industry, that’s the Digital Twin plus the curated knowledge base running together, inside a safety pipeline that the MSP controls.

Why this is the moat, not a feature

The reason this matters for the business decision in front of an MSP or IT leader is that this kind of asset compounds in a way that almost nothing else in the AI stack does.

Models commoditise. The frontier model from eighteen months ago costs a fraction of what it did then. The next frontier model will be better and cheaper still. If your AI strategy depends on having access to the best model, you have no strategy, because everyone has access to the best model.

What does not commoditise is the structured knowledge of your specific service desk. The Digital Twin of your customer environments. The knowledge base, structured as a library of skills, that codifies how your senior engineers actually solve problems. Those things are unique to your business, they took real time to develop, and they get more valuable with every ticket your team resolves. They are an asset on your balance sheet, in the sense that matters.

This is also why competitors who built their tools as pure API orchestration layers, sit on top of a PSA, sit on top of an RMM, send the ticket text to a model, dump the answer back into the ticket, cannot replicate this. The architecture doesn’t support it. They can read the ticket. They cannot maintain a live state model of the customer environment, because they don’t have agents on the endpoints to maintain it. They cannot accumulate per-customer, per-engineer memory because they weren’t designed to.

The other implication is one we’ve talked to MSP and IT leaders about repeatedly. The right question to ask any AI vendor in this space is not “how smart is your model.” Every vendor uses the same family of models. The right question is: how do you capture and maintain the context that’s specific to my customers, and what happens to that context if I switch vendors? If the answer is “we don’t really maintain it” or “the context lives in the model provider’s storage,” that’s not an asset, it’s a rental.

What this means for the next twelve months

The industry just had a moment where three influential people landed on the same insight at the same time. That’s usually a signal that the conversation has shifted, and the early-mover advantage on “context as the bottleneck” is closing fast.

For MSPs and internal IT teams, this means the AI investment decision in the next twelve months will increasingly be evaluated on context architecture, not model quality. Buyers who ask “how smart is the model” will buy products that don’t deliver. Buyers who ask “how does this system learn my customers, capture my engineers’ knowledge, and stay current as my business changes” will get something that compounds.

Our bet, for what it’s worth, is that the MSPs who win the next phase are the ones whose AI investment turns into a structured, executable record of how their service desk actually works, that runs autonomously where it can and hands off cleanly where it can’t. That record is the asset. Everything else is plumbing.

The resolution rate we can hit is a direct consequence of the architecture we’ve described here. Take the Digital Twin or the curated knowledge base away, and it doesn’t hold. The models do not pick up the slack.

The bottleneck has shifted. The vendors who recognise it are building one kind of product; the ones who haven’t are still benchmarking model performance. Both will ship next year, and only one will be solving the right problem.

Want to see what your own environment looks like inside a Digital Twin? Book a demo and we’ll show you against your own queue.