# ReplyLater: I Gave My Inbox the Night Shift to Reclaim My Me Time > Source: > Published: 2026-10-25 12:37:10+00:00 *This is a submission for the [Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady](https://dev.to/challenges/hacktoberfest-week3-2026-10-19)* **The Sloth Philosophy:** Sloths don't hurry, stress over backlogs, or react to every stimulus in real time. They pace themselves, conserve their energy, and let the world catch up. *Go to sleep with an inbox full of obligations. Wake up with next week's replies ready.* ReplyLater is a local-first, open-source AI co-pilot that turns a chaotic email backlog into an organized, week-ahead action board. Most AI email tools compete for your attention while you're already trying to read and respond. ReplyLater takes a different approach: **batch the work, let it run in the background, and review the results when you're ready.** The workflow is simple: `.eml` backlog or email export. ReplyLater can classify messages, extract commitments such as *“Send the revised design deck by 2 PM,”* identify unanswered questions, and prepare reply drafts. When key information is missing, it is designed to flag the uncertainty rather than invent an answer. The people who benefit are anyone who ends the week with an inbox full of obligations: students, freelancers, developers, and busy professionals who want to spend less energy on inbox triage and more time on meaningful work. The hosted demo may have different privacy characteristics from a local installation. Use synthetic or non-sensitive email samples when testing a hosted instance unless its data-handling behavior has been verified. The project is organized around a React dashboard, a FastAPI backend, local model inference, durable workflow orchestration, and persistent semantic memory. ReplyLater is built as a modular, local-first application: `gemma2:2b`), running locally through Ollama.` temporalio`). ``` +------------------------------------------------------+ | React + Vite Dashboard | | Needs Your Call | Week-Ahead Queue | Info/Closed | +----------------------------+-------------------------+ | REST API | +----------------------------v-------------------------+ | FastAPI Backend | +------------+-------------------+---------------------+ | | +------v------+ +------v------+ +----------------+ | Temporal | | Local Gemma | | PostgreSQL | | Workflow |<--->| via Ollama |<--->| + pgvector | | & Activities| | | | | +------+------+ +-------------+ +----------------+ | +------v-------------------------------------------+ | Sentry Observability | | Custom spans, latency, errors | +--------------------------------------------------+ ``` The key design principle is separation of concerns: Temporal coordinates long-running work, FastAPI exposes application functionality, Gemma handles language tasks, PostgreSQL stores persistent data, and Sentry helps diagnose failures. Gemma supports two main tasks: Local batch processing can be interrupted by inference delays, hardware limits, or other transient failures. Temporal's `OvernightEmailPrepWorkflow` coordinates the process through separate activities for parsing, semantic retrieval, extraction, and draft staging. Configured retry policies help recover from transient failures, while controlled concurrency helps avoid exhausting local CPU or GPU resources. Sentry is used to help inspect inference and workflow behavior, including custom spans, execution latency, activity transitions, and Ollama HTTP errors. Token counts are tracked where available. PostgreSQL and pgvector provide a semantic retrieval layer. Relevant sent-email examples can help the system condition drafts on a user's preferred greetings, phrasing, and sign-offs. Email contains some of our most sensitive information: personal correspondence, financial documents, travel plans, health messages, and work commitments. Sending all of that content to a hosted AI API should not be the default. Open-weight models and open-source infrastructure made a local-first architecture possible: This is not a claim that every deployment has zero network traffic. Privacy depends on the actual configuration, including telemetry, hosting, and any external integrations. The goal is to make local processing practical and keep private correspondence out of hosted model inference by design. The point of ReplyLater is not to make people answer email faster every minute of the day. It is to reduce the number of decisions waiting for them when they sit down to work. In a test run using **30 `.eml` messages**, the observed results were: | Metric | Result | |---|---| | Total processed emails | 30 | | Total batch execution time | 3 min 48 sec | | Average inference latency | 2.82 seconds per message | | Emails requiring replies | 18 | | Messages routed to “Needs Your Call” | 5 | | Receipts/digests auto-archived | 7 | | External email-content egress during local inference | 0 KB under the tested configuration | These are results from one test corpus, not a universal performance guarantee. The missing-information precision result should be interpreted in the context of the sample and labeling method. The intended payoff is a calmer start to the week: fewer repetitive triage decisions, commitments surfaced before they are forgotten, and drafts ready for human review. ReplyLater stages drafts; it is not intended to send messages without the user's review. ReplyLater is intended for the following partner categories, based on the technologies used: Please confirm these categories match the challenge's official eligibility and submission rules before publishing. Technology shouldn't just accelerate how quickly we react; it should protect our attention and conserve our energy. With open-weight models like **Gemma**, durable orchestration through **Temporal**, and observability from **Sentry**, ReplyLater explores a calmer way to handle the inbox: prepare the work while you rest, then let a human make the final call. **Shut your laptop. Get some sleep. Let ReplyLater prepare Monday morning.**