I’ve read a lot of institutional AI RFQs over the past year, and a pattern keeps surfacing.
Institutions are asking for power-user AI capability across the entire campus: agentic workflows, coding assistants, advanced automation, sophisticated reasoning tools — the most capable systems available, for everyone.
If I formed my impression of higher education from procurement documents alone, I’d conclude that every campus was full of students vibe-coding their way through a degree.
That’s not what the usage data shows.
Across hundreds of thousands of interactions on our platform, the pattern has remained remarkably consistent.
Only about 5% of users move beyond the basics. Fewer than 1% ever reach a point where they need genuinely advanced capabilities. The most common question we see isn’t “How do I use this feature?” It’s “Where do I start?” and “How do I begin?”
And standing just behind those students are faculty members trying to figure out how to bring AI into a classroom in the first place.
There is a significant gap between the capability institutions are buying and the capability most people are actually using.
The more interesting question is why.
When I look at the data, I don’t see a population straining against the limits of their tools. I see people trying to take a first step.
They’re not asking for more sophisticated workflows. They’re asking what good AI use even looks like. They’re trying to build confidence. They’re trying to understand where AI fits into their work, their learning, and their teaching.
We keep evaluating AI platforms as though capability is the bottleneck.
The more time I spend in this space, the more convinced I am that adoption is the bottleneck. Not because the tools aren’t powerful enough. Because most people haven’t yet learned how to use the power that’s already available.
A tool nobody knows how to start using isn’t a powerful tool. It’s an expensive one.
Part of what makes this challenging is an assumption baked into how we buy technology: that institutional AI need is a single thing that can be satisfied by a single, sufficiently powerful platform.
It isn’t.
Demand has a shape. A small number of people — researchers, computational disciplines, developers, and advanced users — genuinely need sophisticated, agentic tooling, and they should have it. But they’re a sliver of any campus.
The overwhelming majority — students finding their footing, faculty redesigning assignments, staff automating routine work — need something different. They need a way in. They need guidance. They need a path to competence.
Buying for the most advanced use cases and deploying to an entire campus assumes everyone is solving the same problem. They aren’t.
And there’s a quieter tension that procurement rarely accounts for: every capability added for the power user introduces another layer of complexity for everyone else. A new concept. A new menu. A new piece of vocabulary. Another decision. The more sophisticated a platform becomes, the easier it is to drift away from where most people actually are.
Teaching and tooling are different disciplines.
Building software that helps people learn is fundamentally different from building software that helps experts move faster. A platform designed to teach makes different decisions everywhere: in what it shows first, in how it responds when a user gets stuck, in whether it explains itself or assumes prior knowledge.
Those choices aren’t features. They’re philosophy. And they shape adoption far more than another advanced capability ever will.
This is why I’ve stopped thinking about AI literacy as something that gets layered onto a platform after it’s selected. You can’t retrofit it. You can’t build AI literacy on a platform that was never designed to teach.
And literacy is ultimately what matters. If an institution optimizes only for the most capable platform, the best-case outcome is that it produces people who can operate powerful tools. That’s valuable. But it isn’t the purpose of education.
The purpose of education is to help people learn, develop judgment, and grow into capability over time. A campus that buys for raw power while neglecting the learning journey is solving the wrong problem impressively well.
Once you see the shape of demand clearly, the architecture follows naturally. It sorts into two distinct groups.
The many — students, faculty, staff — need a way in. They need to build confidence, learn what good AI use looks like, and grow steadily more capable over time. Their bottleneck is adoption.
The few — researchers, computational disciplines, developers — need depth. Agentic workflows, coding assistants, automation, the sharp edges. Their bottleneck is capability.
These aren’t the same need at different volumes. They’re different needs. And the moment you accept that, serving both through a single platform stops looking like efficiency and starts looking like a compromise that shortchanges both ends.
Start with where the people actually are.
For the overwhelming majority of a campus, the right environment isn’t the most powerful one — it’s the one built to teach. A place that meets a beginner at “where do I start?” and walks them forward. That explains itself. That treats getting stuck as a normal part of learning rather than a failure. That’s designed, end to end, around progression instead of raw capability.
This is the layer where adoption happens. It’s where AI literacy gets built — not as a workshop bolted on the side, but as the texture of the tool itself. And because it’s where almost everyone spends almost all of their time, it’s where an institution captures most of its value.
Get this layer right and you don’t just serve more people. You serve the ones the powerful-tool RFQs quietly overlook: the 95% who never make it past the basics today, and the faculty still trying to bring AI into their classrooms at all.
Then — deliberately, not by default — give the advanced users the advanced tools.
The researchers and developers whose work genuinely runs on agentic, code-heavy capability should have it without compromise. The operative word is targeted. This tier gets provisioned for the people whose work requires it, rather than deployed across the whole campus on the theory that more power is always better.
That one decision — depth for the few, not for all — is what keeps the foundation simple enough for the many to actually use. Every advanced feature you don’t force onto a beginner is a layer of complexity they never have to wade through.
The two tiers end up protecting each other. The few get their depth. The many keep their on-ramp.
Designing this way pays off on the three things institutions actually care about.
Adoption. You serve the part of the curve where almost everyone lives, instead of optimizing for the tail. More people use AI, more of them use it well, and more of them keep using it.
Cost. You stop paying power-user prices for an entire campus that, by the data, will never touch power-user features. Capability gets bought for the people who need it — not spread across everyone as an expensive hedge.
Mission. Literacy stops being an afterthought and becomes the design center. You graduate people who learned to think with AI, not just operate it — which is, after all, the point of an institution that exists to teach.
None of this requires choosing between serving the many and serving the few. That’s the whole point of matching the architecture to the shape: you stop trading one against the other.
So if I could change one thing about how institutions buy AI, it would be this: stop writing the RFQ as though you’re buying a single, maximally powerful platform. You’re not buying one thing. You’re meeting two needs.
Which means the next RFQ probably shouldn’t ask one question. It should ask two.
Buy for the shape of the demand, and you can answer both honestly.
Buy for the most powerful platform, and you’ll keep solving the wrong problem impressively well.
Tool access isn’t literacy. Capability isn’t confidence. The institutions that understand the difference will capture far more value from AI than those that simply buy the most powerful tool.
That’s the architecture I think the next few years of institutional AI will be built on. Not one platform to rule them all — but a thoughtful pairing that finally meets people where they are, and still gives the few room to run.
Kisa Brostrom | Chief Technology Officer, BoodleBox
Kisa Brostrom leads AI systems architecture, data strategy, and platform governance at BoodleBox. With over a decade of experience in data engineering, applied machine learning, and distributed systems design, she has spent her career building scalable, privacy-aligned AI infrastructure in startup and growth-stage environments — the kind of environments where the gap between what technology can do and what people actually use it for is most visible.
At BoodleBox, Kisa has led the development of a privacy-first AI platform serving 100,000+ learners across 1,300+ institutions, including a sustainability-focused token-reduction architecture that makes equitable access to AI practical at institutional scale. She works daily at the intersection of what AI can do and what it should do for the people trying to learn with it.
The observations in this piece are drawn from that platform data and from years of watching institutions navigate the gap between AI procurement and AI adoption.
Download the full executive briefing — The Two-Tier Institutional AI Architecture — a free resource for CIOs, Provosts, and CFOs evaluating campus-wide AI strategy. Includes the enterprise cost cases, a two-tier architecture framework, cost comparison modeling for a 50,000-FTE institution, and a governance structure you can bring to your board.
Download the full executive briefing — The Two-Tier Institutional AI Architecture — a free resource for CIOs, Provosts, and CFOs evaluating campus-wide AI strategy. Includes the enterprise cost cases, a two-tier architecture framework, cost comparison modeling for a 50,000-FTE institution, and a governance structure you can bring to your board.
Learn more about the ins and outs of the BoodleBox workspace from our team of experts.
Schedule a meetingLooking for more information?
