The Short Answer
A university needs an AI Platform Team because AI bought one department at a time leaves it with separate contracts, data pipelines and security reviews it cannot govern. The team runs one shared platform and its policies centrally, while engineers embedded in each office build that office's agents. On ibl.ai you own all the code and the data, so the platform stays the university's.
The model comes from enterprise IT, where Superblocks CEO Brad Menezes described it on 10 November 2026 after speaking with "hundreds of CIOs, CISOs, and Heads of AI".
Universities are earlier on the curve: only 22% of respondents in the 2025 EDUCAUSE AI Landscape Study reported an institution-wide AI strategy.
This page maps that operating model onto a university org chart: who sits centrally, who embeds in which office, and what the alternative of departmental buying costs.
What is an AI Platform Team?
An AI Platform Team is a central group that owns the shared AI platform and its governance, while each business unit has its own forward-deployed engineers who build on that platform.
Brad Menezes, founder and CEO of the enterprise software company Superblocks, put it in one line.
His words, from a post that opens "The rise of the AI Platform Team.": "centralize the platform and governance, embed internal FDEs in the business." FDE stands for forward-deployed engineer, a role that sits with the people doing the work rather than in a central backlog.
The AI Platform Team model has two halves, and both matter. Centralizing alone produces a committee that departments route around. Embedding alone produces a dozen teams building on a dozen stacks. The pairing is what makes the model work.
Why are universities buying AI one department at a time?
Universities buy AI one department at a time because nobody owns the institution-wide decision. EdScoop's report on the 2025 EDUCAUSE AI Landscape Study put a number on it.
Fifty-five percent of respondents said AI strategy was being rolled out "on an ad-hoc basis in various colleges and departments." Only 22% said their schools had implemented institution-wide AI strategies.
In practice, ad hoc looks like this: admissions licenses a chatbot for applicant questions, advising pilots a different agent, the library trials a research assistant and IT deploys a help-desk bot.
Each office runs its own procurement, its own security review and its own data feed.
None of those decisions is wrong on its own. The problem is the sum: a university that cannot say which agents exist, what student data each one reads, or which model vendor processes it.
| What the university has to manage | Four departmental purchases | One platform with an AI Platform Team |
|---|---|---|
| Vendor contracts | 4 | 1 |
| Security and privacy reviews | 4, one per tool | 1 for the platform, then per-agent configuration |
| Copies of SIS and LMS data | Up to 4, one per vendor pipeline | Shared connections every agent reads through |
| Model choice | Whatever each vendor bundled | Set centrally, switchable per agent |
| Audit trail | 4 formats, 4 consoles | One log across every agent |
What does departmental AI cost a university when it is priced per seat?
Departmental AI costs a university the most when each tool is priced per seat, because per-seat pricing is the wrong shape for a campus. The bill scales with headcount whether staff use the tool daily or never.
Microsoft lists Microsoft 365 Copilot for education at $18 per user per month, the academic price for faculty and staff (the commercial list price is $30).
The arithmetic below uses only that list price; it is not a quote for any institution.
| Staff seats licensed | Per month at $18/seat | Per year at $18/seat |
|---|---|---|
| 500 | $9,000 | $108,000 |
| 2,000 | $36,000 | $432,000 |
| 5,000 | $90,000 | $1,080,000 |
| ibl.ai (usage-based) | Tokens actually consumed, or only the GPU when self-hosted | |
Each additional departmental tool priced the same way adds its own row to that bill. The same EdScoop report found only 2% of respondents saying there are new funding sources for AI projects, so a university paying for unused seats is paying out of budgets it already has.
How does an AI Platform Team work inside a university?
An AI Platform Team inside a university has three parts: a central platform group, engineers embedded in offices, and governance encoded in the platform rather than in a meeting. Here is how each maps onto a campus.
The central platform group. Usually inside central IT, this team runs the AI platform, connects it to the student information system, the LMS, the CRM and campus single sign-on, and chooses which models are approved for which data. It is the only team that signs an AI platform contract.
Engineers embedded in offices. This is the half universities tend to skip. Engineers sit with admissions, advising, financial aid and the help desk, learn each office's workflow, and build that office's agents on the shared platform.
That is the forward-deployed role Menezes names. The difference from a central backlog is that the engineer works where the workflow lives, so the advising agent is designed with advisors, not specified to them.
Governance in the platform. Data residency, model selection, logging and access rules are set once and inherited by every agent. FERPA, the federal student privacy law on the books since 1974, then becomes a platform configuration the institution reviews once, not a question every department answers separately.
Our earlier post on organizing for AI experimentation without shadow IT covers the governance council and departmental ownership in more detail. The AI Platform Team model adds the embedded engineers that post leaves out.
Should a university hire its own AI engineers or bring in forward-deployed engineers?
A university should end up with its own AI engineers, and outside forward-deployed engineers are a way to get there faster, not a substitute. Menezes's phrase is "internal FDEs": the expertise is meant to live inside the organization.
Most universities do not have that team on day one. ibl.ai's AI Transformation service is built for that gap: our forward-deployed engineers work inside the university's environment alongside its staff, connect the SIS, LMS and CRM through Model Context Protocol servers, and build the first agents with each office.
The engagement ends with code, data and configuration the university keeps, plus enablement so its own team can run and extend the agents. The test of a good engagement is that the internal AI Platform Team can carry on without us.
What does a university AI platform look like on ibl.ai?
A university AI platform on ibl.ai is one agentic AI operating system, Agentic OS, deployed once and shared by every office. Departments get their own agents; the platform team keeps one set of connections, one policy layer and one audit log.
The ibl.ai higher-education roster ships 12 ready-to-deploy agents a platform team can start from, covering areas such as advising, tutoring, enrollment and the help desk. Each one runs on the shared platform rather than as a separate purchase.
The platform is model-agnostic, so the central team can route an agent to a commercial or an open-weight model and switch later without rebuilding it. Pricing is usage-based, with no per-seat pricing, so adding an office does not add a headcount-sized line to the bill.
And because you own all the code and the data, the AI Platform Team can run the platform hosted, in the university's own cloud or in its own data center. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
When should a university set up an AI Platform Team?
A university should set up an AI Platform Team before its second departmental AI contract, because every additional contract is a data pipeline and a security review the team will later have to unwind.
In the 2025 EDUCAUSE study, 55% of respondents already reported ad hoc rollout, so many campuses are likely past the first.
The practical start is small: name the central team, pick one platform, and embed engineers with the one or two offices that already have a working pilot. Then move the next departmental request onto the platform instead of onto a new contract.
Menezes expects enterprises to spend 2027 learning to govern thousands of agents already in production. A university that sets up its AI Platform Team now builds that governance in from the start.