K@workflow on Martin Sukany

Bridging reMarkable and Emacs Org-mode

Thu, 12 Mar 2026 00:00:00 +0000

Why I still write on paper

There’s something that happens when I pick up a pen that doesn’t happen when I open a new buffer. The thinking is different — less filtered, less structured, more honest. Ideas that would never survive the friction of forming a heading and choosing a tag actually get written down. First drafts of decisions, rough task lists, things I’m trying to work out, all of it lands on paper before it’s ready to be digital.

I’ve tried replacing this with digital tools. Org-capture is excellent for structured input, but for capturing a fleeting thought mid-meeting or sketching out a problem while commuting, I still reach for paper. The reMarkable is my compromise: it’s close enough to writing on paper that it doesn’t disrupt the thinking, and close enough to a computer that the notes don’t stay trapped on dead wood.

The problem is that notes on a reMarkable and notes in Org-mode don’t naturally talk to each other. This post is about the pipeline I built to close that gap.

The two tools and why they complement each other

The reMarkable is good at one thing: letting you write without getting in the way. The e-ink display doesn’t glow, doesn’t notify you, doesn’t tempt you to check anything. The battery lasts days. The pen latency is low enough to feel like paper. Cloud sync happens automatically in the background — you don’t think about it. For first-pass capture of any kind of thinking, it’s hard to beat.

Org-mode is good at different things. It’s plain text, version-controllable, programmable. It integrates with agenda, GTD-style workflows, time tracking, archiving. When information is in an .org file, the full Emacs ecosystem is available — you can schedule it, tag it, refile it, clock time on it, link it to other notes. For organizing and acting on information, it’s where I want everything to end up.

The gap is obvious. reMarkable is where I write things down. Org-mode is where things become actionable. Without a bridge, I was manually transcribing notes — which defeats most of the point of capturing on the device in the first place.

How the sync pipeline works

The pipeline has three stages: download, recognize, and structure.

Download is handled by rmapi, a command-line client for the reMarkable cloud API. It downloads notebooks as .rmdoc files — the native reMarkable format, which is essentially a zip archive containing per-page binary stroke data and metadata. I run this for each notebook I want to sync.

Recognition is where handwriting becomes text. I use the MyScript Cloud API, which accepts raw reMarkable page data and returns recognized text. The API is HMAC-authenticated, accepts batched requests, and handles Latin-script handwriting well enough for practical use. The free tier covers 2000 pages per month, which is more than I need.

One piece of engineering worth calling out: hash-based deduplication. Before sending a page to the API, the script computes a hash of the page content and compares it against a local cache. If the page hasn’t changed since the last run, it’s skipped. This matters in practice — a 20-page notebook where you’ve written 2 new pages today sends 2 pages to the API, not 20. Quota is preserved, and the run takes seconds.

Structuring is handled by a Python script that takes the raw recognized text from MyScript and organizes it into Org format. Each notebook becomes an .org file; pages become headings or entries under headings, depending on how the notebook is organized. The results land in emacs-org/remarkable/, organized by notebook name. A notebook called “Projects” on the device becomes emacs-org/remarkable/Projects.org on disk.

The whole thing runs nightly via cron at 02:00. By the time I open Emacs in the morning, yesterday’s handwritten notes are already there.

Notebook structure on the device

I keep three notebooks on the reMarkable that feed into this pipeline: Projects, Areas, and Quick Sheets.

Projects holds working notes tied to specific projects — meeting notes, rough plans, things I’m working through. Areas holds reference material and ongoing concerns that don’t have a deadline. Quick Sheets is the capture inbox: whatever I write when I don’t want to think about where it belongs yet. Random ideas, to-do items, things to look up, fragments of thought.

After nightly sync, Quick Sheets becomes the Org file I triage first. Something like “Call Jan re: contract renewal — deadline Friday” appears as a plain text entry. Turning it into a scheduled TODO in Emacs takes ten seconds. The capture happened on paper; the action lives in the agenda.

What works well

HWR accuracy for clean, reasonably paced handwriting is high enough to be useful without heavy editing. Not perfect — there are occasional word-level errors — but close enough that the recognized text is readable and the context is always restorable even when individual words are off.

The automation itself is reliable. Once the cron job is set up, I don’t think about it. Notes appear. The hash deduplication means I can re-run the script manually without worrying about duplicates accumulating.

The Org integration is the payoff. Once notes are in .org files, everything Emacs offers is available. Tags, scheduling, refiling into project files, linking to related notes — none of that required any special work on the reMarkable side. The device just needed to get the text into a file.

Limitations and honest trade-offs

The Czech diacritics problem is real. Fast or slightly sloppy handwriting, especially with Czech-specific characters like ě, š, č, ř, produces more recognition errors than clean Latin script. “Přečíst knihu o Kafkovi” might come out as “Precist knihu o Kafkovi”. Readable and context-restorable, but not clean. For notes that matter, a proofread pass is necessary.

Symbols don’t transfer. Diagrams, arrows, flowcharts, mathematical notation — anything that isn’t text is either garbled or empty in the output. A page with a hand-drawn architecture diagram produces only the text labels, if anything. This is a known constraint of the HWR approach, not a bug in the implementation.

The pipeline is one-directional and always will be. reMarkable is a capture device. You write on it; the notes flow to Org. Nothing flows back. This is fine for my workflow, but worth stating clearly.

There are two external dependencies worth noting. rmapi requires reMarkable cloud credentials — if you don’t want to use the cloud, this pipeline doesn’t work as described. MyScript is a third-party API that requires registration and could change pricing or availability. The free tier has been stable, but it’s not self-hosted.

Sync is nightly, not real-time. If I write something at 10pm and need it in Emacs immediately, I run the script by hand. But the default cadence is once a night, and for most of what I write, that’s enough.

How to replicate this

The setup requires some comfort with Python, command-line tools, and cron. It’s not complex, but it’s also not a one-click install.

Tools you need:

rmapi — CLI for reMarkable cloud. Handles authentication and .rmdoc download. (GitHub: juruen/rmapi)
MyScript Cloud API — Handwriting recognition. Register at developer.myscript.com for a free API key. The batch endpoint accepts reMarkable page data directly.
Python 3 — For the post-processing script that structures recognized text into Org format. Standard library is sufficient; no exotic dependencies.
cron — For nightly scheduling.

The rough flow: configure rmapi with your reMarkable credentials, register for a MyScript API key, wire up the Python script to call both, point it at your Org directory, and schedule it. The deduplication cache is a simple JSON file mapping page hashes to recognized text — straightforward to implement.

I’m not publishing the script as a ready-made package because it’s too tied to my specific notebook structure and Org conventions. But the components are all documented, the API is straightforward, and the overall architecture is simple enough to re-implement in an afternoon.

The result: I write on paper and my agenda knows about it by morning. Not magic — just a cron job and a working API key.

Why I Use Two AI Assistants Instead of One

Thu, 12 Mar 2026 00:00:00 +0000

I stopped asking my personal AI assistant to write code. That decision — more than any prompt engineering trick or model upgrade — improved the quality of what I get back. This post is about why, and what the setup actually looks like in practice.

The problem with asking your personal assistant to write code

My personal assistant, Daneel, knows a lot about me. It tracks my calendar, triages my email, controls my Home Assistant devices, remembers past conversations, and generates a morning briefing before I’ve had coffee. That rich context is exactly what makes it useful for life-admin. It’s also exactly what makes it a poor choice for writing code.

When I asked Daneel to refactor a script in a session already loaded with calendar events, email threads, and device states, the suggestions came back hedged, occasionally irrelevant, and harder to trust. The model wasn’t broken — it was trying to reason across too many unrelated domains at once. Calendar management and Go module refactoring are not related problems, but they were sharing the same context window, and that matters.

I think of it as desk space. A programmer works better with a clean desk focused on one problem than with every open project, email, and to-do list spread across the surface. A language model’s attention works the same way. Pack enough unrelated context into the window and the model starts making connections that aren’t there, hedging where it should be precise, or simply losing the thread.

What each agent actually does

The split is clean by design. Daneel is the persistent layer — always on, full life context, memory across sessions, proactive. It handles the entire life-admin surface: heartbeats, email triage, Home Assistant automations, calendar nudges, morning briefings. It knows who I am and what I’m doing across every domain of my life. That’s its job.

Claude Code is the specialist. It’s on-demand, scoped to a repository, and knows nothing about my calendar or email unless I explicitly tell it something. When it gets a task, it gets a working directory and a description. That’s the full context. Nothing else bleeds in.

The analogy that fits best is a generalist doctor versus a surgeon. Your GP knows your full medical history — that breadth is valuable for holistic care. But when you need surgery, you want the surgeon focused on the procedure, not briefed on your tax situation. The surgeon’s narrow focus is a feature, not a limitation.

Why narrow context produces better code

The difference is observable before it’s explainable. When Claude Code gets a task with only the relevant repository in scope, the output is sharper. It references actual code, proposes concrete changes, and doesn’t pad responses with caveats about things it can’t see. When the same model does coding work inside a session loaded with unrelated context, the quality drops in ways that are subtle but consistent: more hedging, less precision, occasional suggestions that only make sense if you squint.

I haven’t run controlled experiments. This is observational. But the pattern is consistent enough that I’ve made it a rule: coding tasks get their own context, every time.

The mechanism matters too. Claude Code gets a specific working directory. It explores the repo, reads the relevant files, and builds its understanding from the code itself — not from my description of my life. That working-directory scoping is the primary context control, and it works.

How the handoff works

From my perspective, the interaction is simple. I tell Daneel what I want done: “refactor the caldav script to handle token refresh.” Daneel constructs the task, points Claude Code at the relevant file and any context it needs, spawns it as a background process, and monitors for completion. When it’s done, the result arrives in Matrix. I haven’t switched tools or changed context myself.

The handoff is where the quality of the split lives or dies. Daneel has to construct a precise task description — if it’s vague, Claude Code still gets a muddled context, and the problem just moves upstream. Writing a clear task handoff is a real skill, and I’ve had to tune it. But a well-constructed handoff is much easier to get right than expecting a single model to maintain useful quality across a large mixed-domain context.

The user experience is a single conversation. The complexity — spawning, monitoring, result delivery — is hidden. That’s the point.

The trade-offs I live with

This setup is not free. Two agents means two failure modes, two configurations, and a non-trivial orchestration layer. When something breaks, it’s not always obvious whether the problem is in the task description, the spawning mechanism, or Claude Code itself. Debugging the pipeline is its own skill.

There’s also latency. Spinning up a coding agent for every task has overhead. For a quick one-liner, it’s overkill. The split pays off for tasks with real scope — a refactor, a new feature, a bug that requires reading multiple files. For something trivial, I still just ask Daneel directly and accept the slightly lower quality.

Maintenance is real. Two tools have separate update cycles, separate auth quirks, and separate failure modes. I’ve hit cases where an update changed the spawning interface, or where Claude Code’s behavior shifted between versions. Keeping both working smoothly is ongoing work, not a one-time setup.

And this setup assumes comfort with CLI tooling and configuration files. It’s not plug-and-play for someone who wants a simpler life.

What I’d do differently

I’d set up the context separation earlier. For too long I tried to get Daneel to do everything, and I blamed the model when quality was inconsistent. The issue wasn’t the model — it was me asking it to be two things at once.

If I were starting over, I’d also invest more upfront in the task handoff format. The quality of Claude Code’s output is almost entirely determined by the quality of the task description. Getting that right — concise, specific, with the right working directory and just enough background — is where the leverage is.

Would I set this up again? Yes. The cognitive overhead of the orchestration is less than the cognitive overhead of getting mediocre code back and figuring out why.

The principle here doesn’t require my specific tooling. If you’re using any combination of AI assistants — whether that’s two Claude sessions, a personal assistant alongside a coding agent, or even just separate chat threads — the same logic applies: don’t mix life-admin context with coding context. Keep them separate. The model on the other end will produce better output, even if it can’t tell you why.