Sejong eCampus Agent is a course project prototype I built to explore a practical problem I see in student life: important academic information is often spread across announcements, files, deadlines, assignment pages, and reminders. Even when the information is available, students still need to check it repeatedly, remember what changed, and decide what deserves attention first.
The idea behind the project is simple. Sejong eCampus Agent is a Telegram-based assistant for Sejong University students that helps track eCampus announcements, deadlines, assignments, files, reminders, and study priorities in one place. It is not a fully finished product. I think of it as a first working version: a course project version that proves the workflow can be useful, while still leaving many details to improve.
Demo video hosted on YouTube.
Project Documentation Sejong eCampus Agent web docs View the documentation and demo context for the course project prototype.Why Telegram?
I chose Telegram because students already use messaging apps every day. Instead of asking a student to open another dashboard, the assistant can send updates in a familiar place. A bot interface also makes the project feel direct: the student can check upcoming work, receive reminders, and quickly see what needs attention without moving through many pages.
This direction also made the prototype more realistic. A student assistant is only useful if it fits into daily behavior. If the system requires too much effort to check, students may stop using it. Telegram gave me a lightweight way to test whether an academic workflow could become more automatic and more visible.
Connection to Operating Systems
The project was developed as part of the Operating Systems course at Sejong University, taught by Professor Muhammad Zubair Islam. That context shaped how I thought about the system. At first glance, a Telegram bot may look like an application project, but the implementation naturally connects to several OS-related concepts.
The assistant needs background processes that can periodically check for new information. It needs scheduling logic to decide when reminders should be sent and which tasks should appear first. It needs automation so the system can reduce repeated manual checking. It also needs session handling, because each student may have a different login state, chat state, and set of tracked courses.
Reliability became an important design concern too. A student reminder system should not silently fail, duplicate every notification, or lose track of a session after a temporary error. Secure data handling is also essential because academic accounts, personal schedules, and course-related data require care. Even in a prototype, these concerns matter because they are part of what turns a script into a responsible system.
This version is intentionally honest: it is an early prototype, not a polished production service. Its value is that it makes the system idea concrete enough to test, discuss, and improve.
What the First Version Does
The first working version focuses on the basic assistant workflow. It is meant to collect the student-facing eCampus information that usually requires repeated checking and make it easier to review from Telegram.
- track course announcements and important updates;
- surface assignments and upcoming deadlines;
- organize files and course materials more visibly;
- send reminders for academic tasks;
- help students think about study priorities instead of only seeing a flat list of tasks.
The goal was not to replace eCampus. Official platforms still matter, and students should continue to rely on the university system as the source of truth. The prototype is more like an assistant layer: it helps students notice, organize, and act on information that already exists.
What I Learned
Building this prototype taught me that automation is not only about making things faster. It is about deciding what should happen in the background, what should wait, what should be prioritized, and how to avoid surprising the user. Those are the same kinds of questions operating systems handle at a deeper level.
I also learned that a small assistant can become complex very quickly. Once the system handles sessions, reminders, periodic checks, failures, and user-specific data, it needs structure. Even a course project benefits from clear boundaries between fetching data, storing state, scheduling work, and sending messages.
Future Improvements
There is still a lot I would improve before calling this a complete product. The next steps would include stronger error handling, better user onboarding, more careful permission management, cleaner reminder customization, deeper testing with real student workflows, and a more complete public documentation page. I would also want to improve how the assistant ranks priorities so that it helps students focus without hiding important information.
The course project version gave me a working foundation. More importantly, it helped me connect classroom concepts with a problem that affects students directly. That is what made the project meaningful for me.
Final Reflection
Sejong eCampus Agent is an early prototype, but it represents the kind of software I enjoy building: practical, student-focused, and connected to real workflows. It also reminded me that operating systems concepts are not only abstract topics from lectures. Background work, scheduling, reliability, sessions, automation, and secure state management appear inside everyday applications too.
For me, this project was a first step toward understanding how a useful assistant can support students without pretending to be bigger than it is. It is a working course project prototype, and that honesty makes the next version easier to build.