AI is changing what organizations need to consider when investing in technology. When you launch a website, you now have to think about how people will discover your organization through AI-generated answers. That brings generative engine optimization, or GEO, into decisions about your content and how you present information. Similar questions are emerging across the technology stack: how well does the software you choose fit into the way people increasingly use AI?
For colleges and universities, that question belongs in the buying process. A system may meet an office’s needs today, but the institution also needs room to introduce new tools and work with new providers over the life of the contract. How accessible that system is to AI can affect the cost and difficulty of doing so.
That’s what we’ll explore in The Agent-Ready Campus, a series examining the technology decisions institutions face as AI becomes part of their work. We’ll look at what to consider when choosing vendors, what agents need to work with their systems, and how those choices affect your ability to build internally or hire an outside company.
With Salesforce having just concluded Dreamforce, I thought CRM would be a useful place to begin.
Your institution may want its own developers to build custom agents, or it may hire a company whose software needs access to enrollment, advising or advancement records. Either approach depends on what the CRM allows: which information can be accessed, which changes can be made, how permissions work, and whether the vendor supports your chosen provider.
This first installment looks at what makes a higher education CRM accessible to independently built apps and agents, and why that depends on what the system exposes to other software rather than what it shows on screen.
The shift
API over UI
What a CRM looks like to an agent
A demo shows you the screen
For about twenty years, choosing a CRM has mostly meant sitting through vendor demos. Staff would watch someone click through a record page and a few dashboards, then decide whether they could see themselves using it every day. That was a sensible way to buy software when people did all of the work inside it.
An agent never sees the screen
An agent doesn’t work that way. It never opens the record page, so a clean layout or a well-placed button means nothing to it. Whether your own developers build it or you hire a company to do it, the agent reads and updates records through the vendor’s API. More vendors are now adding an MCP server on top of that API so that AI tools can connect to it more easily.
Where many CRMs come up short
This is where a lot of higher-ed CRMs struggle. Outside software can usually read most of the data, but any changes it makes go into an import queue that is processed later. Very few of these vendors offer an MCP server yet. When a new application or gift comes in, the agent usually has no way of hearing about it, and every tool connected to the system often shares a single key with broad permissions.
The biggest vendors in the market are saying much the same thing. Satya Nadella has described business applications as “essentially CRUD databases with a bunch of business logic,” adding that “the business logic is all going to these agents.” In April, Salesforce introduced its Headless 360 initiative with the line “No Browser Required,” noting that agents “don’t go to a browser or click through UIs.”
If agents are part of your plans, that changes what you should ask a vendor before you sign. Five questions matter most:
- Can an agent make changes, or only read data? Many higher-ed CRMs let outside software read almost anything but accept changes only as uploaded files that are processed later. An agent that can’t write back to the record can’t finish much of the work you’d give it.
- Does it offer an MCP server? The Model Context Protocol is the standard that tools like Claude, ChatGPT and Copilot use to connect to other software. When the vendor provides and supports a server, your team doesn’t have to build and maintain that connection itself.
- Can the agent have its own login? An agent should sign in under its own account, with only the permissions it needs rather than an administrator’s access. That matters most for student records covered by FERPA, where you need to know exactly what the agent can see.
- Will the CRM tell the agent when something changes? Webhooks or a change feed let the system notify an agent as soon as a new application or gift arrives. Without them, the agent has to keep checking on a schedule, which is slower and easier to get wrong.
- Do the vendor’s terms allow the agent you choose? Terms are changing faster than anything else on this list. In September, Salesforce said agents that use its MCP servers will need to be registered, and SAP’s API policy limits autonomous AI agents to routes SAP has endorsed.
Usability still matters, because your staff will spend their days in whichever CRM you choose. A good demo just can’t tell you whether that system will keep up as agents take on more of an office’s routine work.
What comes next
A comparison for every office
We’re now putting together a comparison of the CRMs used across higher-ed administrative offices, from admissions and advising to advancement, career services and student services. It draws on our own experience working with these systems in different offices, and we’ll publish it here on the blog. If you’d like a copy when it’s ready, leave your email below.