A small follow-up after deliberately testing RTM alternatives

Since writing my original post, I have deliberately tested several RTM alternatives rather than relying on feature lists or first impressions. Todoist received the most serious evaluation because its modern API, official CLI, SDK and MCP support initially made it look like the stronger backend for AI agents.

Then a surprisingly revealing difference appeared in the most trivial place imaginable: my shopping list.

I use both systems in German. My completed shopping history contained three items:

- Zitrone — lemon
- Zitronensaft — lemon juice
- Zitronensäure — citric acid

All three German words contain the search term “Zitrone”. I asked the agent to find everything matching that term, including completed tasks, and put Zitronensaft back on the shopping list.

RTM’s MCP search immediately returned all three completed items, together with their lists, status and category tags. The agent could identify the existing Zitronensaft task and uncomplete it directly. Its metadata remained intact.

More importantly, RTM treated the agent’s change as a server-side transaction and explicitly returned:

completed: false
undoable: true
transaction_id: ...

That is not merely an “undo button” in a user interface. It is agentic undo: an autonomous tool can make a change, receive a transaction ID and reverse that exact operation programmatically if necessary. In my direct comparison with Todoist, I found no equivalent transactional safety mechanism exposed to the agent.

Todoist can list completed tasks through separate history tools and can reopen a task once its ID is known. But its normal text search does not include completed tasks, while the completed-task interface available to my agent is date-oriented rather than a direct search across historical task content. Without already knowing the date or ID, the same natural request becomes far less direct.

So the supposedly old system won this very modern test:

Queryability → Historicity → Mutability → Reversibility

There is something fitting about Remember The Milk revealing this advantage through a grocery list. RTM does not merely remember that I once needed lemon juice. It lets my agent find that memory, restore it with its context intact and safely undo the restoration.

My conclusion after testing the alternatives is that modern integration breadth alone does not determine whether a task manager is a good agent backend. RTM’s searchable completed history and transactional undo are unusually valuable strengths.

If RTM is looking for a natural modernization path, an official CLI exposing the same search language, completed-task access and transactional undo would be extremely valuable.

MilkScript already provides powerful server-side automation, and I do not mean that a CLI should replace or duplicate it. What is still missing is a supported external command-line interface for ad hoc queries and mutations, shell integration, exports, debugging and recovery — ideally with stable JSON output and access to transaction IDs and undo.

The roles would be complementary: MilkScript for workflows running inside RTM, MCP for AI agents, and a CLI for humans and deterministic external automation.

Whatever you modernize next, though, please do not “improve” these properties away. What may look like legacy behavior is exactly what makes RTM remarkably well suited to trustworthy AI agents.

## A broader conclusion after testing and researching the alternatives

Since my previous follow-up, I have widened the comparison considerably.

I directly tested Obsidian Tasks, Todoist and TickTick. I also researched Lunatask, Amazing Marvin, Godspeed, Superlist, Taskwarrior, Nirvana, Vikunja, TaskTrove, Tasks.org with CalDAV or Nextcloud, and Super Productivity.

Some of these systems are excellent. Several are more modern in specific areas. Todoist has an official CLI, Markdown, a modern API, an actively developed MCP and strong calendar integration. Other products offer attractive interfaces, local-first storage, self-hosting or deeper project-management features.

But after looking at the entire field, I keep arriving at the same unexpected conclusion:

Remember The Milk may be a much better product than its own developers realize.

RTM gets a collection of fundamentals right that competitors often treat as separate or secondary features:

- fast, predictable interaction
- powerful boolean search
- Smart Lists that are real saved queries
- tags that remain meaningful across active and completed tasks
- completed tasks that stay part of the searchable system
- mature recurring-task behavior
- a simple and consistent data model
- server-side transactions and genuine undo
- MilkScript for internal automation
- a complete structured export
- an unusually solid mobile experience
- and now an official MCP that exposes much of this to agents

Individually, none of those features sounds revolutionary. Together, they form an unusually coherent task engine.

The completed-task model is especially important. In RTM, completion changes a task's state without making it disappear from the conceptual place where it belongs. I can remain inside a tag, list or search context, switch to completed tasks, inspect history and reopen an item with its metadata intact.

During my Todoist test, I completed a task carrying the label @Urlaub. It immediately disappeared from that label view. The label became a view of active tasks only. The completed task still existed, but I could reach it only through its original container, the separate completed-task search or the activity history. If I no longer remembered that the task had originally lived in the Inbox, the label itself provided no path back to it.

That sounds like a small interface difference. In practice it reveals two different data philosophies.

Todoist treats completed work largely as history attached to containers. RTM lets completed work remain part of the task database that can still be queried through the same vocabulary of lists, tags, status and text.

This matters for reusable shopping lists, recurring procedures, personal records and agent-assisted workflows. An agent should not need to know when something was completed or which original container held it before it can find it again.

The same applies to undo. An agent inventing a compensating operation is not equivalent to reversing the exact server-side transaction. RTM's transaction model is old technology in the best sense: mature, explicit and safe.

None of this means RTM should stand still. There are still clear gaps:

- The MCP must be dependable enough to serve as operational infrastructure.
- An official CLI should expose search, CRUD operations, notes, tags, completed tasks, transaction IDs and undo with stable machine-readable output.
- Notes need at least a small Markdown subset: headings, lists, links, emphasis and code.
- Product communication and roadmap visibility need substantial improvement.

The Markdown request illustrates the communication problem. The original forum request has existed since 2006 and now contains 79 comments. A request remaining unimplemented is understandable. No product can implement everything. What is difficult to accept is that customers still cannot tell whether the request is being considered, rejected or simply unseen.

Slow development is not necessarily a problem. Silence is.

Even "not planned" is more useful than twenty years of uncertainty.

I do not think RTM needs to publish confidential plans or promise release dates. Nor does it need to become open source. But it does need a visible path from customer feedback to a product decision.

One possible lightweight workflow would be:

Forum or discussion -> triage -> accepted feature request -> tracked issue or internal task -> visible status -> release note

GitHub Discussions and Issues could support this, but the exact platform is less important than the process. A public request could carry a simple status such as:

- needs information
- under consideration
- planned
- not planned
- released

Duplicates could be linked, interested users could subscribe to updates, and accepted requests could be transferred automatically into the team's internal backlog. The implementation work could remain completely private.

This would not create an obligation to build every requested feature. It would do the opposite: it would let the team say no clearly, consolidate duplicate requests and concentrate attention on the few changes that genuinely matter.

The recent MCP release demonstrates that RTM is capable of meaningful modernization without damaging the simplicity of the core product. It was a surprisingly forward-looking addition, and it fits RTM's underlying strengths extremely well. That makes the current reliability problems particularly unfortunate: the MCP has already become important enough that users notice immediately when it is unavailable.

After this whole evaluation, I do not want RTM to imitate every competitor. I do not need another collaboration suite, document manager, AI chat interface or constantly redesigned productivity platform.

I want RTM to recognize and protect what it already does exceptionally well, modernize the few interfaces that now hold it back, and communicate clearly enough that customers can trust its future.

The foundation is not obsolete. In several important respects, it is still ahead of the market.