One AI Agent for a Multi-Campus Education Group: Governance

One agent for the whole group works if four things stay separate

A single AI agent can serve several institutions in an education group, provided the set-up keeps four things apart: brand, knowledge base, routing and data. Get that wrong and an applicant to one institution gets an answer written for another, or the admissions team at one campus sees contacts that belong to a sister institution.

For a group, then, the useful question is not "one chatbot or several?" It is "what is shared, what belongs to each institution, and who decides?" 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 groups end up choosing between

Most groups land on one of three options. None is right everywhere; the answer depends on how much autonomy each institution has.

The third option is where most groups want to be, because it matches how applicants think. Someone looking at a conservatoire is not shopping for a business school from the same group. It does demand that you write down who owns what.

Brand: one voice per institution

Each institution keeps its name, tone, web domain and programme list. The agent on an institution's site introduces itself under that institution's brand and only discusses its courses.

The group sets a narrower set of common rules than a style guide: what the agent never promises (an offer, a scholarship, recognition of prior study), how it discloses that it is an AI, and when it hands over to a person. Think of these as a safety floor rather than an editorial charter.

One trap deserves a decision in advance: comparisons between sister institutions. A visitor may ask, "What is the difference between you and the other school in your group?" Decide whether the agent points to the sister institution when it fits better, or stays inside its own remit. Either is defensible. Improvising is not.

Knowledge: a group layer and an institution layer

Split content into two layers. The group layer holds what is genuinely common: values, locations, general student support, legal notices, the privacy notice. The institution layer holds everything else: programmes, tuition fees, application routes and deadlines, entry requirements, accreditation and recognition.

A simple rule: any fact that differs by institution never goes in the group layer. Fees, deadlines and entry requirements are where the costliest errors occur once knowledge bases are blended.

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 institution leaking into another by mistake, or never reaching the one that needed it.

Routing: getting each conversation to the right team

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

Ambiguous cases do arise: a group-level page, an open day or fair, a link shared on social media, a visitor torn between two subjects. The agent then asks a sorting question (level, subject area, preferred campus) before directing. If the answer stays unclear, it offers a conversation with an adviser rather than guessing.

Plan routing inside each institution too, by campus, programme, language or route, such as undergraduate, postgraduate taught, foundation year or international. Each destination needs a team, response hours and a system where the follow-up is tracked. In the UK this also means handling the seasonal peaks around UCAS deadlines and Clearing, when one institution may be flooded while its sister is quiet.

Data: who decides, who processes, who sees what

Legal teams look here first. Under UK GDPR, roles follow who decides the purposes and means of processing. Per the legislation, Article 26 says that where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers.

In a group, the answer depends on the legal structure. If each institution is a separate legal entity recruiting for itself, it is normally the controller for its own applicant data. If the group centralises the decisions (one tool, one shared database, shared campaigns), responsibilities need to be set out in writing. Have your data protection officer settle this; it cannot be read off a marketing org chart. The Information Commissioner's Office (ICO) is the regulator to consult for guidance.

The vendor running the agent is usually a processor. Article 28 states that processing by a processor shall be governed by a contract or other legal act. In practice, the contract should cover instructions, security, where data is held and what happens to it when the relationship ends.

Three working rules follow:

1. Separation by default. An adviser at institution A sees only institution A's conversations and contacts.
2. No silent reuse. An applicant who asked one institution a question is not contacted by a sister institution without a lawful basis and clear information.
3. Aggregated group view. Group leadership tracks aggregated indicators (volumes, response times, rate of conversation to booked call) without access to named records unless there is a defined, documented need.

Hosting and transfer terms belong in the contract. Ask every vendor for them, including us, and check 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 institution. Changes to an institution layer go through that institution's lead alone.

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

Measuring without mixing institutions

Each institution has its own funnel, seasons and level of name recognition. Comparing two of them uncorrected creates false internal league tables. Measure each against itself, before and after launch and over comparable periods, and consolidate at group level only for operating indicators such as response time, escalation 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 institution and by role?
• Where is data hosted, and what are the terms for sub-processors?
• How are an institution's data exported and deleted if it leaves the group?
• Which CRM integrations exist for the systems each institution already uses?

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