One agent for the group works if four layers stay separate
A single AI agent can serve several colleges in an Irish education 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 team on one campus sees contacts that belong to a sister college.
Ireland's higher education landscape explains why this matters. Groups may span universities, technological universities, institutes, private colleges and English-language or professional programmes, with applicants arriving through the CAO points system, direct applications, or international routes. The useful question is not "one chatbot or several?" but "what is shared, what belongs to each college, and who signs off?". This article offers a grid for answering it, and complements our guide to AI agents for student recruitment.
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
| Architecture | How it works | Strength | Risk |
|---|---|---|---|
| One agent per college, separate tools | Each college buys and runs its own | Full autonomy | Uneven practice, no group view, duplicated spend |
| One anonymous agent for the whole group | A single voice across every brand | Simple to run | Blurs brands; mixes programmes and enquiries |
| Shared platform, one configured agent per brand | Common foundation; content, settings and data held per college | Consistency with autonomy | Needs explicit governance |
The third option fits how applicants think. Someone weighing a hospitality programme is not shopping for a computing degree at another college in the group. It does require writing down who owns what.
Brand: one voice per college
Each college keeps its name, tone, domain and programme list. The agent on its website introduces itself under that brand and discusses only its programmes.
The group sets a narrower set of common rules than a style guide: what the agent never promises (a place, a scholarship, exemptions for prior learning), how it discloses that it is an AI, and when it hands over to a person. Treat these as a safety floor rather than an editorial charter.
Decide in advance how the agent handles comparisons with sister colleges. Pointing to the sister college when it fits better, or staying within its own remit, are both defensible. Improvising is not.
Knowledge: a group layer and a college layer
Split content in two. The group layer holds what is truly shared: values, locations, general student support, legal notices, the privacy notice. The college layer holds everything else: programmes, fees, application routes and closing dates, entry requirements, QQI awards and recognition.
A simple rule: any fact that differs by college never goes in the group layer. Fees, closing dates and entry requirements are where the costliest errors appear once knowledge bases are blended. Remember that some programmes are filled through the CAO and others by direct application; the agent should state which route applies to which programme, from the college's approved page, and never generalise.
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 team
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 group-level page, an open day, a link shared on social media, a visitor torn between two courses or two campuses. The agent then asks a sorting question (level, subject, campus, EU or non-EU applicant) before directing. If the answer stays unclear, it offers a conversation with an adviser rather than guessing.
Plan routing inside each college too: by campus, programme, mode of study or applicant type, such as school leaver, mature applicant or international student. Each destination needs a team, response hours and a system where follow-up is tracked.
Data: who decides, who processes, who sees what
In Ireland the Data Protection Commission supervises GDPR compliance, and its website is the place to look for guidance. Roles under GDPR follow who decides the purposes and means of processing. If each college is a separate legal entity recruiting for itself, it is normally the controller for its own applicants' data. If the group centralises decisions (one tool, one shared database, shared campaigns), write down the split of responsibility. Have your data protection officer settle this; it cannot be read off a marketing org chart.
The vendor running the agent is usually a processor. Recital 81 of the GDPR text says: "The carrying-out of processing by a processor should 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.
On purpose limitation, recital 39 of the same regulation says the specific purposes for which personal data are processed should be explicit and legitimate. That applies between colleges of the same group as well.
Three working rules follow:
- Separation by default. An adviser at college A sees only college A's conversations and contacts.
- No silent reuse. An applicant who asked one college a question is not contacted by a sister college without a lawful basis and clear information.
- 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
| Role | Responsibility |
|---|---|
| Group sponsor | Sets scope, arbitrates between colleges, owns the budget |
| Platform owner | Handles configuration, access and integrations |
| College lead | Approves their college's content, reviews conversations and escalations |
| Data lead | Checks contracts, retention periods and individual rights requests |
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, so that when an applicant disputes an answer you can see what the agent knew on the day, and review escalated conversations regularly, college by college.
Measuring without mixing colleges
Each college has its own funnel, seasons and name recognition. Comparing two uncorrected creates false internal league tables. Measure each against itself, over comparable periods, and consolidate at group level only operating indicators such as response time, escalation rate and content flagged as missing. 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
- 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.



