Share your best AI workflow. We could show it to 2M+ people.

I built a local memory system for Claude that is a bit different from others I have seen. The reason was familiar: repeated context loss and gaps, even within projects. I am not technical—I come from a healthcare background—so it was essentially vibe-coded, but I used a method I had not seen elsewhere. I started by interviewing Claude about what would be useful to it, rather than beginning with only what I wanted. The three biggest gaps were the rationale behind decisions, current versus historical states, and the difference between global and project-level detail. We also identified ways memory can go wrong, including stale facts being confidently asserted as truth and rejected ideas resurfacing. Claude’s built-in memory stores flat topics without entity links, captures what but not why, is not well temporally grounded, and is gated by Claude. I researched other memory builds, from homebrew systems to enterprise tools, and found that they generally fell into three groups: - Vector dumps, which lack rationale and supersession and can become stale - Plain Markdown with grep or embeddings, such as Basic Memory, which similarly lacks real temporal grounding and an entity graph - Heavyweight knowledge-graph stacks such as Neo4j, LangChain, and GraphRAG None of these did what I wanted. My store holds entities only, not transcripts. It stores decisions, observations, people, and projects connected by typed edges. Each entry has content, a scope—either portfolio-worthy or working detail for one project—a rationale, and information about where it came from. The system is also bitemporal, so it distinguishes what is current from what is not. Nothing is edited in place: a correction adds a new assertion instead of overwriting the old one. Underneath, it uses SQLite, with sqlite-vec for semantic search and FTS5 for keyword search. Nothing writes automatically. Claude has to propose a memory, and I have to approve it. This prevents the store from filling with noise, keeps it token-efficient, and acts as a governance lever. MCP links Claude to my server. It is local-only at present, although there is potential to add remote access in the future. The server provides instructions for making proposals, so the system is theoretically portable, and I also created a Claude skill to accompany it. I ran the build across multiple projects and created specialist projects for different roles: - A central development and oversight project served as the decision-maker and prompt-writer. - Cowork handled the building and tested each module inside a sandbox. It had no authority to change decisions, and I used a fresh project for each stage of the build. - I handled deployment separately by typing every command on the server and pasting the output back. - I repeated Claude’s Cowork-authored tests on the actual server. Real-world testing after deployment identified only minor issues, which were quick to fix. This separation was administratively heavy because I had to keep switching between projects as tasks started and finished, but it caught several errors in the rules and code. Despite my lack of technical knowledge, the project is now well documented and I have room to develop it further. I may eventually put it on GitHub. It has become a standard component of my workflows, my projects are tracked much better, and Claude and I are on the same page more often.

I record a meeting on my phone and send the audio file to my Telegram chat with Hermes, my local AI agent. That is the only trigger—there is no app, upload page, or extra step. Hermes runs on my PC through WSL and handles the rest locally, except for the LLM analysis. Step-by-step: 1. Send the audio via Telegram. I drop the meeting recording into my Telegram chat with Hermes. 2. Create the meeting record. When Hermes receives the audio message, it calls a FastAPI endpoint at `localhost:8200`. The endpoint creates a meeting record and uploads the file. It is a thin Python server backed by SQLite, using async SQLAlchemy. 3. Transcribe the meeting locally. The backend runs faster-whisper on my PC, so there is no cloud transcription API or transcription cost. It handles large files and produces the full text with timestamped segments. 4. Identify the speakers. A diarization pass determines who spoke when. I can optionally upload a 10-second voice sample for each person; the system stores MFCC features and can automatically label speakers such as “Steve” and “Andrew” in future meetings. Diarization is best-effort, so transcription still works if it fails. 5. Analyze the transcript with an LLM. The transcript and timestamped segments are sent to DeepSeek through the OpenRouter API. A single structured prompt extracts: - A TL;DR - Thematic topic groups - Decisions made - Open questions - Risks flagged - A participant list - Tags - Proposed action items, each with an owner, priority, due date, confidence score, source timestamp, and the exact transcript quote it came from 6. Send action items to the todo app. Each proposed task has a Create in Todo button. With one click, I send it to my separate local `agent-native-todo` service on port `8100`, along with the meeting title, evidence quote, and timestamp as context. The todo app runs independently; the meeting app only calls its REST API. 7. Review everything in the web miniapp. The results appear in a React SPA at `/miniapp/`, which includes a meeting list, FTS5 full-text search, transcripts with clickable timestamps that jump to the corresponding point in the audio, color-coded tasks, speaker name editing, and audio playback with seek. The stack is: - Backend: Python FastAPI, async SQLAlchemy, and SQLite - Transcription: faster-whisper, installed with `pip install faster-whisper` - Diarization: pyannote.audio or a similar tool; optional because transcription works without it - LLM: OpenRouter API with DeepSeek, using one structured prompt and JSON mode - Frontend: React, Vite, and plain CSS without a framework - Agent glue: Hermes Agent receives Telegram messages and orchestrates the API calls - Todo integration: Any task app with a REST API; the meeting app only needs to POST to it The only part that costs money is the LLM analysis step, which costs about $0.01 per meeting through DeepSeek. Everything else runs on my PC.

Michigan Campaign Finance Explorer turns public Michigan campaign-finance records into a user-friendly, searchable research tool. It automatically collects and validates official filings, then lets users compare candidates, trace transactions, explore races on a map, and visualize how money moves between campaigns, PACs, donors, and vendors—all with links back to the original records. The current public system only allows you to look up records one at a time, and you have to know what you’re looking for. I built a tool called Filing Radar to make that process more useful. Every 20 minutes, it searches all filings using Python’s built-in `urllib.request`. It compares filing IDs with those saved during the previous check. If a filing is new, it downloads it; otherwise, it moves on. For each new download, a parser built with `pypdf` processes the PDF and sends the data to a local SQLite database. I was concerned about overloading the public website with requests, so I also built a circuit breaker and added a limit on requests per second. I also built another tool called Vendor Resolver. Campaigns often record the same vendors in slightly different ways, such as “Little Caesars” and “Little Caesar’s.” Vendor Resolver groups transactions that are likely associated with the same entity and assigns a confidence score. It then ranks the groups by impact so the most useful matches are easier to review manually. Together, these tools make the site more useful when I’m trying to determine which PACs are connected to particular campaigns. Step-by-step: 1. I searched all filings every 20 minutes with Python’s built-in `urllib.request`. 2. I compared the filing IDs with those saved during the previous check and downloaded only new filings. 3. I processed each new PDF with `pypdf` and stored the results in a local SQLite database. 4. I used a circuit breaker and a requests-per-second limit to avoid overloading the public website. 5. I grouped differently named vendors, such as “Little Caesars” and “Little Caesar’s,” and assigned confidence scores to likely matches. 6. I ranked those matches by impact so I could review the most useful ones manually. 7. I used the resulting data to identify connections between PACs and campaigns.