The Short Answer
Higher education's next move is owning AI infrastructure rather than renting chatbot seats. ibl.ai is the agentic AI platform where you own all the code and the data: you self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped campus network.
The first wave of campus AI is finished, and it was an adoption wave. Licenses were bought, widgets were embedded, and usage went up.
What did not follow was change in the numbers institutions actually manage: advising load, time-to-degree, yield. This post is about why, and what the second wave requires.
Why hasn't AI adoption in higher education produced measurable results?
Because adoption and infrastructure are different purchases, and higher education has overwhelmingly made the first one.
The survey data shows the gap plainly. Ellucian's third annual higher education AI survey, published March 2026, found 66% of institutions currently leveraging AI — up from 49% a year earlier — and 90% of individuals using it personally, up from 84%.
Then the same survey asks whether AI appears in the institution's strategic plan. The answer is 43%.
Coursera's 2026 research narrows it further: only 26% of educators say their university has a formal policy governing AI use.
Two-thirds are using it. Fewer than half have planned for it. A quarter have written down the rules. That ladder — 66 to 43 to 26 — is the signature of technology arriving as a subscription rather than as infrastructure.
The consequences show up as things that did not improve.
Advising queues do not shorten when the assistant cannot read a degree audit. Course development does not accelerate when the tool cannot see the LMS. Yield does not move when the prospective-student chat returns what the website FAQ already said.
None of that is a model problem. GPT, Claude, Gemini, Llama — any of them can hold the conversation.
The limitation is that the model has no connection to institutional data, no memory of the individual student, and no permission to act in the systems where the work actually happens.
What is the difference between adopting AI and owning AI infrastructure?
Adoption is buying access to someone else's system. Infrastructure is running your own, and the distinction is visible in three places.
Data integration without extraction. Institutions that get results connect agents to Banner, PeopleSoft, Canvas, and Slate in place, through MCP connectors that expose records under role-based access control. The agent reads a degree audit, checks seat availability, and verifies aid status without student records leaving the institution's perimeter. A vendor-hosted assistant inverts this: your data goes to the model.
Purpose-built agents instead of a general chat box. An advising agent that encodes your prerequisite chains and transfer-credit policy behaves differently from a general assistant with a long system prompt. On ibl.ai those agents carry Agent Skills — reusable, versioned playbooks written by the people who know the policy, assigned per agent and invoked from a slash-command picker.
Model agnosticism as a routing decision. When the platform is not welded to one provider, work routes by fit: a reasoning model for a complex financial-aid appeal, a cheap fast model for "when does registration open," and an open-weight model running on campus hardware for FERPA-sensitive advising that should never traverse the public internet.
That last one is only possible if the deployment target is yours. This is the practical meaning of ownership — not a philosophical preference, but the set of options that remain available to you.
How much does per-seat AI actually cost a university at scale?
Per-seat pricing is not merely expensive at scale — it is the wrong shape, because it bills headcount instead of usage, and a university's headcount has nothing to do with how much AI it consumes.
The arithmetic is unforgiving. At a $30 per user per month list price, the annual bill scales straight off enrollment:
| Institution size | Per-seat @ $30/user/mo | What it still can't do |
|---|---|---|
| 10,000 students | $3,600,000 / yr | Read your SIS |
| 25,000 students | $9,000,000 / yr | Remember a student |
| 50,000 students | $18,000,000 / yr | Switch models |
| ibl.ai (owned) | One-time license + tokens used | — |
Every row in that first column is paid whether or not the seat is used. A student who asks nothing all semester costs the same as one who asks daily.
ibl.ai charges for consumption instead: credits against a budget cap the institution sets, pooled across every user, model, and agent.
Enterprise engagements are one-time rather than recurring — a pilot from $15K, full integration and deployment at $25K–$80K, or a six-figure codebase transfer that hands over the full source under a perpetual license.
After that the ongoing cost is tokens and infrastructure.
The deeper point is not the discount. It is that a usage-based bill lets a university expand AI to every student without the budget scaling linearly with the student body — which is exactly the expansion a per-seat contract discourages.
For the full model, see the per-seat versus usage math for higher education.
What should a university ask its current AI vendor?
Five questions separate a chatbot subscription from infrastructure. Each one has a yes/no answer, and a vendor's discomfort is itself informative.
- Can your AI query our SIS in real time — a specific student's degree progress, aid status, and course history — without exporting records to a third-party cloud?
- Does your AI remember individual students across conversations, semesters, and touchpoints, with memory scoped to our privacy policy?
- Can we switch the underlying model without changing integrations, retraining staff, or reopening the contract?
- Do we own the source code — or do we lose the capability if pricing changes, a feature is deprecated, or the company is acquired?
- Can we deploy on our own servers, including air-gapped environments for research data, FERPA-sensitive advising, or ITAR-controlled programs?
A "no" to any of these means the institution adopted a chatbot. That is not a failure — it was the correct first step — but it is not infrastructure, and it will not produce infrastructure-shaped results.
What does owning the AI stack actually require?
Less than most procurement teams assume, because the hard part was never the model.
Two recent additions make the point.
Code Mode is a coding agent inside Agentic OS that scaffolds a working application from a single prompt — it generates the app from the Agentic Vibe starter, installs components, wires data connections, and runs it, with every tool call gated behind explicit approval.
A department that needs a graduate-admissions tracker gets a working prototype in one conversation rather than a six-month IT project and an RFP.
Agent Skills supplies the other half: an organization-wide catalog of reusable playbooks, assignable per agent, so capability accumulates as an institutional asset instead of living in one person's prompt history.
The result is that universities compose AI capability the way they compose curricula — modularly, deliberately, and under their own governance.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University, and it deploys on any cloud, on-premise, GovCloud, or fully air-gapped.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.
The first wave was adoption. The second is ownership, and it is measured in what your institution can still change two years from now.
Related reading: AI agents for higher education that universities can own and the ibl.ai higher education solution.