DEV Community: Aadi Jain

SlothOps: An Autonomous AI Coding Factory That Works While You Sleep

Aadi Jain — Sat, 24 Oct 2026 18:32:24 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

SlothOps is an autonomous software-maintenance system that takes repetitive GitHub issue-to-PR work off a developer's hands. Instead of manually investigating every issue, tracing dependencies, implementing fixes, running tests, and writing PR descriptions, you queue up eligible issues and let the factory work through them.

The goal is simple: wake up to investigated issues, isolated code changes, test results, and draft pull requests ready for human review. This is not another chatbot suggesting code snippets. It is a persistent engineering workflow that carries tasks across multiple steps, recovers from failures, and preserves progress without requiring a human to supervise every tool call.

The project is deliberately conservative about irreversible actions. It prepares code and draft PRs, but it does not merge its own work. Reliability and verifiability matter more than PR volume.

Demo

Working project under active development. The current development target is Recon-OS, a repository with multiple issues involving data loaders and document ingestion. The factory has been used to prepare feature PRs for plain text, Markdown, JSON, HTML, CSV, and remote URL ingestion.

Live end-to-end demonstration with real workers and review feedback is the next milestone. Recent smoke tests encountered provider timeouts and free-tier limits, which is exactly the kind of failure the orchestration layer is designed to handle gracefully.

Code

Thrizzio / agent-factory

agent-factory

View on GitHub

How I Built It

Architecture

Python orchestrator and SQLite: Python acts as the control plane. SQLite stores durable task state and supports recovery, retry tracking, and reconciliation. The model is not the source of truth for whether a task completed—that status must come from recorded state and verifiable outcomes.
Multiple AI workers: The system uses different workers for reasoning, implementation, and review. The current setup has explored OmniRush, Antigravity, and the OpenCode CLI, with different models and availability constraints. Worker selection and fallback distinguish successful execution from errors, timeouts, unavailable services, and situations requiring human intervention.
Git and GitHub integration: Git worktrees provide task isolation—concurrent or unfinished tasks cannot contaminate one another. GitHub is used to retrieve issues, communicate progress, push branches, and create or update draft PRs. The factory reconciles remote state before retrying operations, so an interruption after a successful GitHub action does not produce duplicate comments or PRs.

The Reliability Problems I Am Trying to Solve

Building the happy path is only part of the project. Much of the engineering effort goes into the failure cases:

Long-running subprocesses: Workers may stall or fail without useful messages. The orchestrator needs real deadlines, non-blocking supervision, bounded output collection, and process cleanup. A silent log is not proof that a process is stuck.
Worker availability and fallback: AI services run out of capacity, hit usage limits, or become unavailable. The system classifies failures, applies bounded retries with backoff, and preserves work instead of endlessly launching new attempts. Fallback is not permission to weaken the review policy.
Idempotent GitHub operations: An operation can succeed remotely even if the local process crashes before recording the result. The factory reconciles GitHub comments and PR state with SQLite records before retrying.
Changes across multiple PRs: Several PRs may modify related interfaces. The system detects stale branches, resolves conflicts carefully, reruns checks, and obtains fresh reviews when code changes.

Quality and Safety Gates

The factory is designed around deliberate constraints:

No automatic merging or automatic merge enablement.
Required reviewers must approve the exact same final commit SHA.
Changes made after review require fresh review.
Failed or unavailable reviewers do not count as approvals.
Repair attempts are bounded.
Uncertain or unsafe situations are marked as blocked instead of being silently treated as success.

An autonomous coding system should be allowed to do repetitive work, but it should not be allowed to redefine success just because it ran out of time or model capacity.

Why Does Open Innovation Matter?

The broader goal is to make autonomous coding workflows inspectable, adaptable, and less dependent on a single proprietary service. Open-source agent tooling and open-weight models make it possible to:

Inspect and customize the execution harness: A developer should understand and change how the automation works, rather than accepting an opaque agent's decisions.
Swap models or providers when availability, cost, or quality changes.
Run suitable models locally or on infrastructure under the developer's control.
Keep repository code and task data within a chosen environment when the deployment supports it.
Reproduce and improve the workflow without depending entirely on a closed, fixed implementation.

Note on the current implementation: The orchestration layer is Python and SQLite, but some workers rely on hosted AI services. The current system should not be described as fully offline, fully local, or entirely powered by open-weight models. Those are deployment possibilities to investigate and demonstrate, not claims to make without evidence.

The open-source approach matters because the developer should be able to understand and change how the automation works. A closed API would make the workflow a black box—you could submit issues and hope for PRs, but you could not inspect the review logic, modify the safety gates, or run the entire pipeline on your own hardware.

My Agent Session

DevRelay session coming soon. This project was built in an extended pair-programming session exploring orchestration architecture, failure classification, and worktree isolation.

The Lazy Payoff

SlothOps is designed to reward a developer for doing less repetitive work without lowering the quality bar.

Software maintenance involves a surprising amount of tedious work. Even a small issue can require reading unfamiliar code, tracing dependencies, reproducing a bug, implementing a fix, running the correct checks, preparing a PR, and responding to feedback. That is a 15–25 minute context-rebuild tax before any real engineering starts—per issue.

With SlothOps, you queue an eligible issue and return to review the evidence and proposed changes. The factory handles the investigation and implementation workflow. You spend your attention on architecture, difficult decisions, and the changes that actually require human judgment.

The central idea: Laziness and engineering discipline do not have to conflict. Good automation handles the repetitive work while preserving the checks that make the result trustworthy.

Prize Categories

Categories pending final review of partner requirements. Primary fit:

Best Use of Open-Source AI — SlothOps is built around the principle that autonomous coding workflows should be inspectable, adaptable, and not locked to a single provider. The orchestration layer and safety gates are fully open, and the architecture explicitly supports swapping models and providers.

SlothOps is a work in progress. The goal is to establish that the factory can reliably complete a task, not merely that it can start one. The strongest demonstration would begin with a real, appropriately scoped issue and end with a draft PR that includes a clear explanation, an isolated reviewable implementation, reproducible test results, independent review against the final commit, natural GitHub communication, a recoverable task history, and no hidden bypasses when a worker fails.

Focus67Dumby: A 100% Offline, Vision-Aware Sticky Note That Tells Coding Tutorials from Brain-Rot

Aadi Jain — Sat, 17 Oct 2026 19:00:28 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

The Problem: The "Coding Tutorial vs. Brain-Rot" Dilemma

As developers, students, and freelancers, we all know the pain of opening YouTube to watch a 15-minute system design breakdown or documentation walkthrough—and waking up 45 minutes later deep in a YouTube Shorts or gaming rabbit hole.

Existing productivity tools fail developers in two ways:

Traditional Website Blockers (Cold Turkey, Freedom): They are blunt hammers. They block all of YouTube or Reddit indiscriminately, which immediately breaks your workflow when you actually need a coding tutorial or debugging thread.
Cloud AI Activity Trackers (Rize, Reclaim): They charge $15+/month subscriptions to continuously stream your window titles, private repo names, and screen activity to third-party servers—an absolute non-starter for privacy-conscious engineers or freelancers working under client NDAs.

The Solution: Focus67Dumby

Focus67Dumby is an ultra-lightweight, 100% offline floating sticky-note accountability companion powered by local open-weight models (gemma4:e2b, gemma4:e4b, qwen3-vl:2b, gemma3:1b, and gemma3:270m) via Ollama.

It sits quietly in the corner of your screen like a minimalist 350x530 dark-amber sticky note. You lock in what you are working on (e.g., "Fix Express auth middleware"), pick a sprint duration (25m), and choose your local Ollama model. In the background, it observes your active window transitions and downscaled in-memory screenshots (512x288) to distinguish productive work and relevant tutorials from off-task entertainment—nudging you back on track without ever sending a single byte of data to the cloud.

Who Would Pay For It? (The Side Hustle Model)

Developers, indie hackers, and remote freelancers suffer from horrific subscription fatigue. Because Focus67Dumby runs 100% on the user's local hardware via Ollama, our marginal cloud inference cost is $0.00. That allows us to sell the packaged Pro Desktop Edition as a $19 One-Time Lifetime License (zero recurring monthly fees, zero cloud telemetry) alongside a free self-built open-source edition.

Demo

🌐 Live Product Landing Page & Interactive Checkout Demo: https://focus67dumby-landing-page.onrender.com/
💻 Desktop Application & Source Code: https://github.com/Thrizzio/Focus67Dumby

(Tip: On the live landing page, you can interact with the Sticky Note preview directly, test the checkout flow, and explore the local architecture!)

Code

Thrizzio / Focus67Dumby

A tiny, privacy-first desktop accountability widget that uses local open-weight AI (Ollama + Gemma) to tell coding tutorials apart from YouTube rabbit holes.

📌 FocusDumbyDumb (FocusSticky)

Stop blocking all of YouTube. Just block the brain-rot.
An ultra-lightweight, 100% offline floating sticky-note accountability partner powered by tiny local open-weight models (gemma3:270m / gemma2:2b) via Ollama.

💡 Why This Exists

Traditional website blockers are blunt hammers—they either block YouTube completely (breaking your workflow when you need a system design breakdown or documentation tutorial) or let you slip into a 45-minute Shorts rabbit hole. Meanwhile, cloud AI productivity trackers stream your private window titles and screen data to third-party servers while charging a monthly subscription.

FocusDumbyDumb lives as a tiny, frameless sticky note in the corner of your screen:

Lock in your goal & timer (e.g., "Fix Express auth middleware — 45 mins").
Pick your local model dynamically from your Ollama installation (gemma3:270m uses <400MB RAM).
Stay accountable privately: A background watcher evaluates active window changes locally in ~40ms. Coding tutorials pass…

View on GitHub

How I Built It

Focus67Dumby was engineered around small, fast open-weight models running locally through the Ollama REST API (http://127.0.0.1:11434), wrapped in a modular Python 3.11 desktop architecture (CustomTkinter + Win32 ctypes + Pillow).

1. Local Open-Weight Models Used (Gemma & Qwen)

Through live discovery via Ollama's GET /api/tags, the sticky note dynamically populates a dropdown so users can hot-swap models based on their hardware:

gemma4:e2b & gemma4:e4b (Primary Multimodal Vision + Text Engine): Google's compact open-weight Gemma models evaluate both the foreground window title and a compressed 512x288 base64 screenshot payload via POST /api/generate in strict JSON mode.
gemma3:270m & gemma3:1b (Ultra-Edge Text Mode): For users on low-spec laptops running on battery, gemma3:270m (~290MB footprint) evaluates window titles in sub-50ms using almost zero RAM.
qwen3-vl:2b & qwen3.5:2b: Supported as drop-in open-weight vision alternatives for reading small UI text inside split-screen browser tabs.

2. Solving Real-World Desktop Edge Cases

Building a local AI watcher that actually feels good to use required solving several gnarly systems challenges:

👁️ Hybrid Vision + Perceptual Diff Caching (<3% Threshold): Window titles alone can be deceptive (e.g., Chrome just saying "LinkedIn" when you're actually playing the LinkedIn Zip puzzle game, or watching a coding tutorial with a vague title). In Vision Mode, window_watcher.py grabs an in-memory screenshot, resizes it to 512x288 (JPEG quality 65), and computes a fast 16x9 grayscale perceptual signature. If the screen pixels change by <3% and the window title is identical (like reading static documentation), it hits the local session cache (0ms latency, 0 GPU calls).
⏱️ 30-Second Workspace Calibration & Multi-Window Breadcrumbs: Real engineering tasks span multiple windows (VS Code + Terminal + Localhost Browser + Google OAuth popups). During the first 30 seconds of a sprint, Focus67Dumby enters a Workspace Calibration Phase, automatically whitelisting the windows you touch into a trusted workspace (0ms instant switching), plus tracking a rolling 4-window breadcrumb trail so the model understands when a secondary login popup was spawned from your primary task.
🚨 Two-Strike Grace Period & Escalating Interference: Quick Alt-Tabbing never triggers a false alarm. If you stay on an unaligned distraction for 2 consecutive checks (Strikes 2, 4, 6...), it fires your chosen interference level:
1. Gentle Toast (Native Windows notification with custom auto-generated .ico icon)
2. Toast + Sound (System audio alert + toast)
3. Popup Takeover + Sound (Forces the sticky note to the front via Win32 WS_EX_APPWINDOW, flashes the border bright red, and physically shakes the widget horizontally on screen until you get back to work).
🐧 Headless Linux & Docker Determinism: All GUI (customtkinter), screen-capture (Pillow), and Win32 (ctypes.windll) imports are lazily guarded so the app runs a deterministic offline CLI simulation (python -m src.main --headless --demo) and passes all unit tests inside a clean headless Linux Docker container in 0.75s.

Why Does Open Innovation Matter?

This is a product category that literally cannot exist as a sustainable, trustworthy business on closed-source cloud APIs:

Absolute Data Sovereignty (Zero Screen-Spying): To know whether you are watching a React tutorial or scrolling memes, an AI needs to see your window titles and screen context. Sending screenshots of a developer's desktop every 10 seconds to a closed cloud API means leaking .env files, proprietary company source code, private messages, and banking tabs to external servers. Running gemma4:e2b or gemma3:270m locally on 127.0.0.1 guarantees that screenshots never even touch the disk—they are evaluated in RAM/VRAM and immediately discarded.
Unit Economics That Make a $19 One-Time Price Possible: Polling a frontier vision API every 10 seconds across an 8-hour workday equals 2,880 multimodal API calls per user per day. With closed API pricing, a single heavy user would burn through $20–$40+ in token costs every single month, forcing a bloated recurring SaaS subscription. By running open-weight Gemma models locally on the user's existing hardware, inference costs $0.00 forever.
Zero Vendor Lock-In & Offline Freedom: Whether a user has an 8GB VRAM GPU running gemma4:e2b in Vision Mode or an older laptop running gemma3:270m on CPU while studying on a train with zero Wi-Fi, the open-weight architecture adapts to them—and still includes a deterministic heuristic fallback if Ollama isn't running.

My Agent Session

I built and verified this project using an agent-driven workflow anchored by strict repository guardrails (AGENTS.md, ARCHITECTURE.md, MISTAKES.md, and a custom focus67dumby-master skill specification).

Instead of letting coding agents hallucinate monolithic spaghetti code, the master skill enforced thread-safe queue.Queue() / root.after() UI marshaling, sub-60-word structured JSON prompts tailored for small models, Win32 foreground window detection, and an 8-point clean-Linux Docker rebuild gate verified by a 15-test pytest suite.

My First User

I put Focus67Dumby in front of its first real user—a college mate of mine who constantly battles the exact "open YouTube for a lecture/tutorial, end up watching random videos for an hour" loop during study and coding blocks.

How the Test Went:

What clicked immediately: He loved the floating sticky-note form factor and the fact that it wasn't a heavy browser extension or a full-screen dashboard app. Seeing the widget distinguish between a legitimate task window and off-topic browsing—plus the "Popup Takeover + Shake" interference mode physically shaking the sticky note on screen when he drifted off-task—got him genuinely excited about using it for daily sprints.
Real-world friction we discovered during testing: Early in our testing, we noticed that real workflows involve bouncing between multiple windows (like opening a secondary login popup or switching between a browser puzzle/task and a terminal), and that unchecking "Always on Top" on a frameless Windows widget could hide it behind the browser.
What we iterated on next: That feedback directly inspired our 30-Second Workspace Calibration feature (where the app automatically learns and trusts the tabs/windows you open in the first 30 seconds of a sprint) and our native Win32 taskbar persistence fix (WS_EX_APPWINDOW).
Would they pay? For students and indie devs, monthly subscriptions are a dealbreaker, which validated positioning the packaged desktop installer as a low, one-time lifetime utility while keeping the core repo 100% open-source.

Prize Categories

Best Use of Gemma: Focus67Dumby is built around Google's open-weight Gemma family (gemma4:e2b and gemma4:e4b for local multimodal vision-and-title classification, plus gemma3:270m and gemma3:1b for ultra-low-memory CPU edge classification) served locally via Ollama with strict JSON schema validation and keep_alive VRAM management.
Best Use of Entire: Shared the full agent-driven engineering workflow, session history, and repository memory artifacts (AGENTS.md, ARCHITECTURE.md, MISTAKES.md, and focusDumby67-skill.md) that governed why each module, thread-safety queue, and headless fallback exists in the codebase.
Best Use of Render: Deployed and hosted the Focus67Dumby interactive product front-end, sticky-note state simulator, and license checkout portal on Render with automated GitHub continuous deployment.

StrideQuest: Touch Grass, With a Little Help From On-Device AI

Aadi Jain — Sun, 11 Oct 2026 13:56:30 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Most applications compete to monopolize your screen time. StrideQuest is built on the inverse premise: use open-weight AI to nudge you out the door, turn your attention toward the physical world, and then get out of the way.

StrideQuest is a local-first outdoor scavenger hunt Progressive Web App (PWA). It transforms an everyday walk into a mini-expedition: select a quest, step outside, search for specific natural elements in your surroundings, and log what you discover. Browser-based image classification assists with identifying observations, while an integrated journal and progression loop make those outdoor discoveries rewarding to catalog.

What I Built

StrideQuest unifies a modular expedition engine, lightweight field journaling, and in-browser edge AI into a single installable web application.

7 Field Expeditions: Forest Floor, Waterside Explorer, Urban Nature, Seasonal Scout, Rock & Mineral Hunt, Wildlife Watch, and Micro-Adventure.
38 Curated Collectibles: A structured field catalog of botanical, geological, and natural features to observe across different biomes.
GPS & Elapsed-Time Tracking: Active session monitoring with threshold-based accuracy filtering and stationary drift rejection.
Camera-Based Observation Loop: Direct capture flow with viewfinder preview, retake options, and an upload fallback for legacy devices.
Local Field Journal: Observations and camera image blobs stored directly in IndexedDB, featuring filters for discovery state, category, and rarity.
Progression System: Earn XP, level up, and unlock eight distinct achievement badges tied to genuine outdoor activity.
Expedition History & Telemetry: Revisit past expeditions with logged duration, distance, and itemized findings.
State Recovery & Session Controls: Pause, resume, complete, or cancel expeditions on the fly; active sessions automatically recover across browser reloads.
Data Sovereignty: Full JSON import and export tooling for local journal data and metadata backups.
PWA & Offline Foundations: Includes a Web App Manifest, Service Worker caching, adaptive app icons, and an active network status indicator.
Safety & Privacy Guidance: Transparent notices detailing on-device storage mechanics and encouraging safe, non-intrusive outdoor exploration.

The goal is not to keep users staring at a screen mid-walk. The interface helps plan the outing and record discoveries, leaving the actual exploration entirely to the person on the trail.

Demo

Live PWA: https://gamified-irl-quest-system.vercel.app/

Note: StrideQuest is designed for mobile screens, where camera workflows and geolocation APIs function naturally. WebGPU availability, model download performance, and hardware camera behavior vary across operating systems and browsers.

Code

The project is fully open-source on GitHub:

Thrizzio / gamified-irl-quest-system

StrideQuest

StrideQuest is a local-first outdoor scavenger-hunt PWA for the DEV Hacktoberfest Week 1 Touch Grass challenge. It turns a short walk through a park, trail, garden, or city block into a lightweight field expedition: choose a target, put the phone away, photograph something only after stopping safely, and build a personal journal of what you noticed.

Challenge tags: #devchallenge #hf26challenge

Run locally

npm install
npm run dev

Open the localhost URL in a modern browser. Production checks are:

npm test
npm run build
npm run preview

Camera, GPS, wake lock, and service-worker behavior require HTTPS when deployed. localhost is treated as a secure context by browsers during development.

What is implemented

Dashboard with level/XP progress, a daily invitation, recent field notes, collection progress, measured distance, and local-model readiness.
Seven data-driven expeditions: Forest Floor, Waterside Explorer, Urban Nature, Seasonal Scout, Rock & Mineral Hunt, Wildlife Watch, and Micro-Adventure.
38 catalogue…

View on GitHub

The repository includes the complete client source, data models, test suites, and project documentation.

How I Built It

StrideQuest is built with React, Vite, JavaScript, and Tailwind CSS, leaning directly on modern web APIs for device hardware access and local storage.

Local-First Architecture and Privacy

StrideQuest operates without a custom backend server or a remote cloud vision API. All field observations, geographic metrics, and raw image blobs are stored client-side in IndexedDB, while interface configurations live in localStorage.

There are essential network considerations to note: the application bundle must be downloaded on first load, and the AI model weights and runtime assets are fetched from Hugging Face on demand. The local-first design ensures that user data and photos are not dispatched to a central analytics or storage server, rather than asserting that the initial download is zero-network.

The Service Worker caches the core application shell for subsequent visits. Offline AI inference has not yet been benchmarked end-to-end on a physical handset; complete disconnected inference requires all model chunks and runtime dependencies to be fully downloaded and cached locally before venturing off-grid.

On-Device Image Classification

The vision pipeline runs entirely in-browser using Transformers.js v3 and ONNX Runtime Web:

Vision Model: onnx-community/mobilenetv4_conv_small.e2400_r224_in1k
Execution Strategy: The classifier initializes lazily on first observation and operates as a shared singleton. It requests WebGPU acceleration when exposed by the browser environment and defaults to the multi-threaded WASM runtime otherwise.

The model is a generalized ImageNet-1K classifier, not a specialized taxonomic or botanical authority. Because generalized labels do not always map 1:1 to outdoor field objectives, StrideQuest implements confidence-weighted objective matching, surfaces top predictions transparently, communicates uncertainty honestly, and allows users to save manual observation entries whenever the model output is ambiguous.

Real-world latency, initial weight transfer sizes, and hardware thermal characteristics have not yet been rigorously benchmarked on physical mobile chips.

Persistence and Session Reliability

IndexedDB: Persists structured records for field observations, captured image blobs, completed expeditions, and achievement progress.
Session Safeguards: Expeditions handle pause, resume, finish, and interrupt flows, while localStorage maintains an active expedition checkpoint to restore state after accidental tab closures or mobile browser refreshes.
GPS Filtering: Haversine calculations discard positional updates with poor horizontal accuracy or stationary GPS drift.

Verification and Test Suite

Development verification included:

npm install
npm test — 4 test suites passed (6 tests verifying distance calculations, progression logic, and persistence schemas)
npm run build — Clean production bundle generated (with standard ONNX/Transformers.js bundle size notices)
npm run dev -- --host 127.0.0.1 — Dev server, web app manifest, and service worker validated with HTTP 200 responses

Why Does Open Innovation Matter?

StrideQuest explores what happens when open-weight models and web standards meet experiences outside the traditional screen-first paradigm:

Edge Intelligence: Running open-weight models in the browser shifts inference directly to consumer hardware, removing per-request cloud API dependencies and server hosting bills.
Auditability & Transparency: Open codebases and open weights mean users and contributors can inspect the prompt mappings, see confidence thresholds, and review exactly how their data is processed.
Intentional Technology: Open tooling allows developers to build software that serves as a quiet utility—documenting and encouraging physical activity—rather than optimizing for maximum screen engagement.
Iterative Community Growth: Contributors can readily test domain-specific fine-tunes (such as dedicated flora or fungi classifiers), refine objective heuristics, and optimize WASM/WebGPU pipelines across varied mobile hardware.

My Agent Session

Development architecture, state persistence schemas, and test suites were refined interactively with an AI coding assistant. Because this was completed in a local workflow without an external public DevRelay session link, no unverified third-party session URL is included.

Prize Categories

Primary Track: Hacktoberfest Week 1: Touch Grass Challenge (Overall Submission)

Step outside, keep your phone in your pocket between milestones, and let the real world be the main event.

devchallenge #hf26challenge

LifeOS: Giving AI Persistent Personal Context with Local Open-Source AI and MCP

Aadi Jain — Sun, 04 Oct 2026 16:46:48 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Most AI coding assistants suffer from severe amnesia. Every time you open a new conversation, context resets completely. You spend the first ten minutes re-explaining your tech stack, your active projects, your career goals, and how you want the AI to talk to you. Worse, when you hit burnout or feel stuck, commercial closed chatbots resort to generic, hollow reassurance: "You're doing great! Keep going!"

I built LifeOS for a close friend and fellow developer who was tired of repeating themselves across coding sessions and wanted an assistant grounded in their actual goals and ground-truth progress.

LifeOS is not another chatbot. It is a local-first personal context and memory layer built on top of the open Model Context Protocol (MCP). It indexes a local vault of plain Markdown files into a local PostgreSQL + pgvector instance using local ONNX embeddings, allowing any MCP-compatible agent (like Antigravity or local open-weight models) to retrieve personal context with strict provenance.

Key features include:

The Interaction Policy: Reads an explicit how_i_want_ai_to_treat_me.md user document that instructs the AI to separate emotion from evidence, challenge weak plans, and avoid empty reassurance.
Inspectable Provenance: Every retrieved memory returns exact source paths and headings (e.g., [Source: projects/chronolog.md | Heading: Architecture]).
Quarantined Memory Writes: Prevents agents from silently hallucinating or overwriting canonical user files—all agent-authored memories are strictly isolated to vault/memory/ with timestamps and metadata.

Demo

Here is an example interaction showing how LifeOS changes agent behavior:

User: "I feel like I'm wasting my time and making zero progress on my projects."

Standard Chatbot: "Don't be hard on yourself! Coding is tough, you're doing amazing!"

Antigravity with LifeOS:

Agent calls lifeos_get_instructions() and lifeos_get_context().

It identifies the user's explicit rule: Do not give empty reassurance; distinguish feelings from evidence; verify recent project milestones.

Agent calls lifeos_search("recent progress Chronolog PhysioEvidence").

Response: > "Let's separate how you feel right now from what the evidence says. According to projects/chronolog.md, you finalized the backend architecture this week. In learning/ai.md, you completed your embeddings implementation. What specifically stalled today—was it the auth bug in Chronolog, or are you feeling overwhelmed by context switching? Here is the smallest next action to take..."

┌──────────────────────────────────────────────┐
│ LIFEOS ARCHITECTURE                          │
│                                              │
│  Markdown Vault (Canonical Truth)            │
│       │                                      │
│       ▼                                      │
│  FastEmbed (BAAI/bge-small-en-v1.5)          │
│       │                                      │
│       ▼                                      │
│  PostgreSQL + pgvector (Derived Search)      │
│       │                                      │
│       ▼                                      │
│  LifeOS MCP Server (stdio protocol purity)   │
│       │                                      │
│  ┌────┴───────────────────────────┐          │
│  ▼                                ▼          │
│ Antigravity Agent            Local Ollama    │
│ (Cloud Reasoning)          (Gemma 2 / Qwen)  │
└──────────────────────────────────────────────┘

Code

Thrizzio / LifeOS-MCP-Local-first-agent-context-

LifeOS — Local-First Personal Context Layer for AI Agents

AI agents are powerful, but they have amnesia.
Every new conversation starts with zero knowledge of the person they are helping. Users are forced to re-explain their background, their goals, their active projects, and how they want to be spoken to.
LifeOS solves this by providing a local-first personal context and memory layer that gives AI agents access to the user's canonical knowledge through the Model Context Protocol (MCP).

    +-------------------------------------------------------------+
    |                      AI Reasoning Layer                     |
    |       Google Antigravity Agent  OR  Local Open LLM (Ollama) |
    +-------------------------------------------------------------+
                                   ▲
                          JSON-RPC │ over stdio
                                   ▼
    +-------------------------------------------------------------+
    |                      LifeOS MCP Server                      |
    |  - lifeos_get_context()         - lifeos_search()           |
    |  - lifeos_read_file()           - lifeos_get_instructions() |
    |  - lifeos_list_topics()         - lifeos_add_memory()       |
    +-------------------------------------------------------------+
            │                                             │
      Path Validation                               Vector Search
            ▼                                             ▼
+───────────────────────────+                 +───────────────────────────+
│   Canonical Truth Store   │                 │   Derived Vector Index    │
│   Plain Markdown

…

View on GitHub

The repository includes:

Complete Python implementation (lifeos/) with strict stdio protocol cleanliness.
Fully automated tests (24 passed unit and security tests covering path traversal and memory write isolation).
Committed synthetic public sample vault (examples/sample_vault/) with 17 realistic documents so anyone can clone and test it immediately.
Antigravity integration configurations (examples/antigravity/mcp_config.json) supporting workspace and global agent setups.
Docker Compose configuration for local PostgreSQL + pgvector.

How I Built It

LifeOS is engineered from the ground up around open-source AI and open standards:

Local Embedding Engine: FastEmbed running BAAI/bge-small-en-v1.5 locally via ONNX Runtime, generating 384-dimensional dense vectors with zero cloud API dependencies.
Vector Indexing: PostgreSQL with the pgvector extension running locally via Docker, using HNSW index lookups for fast cosine similarity search.
MCP Protocol Interface: An stdio-based server using the official Python MCP SDK exposing 6 core tools: lifeos_get_context, lifeos_search, lifeos_read_file, lifeos_get_instructions, lifeos_list_topics, and lifeos_add_memory.
Optional Local Open-Weight Reasoning: A modular fallback to Ollama running Google's Gemma 2 (gemma2:2b / gemma2:9b), enabling complete offline execution without sending tokens to any cloud API.
Real-time Synchronization: Built-in watchdog file observer that monitors vault edits and updates database hashes idempotently.

Why Does Open Innovation Matter?

Open innovation is not just a feature of LifeOS; it is the entire reason the project works:

Absolute Privacy for Vulnerable Personal Data: A personal context layer holds journal entries, mental burnout patterns, unfinished project drafts, and career ambitions. Trusting proprietary vector databases and third-party cloud LLM APIs with unencrypted personal journals is unacceptable. Open-weight models and local embeddings guarantee that sensitive user context never leaves local disk.
Canonical Truth Inversion (Zero Vendor Lock-in): In closed platforms, your memory is trapped inside a vendor's black-box database. In LifeOS, plain Markdown files on disk are the canonical source of truth. The database is merely a disposable index. If the database is deleted or an embedding model is upgraded, the entire vector store can be regenerated from scratch with python scripts/index.py --rebuild.
Model Independence: The user owns their memory layer. Whether Antigravity is using an advanced coding model, or you are running an open-weight Gemma 2 model offline on an RTX GPU on a train with zero Wi-Fi, the user's context remains identical and portable.

Prize Categories

Best Use of Gemma ($200 USD): LifeOS provides a dedicated local reasoning path powered by Ollama running Google's open-weight Gemma models (gemma2:2b / gemma2:9b), allowing the entire context-and-reasoning loop to run 100% offline.
Best Use of Tiger Data ($100 USD): LifeOS uses PostgreSQL and pgvector with HNSW vector indexing to store high-dimensional embeddings and execute similarity searches over local vault chunks.