Every Campus Wants Agentic AI. Few Have the Data Foundation For It.
The Problem
A single student exists in your SIS, CRM, LMS, finance, and departmental tools. Each system holds a different version of that student, with its own permissions, API, and vocabulary.
Point an AI agent directly at that estate and you inherit scattered credentials, bloated responses, and answers nobody can fully account for.
Why the shortcut fails
Every credential becomes another copy of your access policy, maintained separately and free to drift.
Endpoints return everything they know. The agent pays in tokens and reasons through noise.
Agents reason less reliably over bloated payloads, so teams stop trusting them with important work.
Each new agent rebuilds the same integration and permission logic. The more you scale this way the more complexity you add.
Building the Agentic CampusThe institutional opportunity and why the data foundation decides whether it works.
From AI Ideas to Campus ImpactReal use cases, data readiness, and adoption lessons after go-live.
CampusMind.ai in ActionFabric, a governed data agent, and CampusMind orchestration running live.
Understand why direct access failsSee how permissions, context, and trust break down.
See governance documentedPermissions, row-level security, read-only access, and Purview.
See it Work LiveWatch the agent handle a question like the ones your team would actually ask.
Put your questions to Microsoft and CampusMindBring your own data readiness and ontology questions to the live discussion.
Campus leaders and teams trying to figure out what a real data foundation for AI agents actually requires.
The Proposal
Bring the data into one governed place, with an ontology that captures what your institution means by student, enrolment, and term.
BEFORE
The agent has API credentials but no map of the data. It queries broadly, pulls back everything, and has no way to know what your institution means by its own terms.
Huge API responses dilute the agent's context with irrelevant data
Token usage climbs and accuracy drops
An external agent doesn't know semantics custom to your organization
Access is all-or-nothing at the table, with no column-level control
AFTER
The question is asked in the tool people already use. The ontology decides which source owns the answer, and the query is generated, not written.
Only the relevant slice comes back, not the whole payload
Fewer tokens spent, higher accuracy in the answer
Your organization's definitions travel with every query
Column-level access per user, without opening the whole table
A data agent answers a question, with governance built into how it gets there.
It's documented Microsoft behaviour. A Fabric data agent, generally available today:
✓ Uses the requesting user's own credentials and permissions to enforce least-privilege access.
✓ Row-level and column-level security still apply.
✓ Connected data access remains read-only.
✓ Microsoft Purview governance policies are enforced, including DLP and access-restriction policies.
✓ Supports up to five data sources in any combination — lakehouses, warehouses, Power BI semantic models, KQL databases, ontologies and Microsoft Graph.
The Demo
We'll ask a CampusMind agent a realistic institutional question with the permission boundary visible at every step.
Gets asked a real institutional question — the kind a staff member would actually ask.
Receives a scoped question, not a table. Answers within the asker's own permissions.
One foundation, read-only, with row- and column-level security intact.
You see what the agent was allowed to see, and what it actually received.
Speakers
REGISTER