AI building blocks for the systems a university already runs.
We are not trying to place a new central system on top of the university.
A tutor, an agent, a skill, an integration or a whole application can each be built on its own — and connected only where connecting them helps.
Nothing has to arrive all at once.
A course AI, an administrative agent and an institutional integration are entirely different problems. We do not try to force them into one application.
Every solution is assembled from the components it needs, and each component works on its own and can be built on later.
- a standalone AI tutor
- an MCP server connected to a university system
- an instructor's skill
- an internal knowledge assistant
- an agent
- a mobile application
AI can use what it is given access to.
Much of a university AI solution's value comes from its being able to work with the right institutional or course-level knowledge.
- course material
- documents
- regulations
- knowledge bases
- LMS content
- internal data sources
- information reachable from institutional systems
Not every source reaches every AI component automatically. A course AI may see only its own course material, while an institutional assistant may use other, appropriately authorised sources.
AI becomes genuinely useful where it reaches the existing systems.
Universities already run student information systems, LMSs, document stores and internal applications. We connect AI solutions to them through APIs, MCP or custom connectors.
- reaching LMS content
- querying study information
- searching an internal knowledge base
- preparing an administrative process
- extending an existing application with an AI function
API
Where a system has an API, we can make data or functions available to the AI through it.
Custom integration
Where no suitable standard connection exists, an integration can be built for that system.
University functions do not have to live in one chat.
MCP is a standard way for AI clients and agents to connect to external systems, data and functions.
That lets an institution's own capabilities be used where the person is already working.
Where it can be used
- the GoSchool interface
- a mobile application
- ChatGPT
- Claude
- another MCP-compatible client
- a custom institutional agent
What it can expose
- querying course information
- searching an internal document store
- part of an administrative process
- specified functions of an institutional system
MCP does not mean unlimited access. The tools, data and operations available are determined by the institution and the use case.
AI can do more than answer questions.
An agent, given a defined goal, tools and permissions, can carry out a task that takes several steps.
- search for information across sources
- process documents
- collect data
- prepare a decision or an operation
- call institutional functions
- hand a task over for human approval
Not every process should become an agent. An agent is worth using when the task genuinely involves several steps, tool use or decision points.
What works well should be reusable.
Many AI tasks live today in one person's prompt or private workflow. Where something works, it can become a skill the institution reuses.
A skill can be
- a defined analytical task
- processing course material
- preparing a document
- a teaching workflow
- an administrative task
- a way of using a system function
Skill library
- nobody reinvents the same thing
- practices that work can spread
- usage patterns can be improved together
- the institution builds its own AI knowledge base
Not every task needs the same interface.
The technology is not tied to one chat application. The right interface follows the use.
Own web interface
Where a standalone application is needed.
Mobile app
For students, or other mobile situations.
Embedded interface
An AI function placed inside an existing application.
External AI client
Through MCP or another integration, an institutional capability can be reached from the person's own AI client.
White label
The interface can carry the institution's own brand and domain.
AI should respect the same organisational boundaries.
In an institutional setting, who can reach which data, function and AI tool is a basic question.
- SSO
- institutional identity
- roles
- course-level permission
- organisational units
- access per function
- different permissions per agent
A student can reach the knowledge of their own course. An instructor can reach further teaching functions. An administrative agent gets access only to the system functions its task requires.
We do not build around a single model.
Models change quickly, and different models can suit different tasks. We therefore shape the architecture so model choice can follow the use case and the institution's requirements.
The operating environment follows the institution's requirements.
A course pilot and a sensitive institutional process can call for different operating models.
- managed cloud
- the institution's cloud environment
- private infrastructure
- own or chosen models
- on-premise operation where justified
Not every deployment option is available in the same way for every component or model. The architecture is designed around the requirements of the specific project.
Technically possible does not mean it should be allowed.
For institutional AI, permissions, data handling, human control and auditability matter as much as the model itself. We treat the governance questions separately for every use case.
- access
- data minimisation
- human oversight
- logging
- auditability
- model and provider choice
- the AI Act
- AI literacy
One function. Several possible interfaces.
Suppose the university creates a capability that finds the information relating to a student's own courses.
- in the GoSchool web interface
- in a mobile application
- embedded in a university portal
- from ChatGPT
- from Claude
- as part of another agent
The same institutional integration and permission logic can run behind all of them.
The interface is replaceable.
The institutional capability stays.
The whole university's AI architecture does not have to be designed upfront.
Course
An instructor starts a course AI of their own.
Integration
Next, the AI also reaches certain data from the LMS.
Skill
A task the instructor got working becomes a shareable skill.
Institution
Other instructors and organisational units start using it.
External client
Certain functions become reachable from other AI clients through MCP.
Components can be connected gradually.
No complete monolithic platform has to be introduced first.
Which systems would you want AI connected to?
It might be a single data source, an existing application, an MCP integration, or a fuller institutional solution.
We look first at what the task actually is — and only then at what technology it needs.