StudyX

This is a comprehensive blueprint for StudyX—an autonomous, agent-based student intelligence. This plan moves beyond a simple chatbot and creates a system that "lives" across your devices to manage your academic and digital life.

---

1. Project Description: StudyX

StudyX is a proactive, cross-platform AI assistant designed to centralize and automate the life of a computer science student. Unlike traditional LLMs, StudyX acts as an Autonomous Agent that continuously monitors Learning Management Systems (LMS), WhatsApp groups, and Cloud Workspaces (Google/Microsoft). It doesn't just answer questions; it predicts needs—generating study guides from new lecture slides, scheduling study blocks in Notion based on detected deadlines, and providing a unified command interface via Mobile, Desktop, and CLI.

---

2. Technical Architecture Plan

A. The Infrastructure Layer (The Hybrid Backbone)

• Cloud Orchestrator (Oracle Cloud/Azure): Hosts the "Brain" (FastAPI Backend) and the Agentic logic. This ensures the assistant is always online to parse incoming WhatsApp messages or LMS updates.
• Local Vault (Home Server/PC): Stores the actual high-volume data (textbooks, codebases) and hosts the local Vector Database. Connects to the Cloud via Tailscale for secure, private communication.
• Local Inference Engine: (Optional/Future) Ollama running on a local GPU to handle sensitive data processing without sending it to an external API.

B. The Logic Layer (The Multi-Agent Brain)

Using a framework like LangGraph, the system is divided into specialized agents:

• The Librarian (RAG Agent): Manages the Vector DB. It chunks and indexes PDFs from Drive/Office and retrieves them for technical Q&A.
• The Secretary (Scheduling Agent): Queries the relational DB and Notion API. It uses optimization logic to resolve scheduling conflicts.
• The Scout (Ingestion Agent): Runs background tasks to scrape the LMS and monitor the WhatsApp bridge for new information.

C. The Data Layer (The Memory)

• Structured Store (PostgreSQL): Stores hard data: user schedules, assignment metadata, and "status" flags (e.g., Is assignment X finished?).
• Unstructured Store (ChromaDB/PGVector): Stores embeddings of textbook chapters, chat logs, and class notes.
• State Management: Tracks the "Context" of current conversations across different platforms (e.g., starting a chat on WhatsApp and finishing it on the Desktop App).

---

3. High-Level Data Flow

1. Detection: An assignment is posted to the LMS or a deadline is mentioned in a WhatsApp group.
2. Processing: The Scout Agent pushes the data to the Cloud Orchestrator.
3. Analysis: The LLM extracts the Topic, Deadline, and Requirements.
4. Sync: * A Notion page is created with a checklist.
   • Related documents are pulled from Google Drive/Office into the Local Vault.
5. Proactive Notification: StudyX sends a WhatsApp message: "New project detected. I've indexed the requirements and added a study session to your calendar for Tuesday."

---

4. The Tech Stack

Component	Technology
Backend Language	Python 3.12+ (FastAPI)
Agent Framework	LangGraph (for stateful, cyclical agent logic)
Cross-Platform UI	Flutter (Android, iOS, Desktop)
WhatsApp Bridge	whatsapp-web.js (Node.js service)
Database	PostgreSQL + PGVector extension
APIs	MS Graph (Office), Google Workspace, Notion API
File Parsing	Docling or Unstructured.io

---

5. Implementation Roadmap

Phase 1: The "Observer" (Weeks 1-3)

• Deploy a FastAPI server to the cloud.
• Connect the Google Drive and LMS (Scraper) APIs.
• Implement basic logging to a PostgreSQL database.
• Goal: The system can "see" when a new file or assignment exists.

Phase 2: The "Memory" (Weeks 4-6)

• Set up the Vector Database (ChromaDB) on the local server.
• Build the RAG pipeline: automatically parse and index new files from Phase 1.
• Create a basic CLI tool to ask questions about the files.

Phase 3: The "Messenger" (Weeks 7-9)

• Integrate the WhatsApp Bridge.
• Implement the "Proactive" logic: the bot pings you when a new file is indexed.
• Connect the Notion API to automatically create pages.

Phase 4: The "StudyX App" (Weeks 10-12)

• Build the Flutter mobile/desktop interface.
• Enable "Tool Calling": Allow the UI to trigger terminal commands or local file moves.
• Final testing of the scheduling algorithm: $$S_{opt} = \max \sum (Importance \times Deadline_Proximity)$$

---

6. Project "Jarvis" Success Metrics

• Latency: RAG queries should return in under 3 seconds.
• Accuracy: 90%+ success rate in extracting dates from WhatsApp/LMS.
• Autonomy: The system should operate for 7 days without manual "re-syncing" or intervention.