The cheapest AI upgrade: let your agent write to your actual task list

Text output versus state you can act on

The upgrade is not a better model, it is letting the agent write into a system you already check, so its output becomes state instead of text you have to re-enter by hand.

Watch how most people actually use AI at work. You describe a situation, the model gives you a good answer, and then you do the real work: you read it, decide what matters, and type the follow-ups into whatever you actually use to run your week. The model produced text. You produced the state.

That last step is where the value leaks. Not because the answer was bad, but because a task that lives only in a chat transcript does not exist. You will not see it on Saturday morning. Your phone will not buzz about it. It is a good idea that died in a scroll buffer.

The fix is unglamorous and cheap. Give the agent write access to the one system you already trust enough to check. For me that is Apple Reminders, because it is on my phone, my watch, and my laptop, and because I open it without being reminded to. Any system with that property works. The point is that it is yours and it is already in the loop.

Once that connection exists, the shape of the interaction changes. You stop asking for advice and start asking for outcomes. "Go through this contract and put anything that needs my decision in Reminders with due dates" is a different request from "summarise this contract", and only one of them leaves something behind.

What this looks like day to day

The agent reads context you already have, decides what is actionable, and writes it into your list with real due dates and alarms, so the follow-up happens without you transcribing anything.

Some of the things this handles for me now, with no copying and pasting:

• After a client call, the agent reads my notes and creates the follow-ups, each with a due date that reflects what I actually committed to
• When I am reviewing a document, anything that needs a decision from me becomes a reminder rather than a highlighted line I will never revisit
• Recurring operational work (invoice runs, retainer check-ins) gets created on a schedule rather than existing in my head
• When I ask what is outstanding, the answer comes from the same list my phone is showing me, not from the model's recollection of our conversation

None of that is impressive AI. That is the point. The intelligence was already in the model. What was missing was a hand.

One detail worth knowing because it catches people out: on Apple's platforms, a due date and an alarm are two different things. A due date is metadata. The banner on your phone comes from an alarm attached to the reminder. If you set a date with no time, you get an all-day reminder that will sit there politely and never interrupt you. If you want the agent's reminders to actually fire, they need a time and an alarm. I found this out the way everyone does, by wondering why nothing buzzed, and the behaviour is consistent across the tools here because they all go through the same Apple API.

Picking the bridge: three options

Three mature macOS command-line tools connect an agent to Reminders, and they differ mostly in what permission they demand, how likely they are to break, and how much of Reminders they can reach.

The agent cannot talk to Reminders directly. It needs a command-line tool in between, and there are several good ones. I installed and used three before settling, on macOS 15.3.1 in September 2026.

	remindctl	rem	remctl
Language	Swift	Go	Python plus Swift helpers
Install	Homebrew	Homebrew	build from source
Build prerequisites	none	none	Xcode tools, Apple signing identity, a root-owned Python 3.13+
Full Disk Access	no	no	yes
Background process	none	none	persistent helper app
macOS floor	14+	13+	14+
Feature ceiling	Apple's documented API	plus tags, flagged, geofencing, shared lists, import and export	plus sections, subtasks, templates, grocery lists, attachments, assignees
Risk of breaking on an OS update	lowest	low, degrades with a warning	highest

Tested on macOS 15.3.1 in September 2026. Versions, feature sets and install methods move, so treat the table as a snapshot and check the repos before you commit to one.

A fourth, keith/reminders-cli, is the most popular of the lot and deliberately the most minimal. If all you want is to add and complete reminders from a script, it is the boring correct answer and you can stop reading this section.

The interesting split is between the top two and the third. remindctl and rem both go through EventKit, the API Apple documents and supports. remctl does that too, but it additionally reads Apple's Reminders database file directly. That is why it can do things the other two cannot, including sections, subtasks and templates. It is also the entire reason it needs a permission the others do not.

Worth separating two risks that get confused. Both rem and remctl touch Apple's private ReminderKit framework, which Apple can change without warning. That is a stability risk, and rem handles it gracefully: if Apple breaks the tag lookup, you get a warning and the rest keeps working. Reading the database file is a different thing entirely. That is a permission risk, and it is the one that has consequences beyond the tool itself.

The permission question

Full Disk Access cannot be scoped to a single folder, so a tool that needs it to read your Reminders data is also, technically, a tool that can read everything else.

macOS gates the Reminders database behind Full Disk Access. There is no narrower permission available. You cannot grant access to that one folder. You grant access to everything or nothing, and then you trust the code.

I want to be fair to remctl here, because it is genuinely well built. I read through it before installing: no network calls at all, no sudo, no shell injection, it verifies its own helper's code signature before trusting it, and it refuses to install on a Python interpreter that any non-root process could tamper with. That last one is a real piece of security thinking. The helper holds Full Disk Access, so if its interpreter were writable by you, anything running as you could rewrite the interpreter and inherit that access. The author closed that hole on purpose, at the cost of making installation harder. The code is not the problem.

The problem is the shape of the permission. The trust boundary on macOS is "same user". Anything running as you can reach a helper that holds Full Disk Access, and increasingly, a lot of things are running as you, including AI agents you have given a terminal to. That is a wider surface than I want in exchange for subtasks.

I did test whether you can run remctl without granting it. You can, sort of, and on my machine it was not usable: you can create reminders but you cannot complete, edit or delete them, and the documented fallback for listing today's items crashed outright on my real data. That was one Mac on macOS 15.3.1, and the author targets much newer versions, so your result may differ. A one-way task list is worse than no task list.

So the permission question, asked properly, is not "is this tool safe". It is: what is the smallest permission that gets me the outcome, and does the extra capability justify going above it? Here it did not. Tags, flags, geofencing and shared lists cover what I actually do. Sections and templates are nice. They are not worth a standing grant to read my whole disk.

If you want the general version of that question for any tool you let an agent use, four things settle it: what permission does it need, which process ends up holding that permission, what breaks when the OS updates, and what still works if you say no. Note that the second one matters independently. remindctl asks you to grant Reminders access to your terminal application, which means everything you run in that terminal inherits it. remctl isolates the grant into one signed helper, which is better containment and is exactly why it needs a signing identity and a background process. Neither is wrong. They are different trades, and you should know which one you made.

Setting it up

I went with rem: Homebrew install, no Full Disk Access, no background process, and it ships agent skill files so the agent learns the commands without you writing a prompt for them.

The install is two commands, because Homebrew now asks you to trust a third-party tap before using it:

brew trust bro3886/tap
brew install BRO3886/tap/rem-cli

Read the formula before you run the second one. Trusting a tap is a real trust decision, not a paperwork step. This one is minimal: a pinned release tarball, a checksum, and an install line. No post-install script, no sudo, no shell calls. One honest caveat: Homebrew installs a prebuilt binary from GitHub Releases, and the checksum guarantees the bytes match what the formula author saw, not that those bytes match the public source. If that distinction matters to you, build from source with Go instead.

The part that made the difference is the last step:

rem skills install --agent claude

That writes skill files the agent reads, so it knows the command surface without you describing it in a prompt every time. This is the pattern worth internalising well beyond this one tool. An agent is only as good as what it knows how to operate, and the tools that ship their own instructions are quietly far more useful than the ones that make you write the instructions yourself.

First run will prompt for Reminders access. That is the ordinary permission dialog every Mac app shows, and it is the only one you need.

Where this fits in a second brain

Write access to a real system is what separates a knowledge base an agent reads from one it maintains, and the task list is the easiest place to prove it.

I have written before about what an AI second brain actually is, and the argument there is that chat memory is not one, because it remembers you without working for you. This is the same idea at its smallest possible scale. The difference between an agent that tells you what to do and an agent that puts it on your list is the difference between a notes app and an operating system.

Reminders is a good first connection because the stakes are low and the feedback is immediate. If the agent creates a bad task, you delete it in two seconds. You learn quickly what it is good at deciding and what it is not, and you learn it on something that cannot damage anything.

Once that is working, the same pattern extends. Calendar. Your CRM. Your project tracker. Each one is the same three questions: what does it need permission to do, what does the agent gain by reaching it, and what happens when it gets something wrong. Start with the one where a mistake costs you two seconds.

The broader point for anyone running a business on this stuff: the gap between founders getting a lot out of AI and founders getting a little is almost never the model. It is whether the model can reach anything. Most people are still using the most capable systems ever built as a very expensive typist.

---

If you are working out which of your systems an agent should be allowed to touch first, book a call or have a look at how I approach agentic workflows.