Manish Kumar

Manish Kumar

Full-Stack Developer

Mahatama Jyotiba Phule Rohikhand Universityfull_time, internship, freelance
Open to roles
Languages: PythonTypeScriptJavaScriptSQL
SAVIOUR.OS — The Atmospheric Deadline Shield Terminal

SAVIOUR.OS — The Atmospheric Deadline Shield Terminal

SAVIOUR.OS — AI Multi-Agent Productivity & Digital Memory Operating System SAVIOUR.OS is an AI-powered multi-agent platform that combines intelligent productivity management with contextual digital memory. Rather than functioning as another reminder application, it proactively predicts workflow risks, coordinates specialized AI agents, and helps users recover before deadlines become failures. The platform demonstrates how autonomous AI agents can collaborate to analyze tasks, optimize schedules, generate recovery strategies, and assist users through contextual conversations. Problem Statement Traditional productivity tools depend on users to constantly monitor dashboards and notifications. Under pressure, reminders are often ignored, schedules become fragmented, and there is little support for recovering from missed deadlines. SAVIOUR.OS addresses this by shifting productivity from passive reminders to proactive AI-driven intervention. Multi-Agent Architecture The application is built around five independent AI agents, each responsible for a specific workflow. Task Breakdown Agent – Converts large goals into structured milestones. Auto-Scheduler Agent – Detects scheduling conflicts and optimizes timelines. Delay Mitigation Agent – Creates recovery plans and professional extension emails. Companion Chat Agent – Provides contextual productivity guidance through natural conversations. Crisis Triage Agent – Assists users after missed deadlines with actionable recovery strategies. Key Features: AI-powered task decomposition Intelligent deadline risk analysis Dynamic schedule optimization Recovery planning for delayed work Google Calendar synchronization Gmail draft generation Voice-enabled AI assistant Pomodoro focus sessions Habit tracking and productivity analytics Progress dashboard with insights

3 media files · youtube.comView
QueueCure AI -Clinic Queue OS

QueueCure AI -Clinic Queue OS

Most neighbourhood clinics still use paper tokens and verbal announcements, leaving patients waiting for hours without knowing their turn. Receptionists manage the entire queue manually, making delays and mistakes common. QueueCure AI replaces this with a simple browser-based system where receptionists manage the queue from one dashboard and patients scan a QR code to see live queue updates and accurate wait times no app installation required. Process I started by extracting the three binary tests from the brief before writing any code: add patient under 10 seconds, live sync without refresh, ETA from real data. Solving those three tests in order determined every architecture decision. For real-time transport I evaluated three options: polling, Server-Sent Events, and WebSockets. Polling adds 1–2 second average latency and wastes bandwidth. SSE is unidirectional — the receptionist can't send events back on the same channel. Socket.IO WebSockets gave bidirectional push under 100ms with built-in reconnection and room-based broadcast — one emit hits every connected screen simultaneously. For state I chose in-memory over a database. A neighbourhood clinic sees 50–100 patients per day. The entire queue fits in under 100KB of RAM. Results All three binary evaluation tests pass: patient token assigned in 3.2 seconds (target under 10), patient screen updates in under 100ms without any page refresh, ETA switches from manual estimate to real rolling average after 3 consultations. Concurrent "Call Next" race condition handled via mutex — tested with two simultaneous socket events, only one executes. Patient screen reconnects after disconnect and receives full current state immediately no stale data. The one-sentence clinic owner moment: watching the patient waiting room screen flip to the new token number on a phone across Reflection I would add browser SpeechSynthesis API for audio token announcements in the first iteration — it requires zero infrastructure, works in any browser, and is critical for clinics with a TV display where patients may not be looking at the screen. I would replace the in-memory mutex with Redis SET NX EX 2 from day one. The boolean flag works for single-node Node.js but breaks silently when you add a second server. Making the architecture horizontally scalable should be a default assumption, not an afterthought. I would also add SQLite as a daily audit log alongside the in-memory queue.

2 media filesView

This is Manish’s work on Wooble.

Build a profile that shows what you can do — and share it anywhere.

Build yours