During the University’s first AI hackathon, Szymon Drobiazgiewicz, Repository Support Officer at the University of Northampton used Microsoft Copilot to create a chatbot that could guide researchers through the process of adding a journal article to the University’s research information system, Pure. What started as an experimental prototype developed into a resource being prepared for use within his department.
The project offers a practical example of how AI can support university work without attempting to replace the knowledge of the people doing it.
Starting with one focused task
Szymon deliberately began with a narrow use case. The chatbot was not asked to answer every possible question about Pure. Its initial purpose was to explain how to add one type of research output.
“I created a chatbot that helped people find information about how to add a journal article to our database. It was really simple.”
Keeping the scope manageable made it easier to test whether the chatbot could provide useful guidance.
It also allowed Szymon to understand the limits of the Copilot licence available to staff.
Once the first version had been demonstrated, he was asked to develop it further. The longer-term possibility is to extend the chatbot so that it can support researchers with a wider range of outputs.
This gradual approach matters. Rather than trying to build a comprehensive research support assistant immediately, Szymon created something small enough to test and improve.
Making guidance easier to reach
The value of the chatbot lies in its accessibility. A researcher can ask a question in ordinary language rather than searching through guidance documents or waiting for someone to respond.
This does not remove the need for repository staff. It gives researchers another route to straightforward information and may reduce repeated queries about routine processes.
For Szymon, AI works best when it is treated as a tool:
“AI is like a talking hammer. You treat it as a tool that talks, nothing more.”
The description captures both the appeal and the limitation of Copilot. It can respond conversationally, which may make it feel knowledgeable or even human. Yet its purpose is still to help someone complete a task. Responsibility for the quality of the guidance remains with the people who design and maintain it.
How far can a conversation become a simulation?
Alongside the chatbot, Szymon has been testing Copilot’s ability to sustain simulations. His interest comes partly from an earlier career in archaeology and from experience in the games industry.
He experimented by asking Copilot to create a long-running historical scenario in which he made decisions and observed how the situation developed. The exercise made him consider how conversational AI could allow learners to explore historical events from inside a scenario rather than only reading about them.
“You can simulate an environment through text-based input from AI. That could be useful wherever students need to explore a situation.”
In history, a learner might enter a simulated period and ask how events appeared to people living at the time. The same principle could be adapted to other subjects, although each use would need to be designed and checked by people with relevant expertise.
Szymon compares the idea with the holodeck in Star Trek. Current tools cannot generate a completely convincing world in which a learner can move freely, but they can sustain a dialogue that responds to decisions. This creates a text-based form of simulation that may later connect with immersive technology.
These possibilities remain exploratory. The experience of prompting a general-purpose chatbot is not the same as using a validated educational simulation. Its value would depend on the accuracy of the source material and the learning design around it.
Experimentation across traditional boundaries
A recurring theme in Szymon’s interview was that useful ideas do not always sit neatly within one department.
His work in repository support brought him into contact with AI and workflow automation. His previous experience gave him a different perspective on what those tools might do. The chatbot emerged because he was able to combine knowledge of a university process with an interest in new technology.
Szymon would like staff to have more opportunities to contribute to small digital projects outside their usual roles. He draws on the idea of “citizen developers”: people who are not employed as programmers but can create straightforward solutions to local problems.
Such work would still need oversight from IT and the relevant service team. Its advantage is that the person closest to a problem may be able to create an early prototype rather than waiting for a fully resourced development project.
“If someone is interested in Copilot, we should be able to work together even if they come from a completely different department.”
This kind of collaboration could also help staff understand what colleagues elsewhere in the University are trying to achieve. A working prototype gives people something concrete to test and discuss.
Accessibility through conversation
Szymon also sees potential in AI interfaces that respond to spoken instructions. The ability to ask a question aloud and receive a spoken response may make digital systems easier to use for people who find conventional keyboard interaction difficult.
Conversational tools could also help learners access information in a form that suits them. A student might ask for a different explanation or request that information be presented through another medium.
This does not automatically make AI inclusive. The output still needs to be accurate and accessible, while the system must be designed around the needs of real users. However, the move away from a single method of input creates possibilities worth exploring.
Knowing when not to trust the answer
Szymon is enthusiastic about AI, but he is not uncritical. He has encountered errors during long conversations with Copilot and believes that outputs should always be checked by a person.
This becomes especially important when a chatbot provides guidance about an institutional process. An incorrect answer could create additional work or lead someone to record information wrongly.
Data privacy also needs careful consideration. Szymon recommends avoiding the use of identifiable or commercially sensitive information in experimental prompts. Where realistic data is needed to test a system, details can be replaced so that the task remains useful without exposing confidential material.
The same caution applies to educational simulations. AI may create a convincing scenario while introducing false information. A fluent response should never be treated as evidence of accuracy.
From experimentation to useful practice
Szymon does not argue that every AI experiment should become a University service. His approach is to test what the available tool can do, identify a focused problem and see whether a small solution helps.
The Pure chatbot is a good example. It does not attempt to transform research support. It makes one part of an existing process easier to navigate.
This modest starting point may be one of the most useful lessons from the project. Innovation does not always begin with a large system or a fully developed strategy. Sometimes it begins when someone who understands a problem and takes time to experiment. In the hands of someone who knows what needs fixing, a talking hammer can be a powerful tool.
