One AI Agent for a Multi-Campus College System: Governance

One agent across the system works if four layers stay separate

A single AI agent can serve several colleges in a multi-campus group when the set-up keeps four layers apart: brand, knowledge base, routing and data. Without that separation, a prospective student asking about one college gets an answer written for another, and the admissions office on one campus sees leads that belong to a sister campus.

For a group of colleges or a multi-campus system, the real question is not "one chatbot or several?" It is "what is shared, what belongs to each campus or brand, and who signs off?" This article offers a grid for answering it, and complements our guide to AI agents for student recruitment with the group-specific case.

A note on method: paid search-volume and difficulty data were not available for this topic, so the analysis rests on public research. The article contains no performance figures, and nothing in it comes from Skolbot customers.

Three architectures to choose between

Most groups want the third option because it matches how applicants think. A student comparing nursing programs is not shopping for the arts school in the same group. It does force you to put in writing who owns what.

Brand: one voice per college

Each college keeps its name, tone, domain and program list. The agent on its website introduces itself under that college's brand and discusses only its programs.

The group sets a narrower set of shared rules than a style guide: what the agent never promises (admission, a scholarship, a financial aid amount, transfer credit), how it discloses that it is an AI, and when it hands off to a person. Treat these as a safety floor, not an editorial charter.

Decide in advance how the agent handles comparisons with sister colleges. A visitor may ask, "How are you different from the other school in your system?" The agent can point to the sister college when it fits better, or stay within its own remit. Either is defensible. Improvising is not.

Knowledge: a group layer and a campus layer

Split content in two. The group layer holds what is truly shared: mission, locations, general student support, legal notices, the privacy notice. The college layer holds everything else: programs, tuition and fees, application deadlines, entry requirements, accreditation status and financial aid processes.

A simple rule: any fact that differs by college never goes in the group layer. Tuition, deadlines and aid rules are where the costliest errors appear once knowledge bases are blended. Accreditation deserves particular care. Whether campuses are accredited together or separately varies by institution, and a program's status can differ from the college's; have the registrar or accreditation liaison approve every sentence the agent may say on it.

Every item needs a named owner, a last-reviewed date and an expiry rule. We cover the method in keeping an admissions agent's knowledge base current. In a group, the extra risk is propagation: a correction made at one college leaking into another, or never reaching the one that needed it.

Routing: getting each conversation to the right office

Routing answers two questions: which college does this conversation belong to, and who picks it up? The most reliable signal is the entry point. A widget on a college's site ties the conversation to that college without asking the visitor to choose.

Ambiguous cases do arise: a system-level page, a college fair, a link shared on social media, a visitor torn between two majors or two campuses. The agent then asks a sorting question (level, field of study, preferred campus, first-year or transfer) before directing. If the answer stays unclear, it offers a conversation with an admissions counselor rather than guessing.

Plan routing inside each college too: by campus, program, online versus in person, or student type such as first-year, transfer, graduate or adult learner. Each destination needs a team, response hours and a system where follow-up is tracked.

Data: who decides, who processes, who sees what

Student data in the U.S. sits under several layers. For colleges that receive federal funds, the U.S. Department of Education's student privacy site explains that FERPA's regulations cover institutions that receive Department-administered funds, and that rights transfer from the parent to the student at age 18 or on attending a postsecondary institution. That has a direct effect on what an agent may reveal in a conversation: it should not disclose education-record information to someone who has not been verified as the student.

Most admissions-stage conversations involve prospective students rather than enrolled ones, so many of the data points are not education records yet. Do not rely on that assumption. Have your counsel and your registrar confirm, for each college, when a prospect's data becomes part of an education record and what that means for the agent, the CRM and any vendor. State privacy laws and, for visitors under 13, the FTC's COPPA guidance may also apply, so check them with counsel.

In a group, the structure matters. If each college is a separate legal entity with its own admissions function, it is normally responsible for its own prospect data. If the system centralises decisions (one tool, one shared database, shared campaigns), set out the responsibilities and the data-sharing rules in writing. The vendor operating the agent processes data on the institution's behalf, and the contract should cover instructions, security, where data is held, sub-processors and what happens to the data at termination.

Three working rules follow:

1. Separation by default. A counselor at college A sees only college A's conversations and contacts.
2. No silent reuse. A prospect who inquired at one college is not contacted by a sister college without a valid basis and clear notice.
3. Aggregated system view. Leadership tracks aggregated indicators (volumes, response times, rate of conversation to booked appointment) without access to named records unless there is a defined, documented need.

Ask every vendor, including us, for hosting and transfer terms in writing, and verify them before you sign.

Governance: who changes what, and how

A group agent is a living product. Without change rules it drifts. Four roles are enough for a mid-sized group.

Then define a change path: who proposes, who approves, who publishes, how to roll back. Changes to the group layer go through the platform owner plus a lead from each affected college. Changes to a college layer go through that college's lead alone.

Keep version history. When a student disputes an answer, you should be able to see what the agent knew on the day. Schedule a regular review of conversations handed to staff, college by college; that is where missing content shows up.

Measuring without mixing colleges

Each college has its own funnel, seasons and brand recognition. Comparing two uncorrected creates false internal league tables. Measure each against itself, before and after launch and over comparable periods, and consolidate at system level only for operating indicators such as response time, handoff rate and content flagged as missing.

Settle the indicators before deployment. Our evaluation grid for choosing an AI agent lists criteria to test with a vendor, including multi-site handling.

Questions to put to a vendor

Ask in writing and request a demonstration rather than a promise:

• Can separate brands, domains and knowledge bases be configured in one workspace?
• How are access rights managed by college and by role?
• Where is data hosted, and what are the terms for sub-processors?
• How are a college's data exported and deleted if it leaves the group?
• Which CRM integrations exist for the systems each college already uses?

Take only what the vendor shows working. A feature that is announced but not demonstrated does not exist yet for your decision.