One agent for the group works if four layers stay separate
A single AI agent can serve several institutions in an Australian education group when the set-up keeps four layers apart: brand, knowledge base, routing and personal information. Without that, a prospective student asking about one institution gets an answer written for another, and the enrolment team on one campus sees enquiries that belong to a sister provider.
The Australian market has its own shape. Groups often combine universities, university colleges, private higher education providers and VET or TAFE-style pathways under different brands, with a large international student intake and agents acting as intermediaries. The useful question is not "one chatbot or several?" but "what is shared, what belongs to each provider, 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 provider, separate tools | Each provider 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 courses and enquiries |
| Shared platform, one configured agent per brand | Common foundation; content, settings and data held per provider | Consistency with autonomy | Needs explicit governance |
The third option fits how prospective students think. Someone looking at a diploma pathway is not shopping for a postgraduate coursework degree at another brand in the group. It does require writing down who owns what.
Brand: one voice per provider
Each provider keeps its name, tone, domain and course list. The agent on its website introduces itself under that brand and discusses only its courses.
The group sets a narrower set of common rules than a style guide: what the agent never promises (an offer, a scholarship, credit for prior learning, a visa outcome), how it discloses that it is an AI, and when it hands over to a person. Visa and immigration questions deserve a hard boundary: the agent can point to official information and to a qualified adviser, but should not assess an individual's case.
Decide in advance how the agent handles comparisons with sister providers. Pointing to the sister brand when it fits better, or staying within its own remit, are both defensible. Improvising is not.
Knowledge: a group layer and a provider layer
Split content in two. The group layer holds what is truly shared: values, campus locations, general student support, legal notices, the privacy collection notice. The provider layer holds everything else: courses, fees, intake dates, entry requirements, accreditation and registration status.
A simple rule: any fact that differs by provider never goes in the group layer. Fees, intake dates and entry requirements are where the costliest errors appear once knowledge bases are blended. Entry pathways differ by course and by provider, including how ATAR is used, and domestic and international fee arrangements differ too, so the agent should establish the student's category before quoting anything and only from approved provider pages.
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 provider leaking into another, or never reaching the one that needed it.
Routing: getting each conversation to the right team
Routing answers two questions: which provider does this conversation belong to, and who picks it up? The most reliable signal is the entry point. A widget on a provider's site ties the conversation to that provider without asking the visitor to choose.
Ambiguous cases do arise: a group-level page, an open day or expo, a link shared on social media, a visitor weighing a diploma against a degree. The agent then asks a sorting question (level, field, campus, domestic or international) before directing. If the answer stays unclear, it offers a conversation with an adviser rather than guessing.
Plan routing inside each provider too: by campus, course, study mode or student type. International enquiries often go to a different team and time zone from domestic ones, so set response hours accordingly and say them plainly in the conversation.
Personal information: who decides, who processes, who sees what
Australian privacy obligations sit mainly in the Privacy Act 1988. The Office of the Australian Information Commissioner describes the Australian Privacy Principles as "the cornerstone of the privacy protection framework in the Privacy Act 1988". Its quick reference summarises the points most relevant to a group agent: APP 6 outlines the circumstances in which an APP entity may use or disclose personal information that it holds; APP 7 says an organisation may only use or disclose personal information for direct marketing purposes if certain conditions are met; and APP 8 outlines the steps an entity must take to protect personal information before it is disclosed overseas.
Each of those maps onto a group set-up. APP 6 bears on whether one provider may use another's enquiry data. APP 7 bears on follow-up campaigns across brands. APP 8 bears on any hosting or support arrangement outside Australia, which is a live question for any cloud vendor. Whether each member of the group is an APP entity, and how state or territory laws apply to public universities, is a legal question; get a written answer before launch.
Roles follow who decides the purposes and means of handling. If each provider is a separate legal entity recruiting for itself, it normally answers for its own enquirers' information. If the group centralises decisions (one tool, one shared database, shared campaigns), write down the split of responsibility. The vendor handles information on the provider's behalf, and the contract should cover instructions, security, hosting location, sub-processors and the end of the relationship.
Three working rules follow:
- Separation by default. An adviser at provider A sees only provider A's conversations and contacts.
- No silent reuse. An enquirer at one provider is not marketed to by a sister provider without a valid basis and clear notice.
- Aggregated group view. Group leadership tracks aggregated indicators without access to named records unless there is a defined, documented need.
Governance: who changes what, and how
| Role | Responsibility |
|---|---|
| Group sponsor | Sets scope, arbitrates between providers, owns the budget |
| Platform owner | Handles configuration, access and integrations |
| Provider lead | Approves their provider's content, reviews conversations and handoffs |
| Privacy lead | Checks contracts, retention periods and access 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 provider. Changes to a provider layer go through that provider's lead alone. Keep version history, so that when a student disputes an answer you can see what the agent knew that day, and review handed-off conversations regularly, provider by provider.
Measuring without mixing providers
Each provider has its own funnel, intake cycle and brand recognition. Comparing two uncorrected creates false internal rankings. Measure each against itself, over comparable periods, and consolidate at group level only operating indicators such as response time, handoff 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 provider and by role?
- Where is data hosted and supported, and what are the terms for sub-processors and overseas access?
- How are a provider's data exported and deleted if it leaves the group?
- Which CRM integrations exist for the systems each provider already uses?
Take only what the vendor shows working.



