I have a Quick Notes topic in Telegram. It is the nearest thing my personal system has to an input box: send a sentence from my phone and let the machinery put it somewhere useful. The first version was efficient in the way a paper shredder is efficient. It could turn a message into a calendar entry or task, but it did not understand that a thought, a reference, a question, and a commitment are different things. ...
My Google Tasks lists used to have a polite but important lie built into them. They mixed things I needed to do with work my AI assistant, Closp, could do. A reminder to make a phone call sat beside a research job Closp was perfectly capable of completing. Both appeared in the same list, in the same form, as if both were waiting for me. That is not a shared system. It is an AI quietly adding its own homework to the human’s pile. ...
I already run OpenClaw on my server. It handles the useful day-to-day layer: Telegram conversations, scheduled jobs, notifications, research, summaries, and the accumulating collection of small automations that make a personal assistant worth having. So at first glance, Claude Code Remote Control looked redundant. Why put another AI interface on the same box when I can already talk to OpenClaw from my phone? Because they solve different problems. OpenClaw is my normal control plane. But when an OpenClaw update breaks that control plane, I need an independent way back in. In the past that meant SSH from a laptop with the right keys. Fine at a desk; useless when the laptop is shut, elsewhere, or simply not with me. ...
Most notification systems do not have an information problem. They have a presentation problem. The email system had already done the hard work. In an earlier post, I described the scoring pipeline that separates mail needing an immediate alert from messages that can wait for the evening summary or a later review. More recently, I wrote about removing recurring junk at the source, rather than merely teaching the filter to tolerate it. ...
I’ve been running an AI personal assistant (via OpenClaw) for a couple of months now. It checks my emails, sends me a daily news digest, prepares GTD rituals, tracks weather before my morning runs, and does a dozen other things automatically. Last week I noticed something off: I hadn’t received a daily email notification in a while. Not an error. Not a crash. Just… silence. The job was running. The logs looked fine. But nothing was arriving. ...
I’ve been running a personal AI assistant for a few months now — handling email triage, GTD rituals, news digests, morning run reminders, and a bunch of other cron-driven automation. It’s genuinely changed how I operate day-to-day. But here’s something I’ve learned the hard way: the model underneath everything matters more than you’d think. The Reasoning Problem At some point I had extended reasoning enabled on my assistant. In theory, this should make responses more thoughtful — the model “thinks before it speaks.” In practice, it made every message reply a slow, verbose rewrite of whatever I’d asked. Inconvenient enough that I just switched it off. ...
Most AI assistants start fresh each session. They read their instructions, follow them, then forget everything. Mine doesn’t. It maintains its own documentation, reviews it daily, and proposes improvements. The Core Idea My AI assistant (ClawdBot) wakes up each session by reading workspace files: AGENTS.md – its operating instructions SOUL.md – personality and voice USER.md – who I am, what I prefer TOOLS.md – local configuration (Telegram topic IDs, RSS feeds, routing rules) MEMORY.md – long-term memory memory/YYYY-MM-DD.md – daily logs These files evolve. When I say “remember this,” it updates them. When it learns something, it writes it down. ...
A quick recap: I’ve been experimenting with a “GTD copilot” that runs as a personal daemon and does the boring parts of planning: scanning inboxes, creating properly-scoped tasks, looking ahead at the calendar, and sending a single clean briefing. This post is a field report: the minimal structure that made the system useful, plus the guardrails that stopped it turning into task spam. Why this works (the GTD pain points) If you’re doing GTD seriously, the pain is rarely “I don’t know what to do.” It’s: ...
My name is Timur Davletshin. I’m a software engineer with a long-standing passion for personal productivity. I’ve been practicing Getting Things Done for the last 10 years. The methodology itself has never been the problem — the problem has always been the tooling. GTD asks you to maintain an inbox, a task tracker, a calendar, reference files, and a regular review habit. In practice that means juggling three or four apps, copying things between them, and spending real effort just keeping the system running. Every few years I’d burn out on the maintenance overhead and start over with a new stack. ...