This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
I built a local AI system reliability agent that monitors a Windows computer, stores system metrics locally, analyzes trends, and uses Gemma 3 4B to provide reliability and maintenance recommendations.
The idea came from a simple problem:
A friend of mine often noticed that their computer would become slow or unresponsive, but figuring out why usually meant opening Task Manager and trying to interpret a long list of numbers.
The problem wasn't a lack of data.
It was understanding the data.
The Purpose
I wanted to build something that could answer a simple question for my friend:
"What's happening with my computer, and what should I check?"
Instead of another monitoring dashboard, I decided to build a local AI System Reliability Agent.
The Solution
The agent turns raw system activity into understandable reliability insights:
🖥️ Friend's Computer
↓
📊 Monitor
CPU • RAM • Disk • Network • Cache • Events
↓
🗄️ Store
Local SQLite History
↓
🔧 Analyze
Reliability & Trend Tools
↓
🤖 Understand
Gemma 3 4B + Ollama
↓
💡 Recommend
Clear Reliability & Maintenance Suggestions
So instead of only seeing:
RAM: 82%
my friend can get context about what the system has been experiencing and what they may want to investigate.
The agent doesn't automatically change the computer. It provides the analysis and recommendations while the user stays in control.
Monitor → Store → Analyze → Recommend.
That's the idea behind the project: make system reliability information easier for a real person to understand, while keeping their data and AI processing local.
DEMO LINK: AI System Reliability Agent
Dashboard
The dashboard shows the current system state and keeps the monitoring interface compact enough to remain useful while the machine is being used.
AI Reliability Analysis
The AI produces a structured assessment containing:
Overall status
Summary
Reliability findings
Evidence from collected metrics
Recommended ma
The complete project is available on GitHub:
This version keeps the working v3 monitoring dashboard and adds a fully local AI reliability layer.
Tkinter Dashboard
|
+---- local SQLite (system_metrics.db)
|
+---- FastAPI (127.0.0.1:8000)
|
+---- reliability tools -> SQLite
|
+---- Ollama -> Gemma 3 4B (local)
MCP server (stdio) exposes the same read-only reliability tools.
No system metrics are sent to a cloud AI service by this application. Ollama is configured for localhost.
Refresh metrics
The repository contains the monitoring application, SQLite data layer, FastAPI service, reliability tools, MCP server and local Ollama/Gemma integration.
The project is built with Python, Tkinter, SQLite, FastAPI, MCP, Ollama, and Gemma 3 4B.
The architecture is intentionally simple:
🖥️ Windows System ↓ 📊 Python Monitoring ↓ 🗄️ SQLite ↓ 🔧 Reliability Tools ↓ ⚡ FastAPI + MCP ↓ 🦙 Ollama ↓ 🤖 Gemma 3 4B ↓ 💡 Reliability Recommendations
The application collects CPU, RAM, disk, network, cache, and Windows event data and stores it locally in SQLite. Historical data gives the agent context instead of relying on a single snapshot.
The reliability layer provides read-only tools for retrieving metrics, history, cache information, events, and trends.
Gemma 3 4B runs locally through Ollama and receives the relevant reliability data as structured context. The AI then turns that information into a human-readable reliability assessment and maintenance suggestions.
I also exposed the reliability capabilities through a local MCP server, keeping the tools separate from the model.
For this project, open innovation made it possible to build the reliability agent around the user's machine instead of around a cloud AI service.
CPU, memory, disk, cache and system-event data can reveal information about how a computer is being used.
With local inference, the application doesn't need to send that monitoring history to a third-party AI API just to generate recommendations.
🧩 Control over the AI stack
The AI isn't locked into a single hosted API.
I can change the model, prompts, reliability tools, or inference layer without redesigning the monitoring system.
The project separates data collection → tools → AI reasoning, which makes the system easier to experiment with and extend.
🛠️ Open tools made the architecture possible
Using Python, SQLite, FastAPI, MCP, Ollama and Gemma gave me control over each layer.
For example, when Gemma 3 4B through Ollama didn't support the native tool-calling approach I initially tried, I didn't need to redesign the entire application around a closed API.
I changed the architecture so Python executes the read-only reliability tools and passes their structured results to Gemma:
SQLite
↓
Python Reliability Tools
↓
Structured Context
↓
Gemma 3 4B
↓
Recommendation
That flexibility is what open innovation meant for this project:
I could adapt the system to the model instead of adapting the entire project to a closed AI service.
And because inference runs locally, there is no per-request cloud AI API cost. The trade-off is that the user's computer provides the hardware and electricity needed to run the model.