What Nobody Tells You About Actually Building AI in Higher Education
An installation in implementation reality
A few weeks ago, I wrote about why higher education can’t afford the AI agent delusion on LinkedIn. That was the warning.
This is what happens when you heed it.
After building Unity Environmental University’s AI ecosystem, Una, from the ground up, I’ve learned that successful AI implementation in higher education has nothing to do with the breathless promises in vendor decks and everything to do with decisions nobody wants to make at moments nobody finds convenient.
Here’s the gap between “we’re implementing AI” and actually having AI that works.
The (Z)Room Where It Happens
The decision to build rather than buy doesn’t happen in a single meeting. It happens across dozens of conversations where you’re defending a choice that sounds irresponsible to people who haven’t lived through vendor disappointment.
Board members ask reasonable questions: “Why aren’t we using [well-known vendor]? They serve hundreds of institutions.”
Exactly. They serve hundreds of institutions with the same generic solution, the same templated workflows, and the same assumption that higher education is a monolith rather than hundreds of unique organizations with distinct idiosyncrasies.
But you can’t say that without sounding arrogant. So instead you talk about “strategic alignment” and “institutional fit” and hope someone in the room remembers the last three vendor implementations that promised transformation and delivered expensive mediocrity.
The choice to build isn’t made once. It’s remade every time someone questions it, every time a vendor releases a shiny new feature, every time you hit a technical obstacle that makes you wonder if outsourcing would have been easier.
It wasn’t easier. It was just someone else’s problem to hide from you.
The Talent Problem Nobody Solves
Vendors sell you their talent. When you build, you need your own.
Higher education doesn’t pay Silicon Valley salaries. We can’t compete with tech companies for developers. We operate in places where “remote work” means “our entire candidate pool just evaporated to companies that pay twice as much.”
So how do you build technical capacity when you can’t hire it?
You grow it. You find people with adjacent skills and bet on their ability to learn. You create roles that don’t exist in traditional higher ed org charts. You make the case that building something meaningful at a mission-driven institution beats optimizing ad click-through rates at a tech company.
We have created and augmented multiple positions. Not because we found people with that exact title somewhere else, but because we needed people who could translate between technical possibility and institutional reality. Someone who understood that “clean data pipeline” isn’t just a technical requirement; it’s a political achievement.
Finding those people required rewriting job descriptions, defending unconventional hiring decisions, and accepting that the right person might come from an unexpected background.
Building AI in higher education isn’t a technical challenge. It’s a talent development challenge that happens to involve technology.
The Velocity Problem
Vendor timelines are measured in quarters. Implementation reality is measured in years.
Not because the technology is complex, but because organizational change is slow. Because people need time to trust new systems. Because you can’t force adoption faster than culture moves.
Una launched with three specialized assistants: “Una” our AI Ecosystem, “Una Consierge” for Applicants in our portal, & “Una Guide” in academics. We didn’t build all three simultaneously. We started with one, learned from it, iterated, then expanded. Two were built on the Agentforce Platform and one own bespoke build affectionately called A.L.I.G.N
And here’s the tension that matters. Getting vendor help isn’t the problem. Vendors can provide valuable infrastructure, technical capabilities, and support that would be impossible to build from scratch.
The problem is when vendor solutions replace institutional thinking. When you buy their roadmap instead of building your own. When you outsource the understanding of your problems, along with the implementation of solutions.
The critical distinction is between using vendor tools and being used by vendor strategies. We use Agentforce infrastructure, but we’re not Agentforce customers waiting for their next release to solve our problems.
We’re Unity, using available tools to solve Unity-specific challenges in Unity-specific ways. That nuance, that tension between leveraging external capability while maintaining internal control, that’s where successful AI implementation actually lives.
The Marketing Paradox
Building AI creates a communication problem. How do you tell the story when the real story is boring?
Una works because of data pipelines, system integrations, and workflow redesign. But try putting that in a press release. Try getting traditionalists excited about API endpoints that finally talk to each other.
The gap between what makes AI successful and what makes AI marketable is enormous.
Vendors understand this. They lead with transformation, personalization, and intelligence. They bury the infrastructure requirements in implementation footnotes nobody reads until they’ve already signed the contract.
When you build, you own the whole story. Including the parts that don’t photograph well.
We struggled with this. How do you announce Una without either:
Overpromising what it does (the vendor trap)
Boring everyone with technical accuracy (the engineer trap)
The answer we found? Talk about outcomes, not architecture. Our recruitment teams will be able to respond faster to inquiries. Our student success team identifies at-risk students earlier. Our academic advisors spend less time on routine questions and more time on complex problem-solving, etc.
Those outcomes required unglamorous technical work. But the people benefiting from Una don’t need to understand Salesforce Agentforce integration. They just need to know their jobs got easier.
The marketing paradox is that the more technically sound your AI implementation, the harder it is to explain why it’s technically sound. Which means successful implementations often look less impressive than failed ones.
The Organizational Immune System
Institutions don’t reject AI because they hate innovation. They reject AI because they’ve seen this movie before.
Every technology wave promises to revolutionize higher education. Most create extra work for already-stretched staff. The organizational immune system has learned to attack foreign objects, even beneficial ones.
Overcoming this required:
Involving actual users in design, not deployment
Starting with genuine pain points, not impressive demos
Building trust through small wins before big rollouts
Accepting that “AI” might need to be invisible to be effective
Our team doesn’t talk about “using AI.” They talk about having better conversations with prospective students because routine questions get handled automatically. That’s adoption. They discuss how Una Guide will Socratically support a learner complete their assignment in the LMS responsibly.
The Succession Question
Building AI internally creates a dependency problem. What happens when the people who built it leave?
This isn’t theoretical. We’ve had key transitions during Una’s development. People move on. Roles evolve; talent gets poached. The person who designed the initial architecture might not be the person maintaining it two years from now.
Vendors sell this as their advantage: “We’re not going anywhere. We’ll support this system indefinitely.” (Until they’re acquired. Or pivot. Or deprecate your version. Or price you out. But sure, permanence.)
Building internally requires different thinking about continuity. It means:
Documenting decisions, not just code. Why did we choose this approach? What alternatives did we consider? What would we do differently?
Distributing knowledge across people, not concentrating it in one technical wizard
Creating roles that can evolve as needs change
Building systems simple enough that they can be maintained by future staff with different skills
The succession question applies to leadership, too. Una needs to outlive my tenure. That shapes every decision we make; not “will this work for me?” but “will this work for whoever comes next?” Unless they would rather just walk their dog on campus all day :)
This long-term thinking is incompatible with the vendor sales cycle. They need you to decide now based on the current pain. But institutional AI systems aren’t temporary solutions to immediate problems. They’re infrastructure that needs to work for the next decade.
Building means accepting responsibility for that decade, not just the next quarter.
What Actually Happens
After a year of building AI systems in higher education, here’s what I’ve learned about the gap between planning and reality:
The timeline is always wrong. Not because you estimated poorly, but because organizational change doesn’t follow project plans, and our understanding of AI is also evolving. Budget for twice as long as you think it will take, then add three months for things you didn’t know you didn’t know.
The first version is wrong. Build it anyway. You learn more from deploying something imperfect than from planning something perfect. Una v1.0 was clunky. Una v2.0 was informed by actual usage, not imagined workflows.
The loudest voices aren’t the biggest problems. Some people will vocally resist AI. Others will quietly struggle. The vocal resisters usually come around once they see it working. The quiet strugglers need proactive support and won’t ask for it.
Success looks like nothing happened. The best outcome is that AI becomes invisible infrastructure. When people stop talking about “using the AI tool” and just talk about doing their jobs, you’ve won.
You’ll defend the decision forever. Every vendor announcement, every conference presentation, every board meeting will generate the question “should we have just bought [something else]?” Get comfortable re-explaining the choice.
Documentation matters more than code. Let me say this again! Documentation matters more than code. You (or future someone else) will need to understand why decisions were made. Write it down while you remember. Your code might be elegant. Your documentation will save someone’s job.
The Choice You Keep Making
Building Una wasn’t a single decision. It was a series of choices, made repeatedly, under pressure, when easier options existed.
The choice to wait when everyone wanted to move faster. The choice to build when buying would have looked more responsible. The choice to invest in unsexy infrastructure when flashy features would have generated better headlines. The choice to accept short-term criticism for long-term capability.
These aren’t heroic choices. They’re uncomfortable ones. The kind where you question yourself at midnight. The kind where you wonder if you’re being stubborn or strategic. The kind where you won’t know if you were right for another two years.
Here’s what I can tell you after making those choices:
It was harder than buying would have been. It took longer than I promised. It required defending decisions I sometimes doubted myself. It meant accepting that we’d look less innovative than institutions that bought shiny vendor solutions, even as we built more sustainable systems.
But Una is ours. It knows Unity. It adapts as we adapt. It doesn’t require vendor permission to evolve. The knowledge we built creating it stays with us. The capability we developed doesn’t live in someone else’s cloud.
When prospective students engage with Una, they’re not getting a generic higher ed chatbot. They’re getting a system trained on Unity’s actual mission, shaped by Unity’s actual people, serving Unity’s actual needs.
That’s the gap between “implementing AI” and actually having AI that matters.
The institutions that will succeed with AI aren’t the ones that deploy off-the-shelf user cases. They’re the ones that build most thoughtfully. They’re the ones willing to endure the boring, frustrating, unglamorous work that nobody photographs for conference presentations.
They’re the ones willing to choose the harder path because it’s the only path that leads somewhere worth going. Let me be as clear as I can! None of this happens without the team willing to build it with you. I'm blessed to work with people who chose the harder path not because it was required, but because they believed it mattered, no matter how uncertain the path less travelled seems!