I Run Multiple AI Coding Agents. My To-Do List Was the Bottleneck.

Posted on Oct 19 • Originally published at pub.towardsai.net

I work with several AI coding agents every day: Codex, Claude, Ollama, Pi, Antigravity, and Hermes. I love working in the terminal and in Obsidian. I am a technical program manager, not a career engineer. The agents write most of the code. My job is to decide what gets built, in what order, and how I know it is done.

That job broke down in an embarrassing place. My to-do list.

tkmd scheduling three tasks as a Gantt chart, straight in the terminal.

For tasks I used a rollover plugin in Obsidian. Every morning it copied each unfinished task into the new daily note. It never removed the old copies. I could not tell which copy was current. Neither could the agents. My tasks sprawled across the vault.

The rollover was never great, but I did not stop to fix it. I stopped when I went looking for when I had completed a task and found twenty-plus copies of the same unchecked task across my notes, with only one completed check among them.

The rollover list had a second problem. It was a list, not a plan. A list does not know that task B waits on task A. It does not know which tasks sit on the critical path. It does not know how much work is in flight. I manage programs for a living. My own task system ignored everything I know about running them.

tkmd is Task Markdown. Every task is a plain Markdown card with a small YAML header. I read and edit the cards in any editor. The agents read the same cards. One source of truth, in a format both sides already understand. The cards sync with my Obsidian Kanban board, so the board I look at and the files the agents touch never drift apart.

I chose Markdown on purpose. It is durable. It diffs cleanly in git. It greps. In ten years the cards will still open in any editor on any machine. No export step and no dead app.

Two ideas shaped the design. Neither came from software.

The first is queue management. In my MBA work I spent time on Little's Law, a supply-chain result that ties work in progress to cycle time. Keep starting work without finishing it and everything slows down. My rollover list was that law failing in front of me. tkmd records every state change in an event log and computes flow metrics from it. I see work in progress and mean time to close instead of guessing.

The second is how I run programs as a TPM. Big work gets decomposed. Dependencies are explicit. Nobody declares victory on their own. tkmd encodes those rules. It computes the critical path across tasks. An agent cannot close a task. It submits the work to a pending-close state with proof attached, and I sign off. An automated check runs before I even look at it.

A task moves through a short cycle. I claim it with tk c. The verification suite runs with tk eval. The work goes up for review with tk r. I close it with tk d after I check it. tk dep shows the dependency graph and the critical path. Every step is a command, and every command leaves a record.

An agent cannot skip straight to done. Say a task is owned by an agent and sits in ready or in-progress. The agent runs tk d or calls task_complete over MCP. tkmd intercepts the call. The task lands in pending-close instead.

An agent cannot pass on a failed check either. Each card can carry an eval command, a shell script that proves the work. tkmd runs it before any close. If the exit code is not zero, the transition is rejected. No green checks, no review.

Once a task sits in pending-close, I can tell the agent to close it. The agent runs tk d through its shell tool. The CLI runs as my user on my machine, so tkmd records the close as mine and marks the task done. The agent acts as my proxy.

The guardrail in one picture. The agent works above the line. Only you cross it.

That proxy is also the honest limit. tkmd enforces a workflow, not identity. Any agent with shell access on my machine can run tk d if I tell it to. For a strict sign-off, the convention is that I type tk d myself. The guardrail keeps the process honest. It does not replace judgment.

I built tkmd on my personal laptop over a weekend. Saturday and Sunday. It is my first Rust project. I did not write it in a traditional IDE. I built it entirely with Antigravity, running Google's Gemini 4 Argon, directing the work the way I direct any program: decompose, assign, verify, close. The tool and the method grew together.

I want to be honest about the limits. tkmd is young. It runs on one machine, with file locks instead of a server. The agents have not yet used it to break down a large project on their own. That is the next test, and I will write about what happens.

Most of the effort in AI tooling goes into making agents smarter. I think the harder problem is managing them. An agent team needs what any team needs: a durable plan it can read, explicit dependencies, and a definition of done that a human controls. Program managers have been working on these problems for decades. This is my version.

tkmd is open source under the MIT and Apache licenses, and the code is on GitHub. If you run agents and your task list looks like mine did, I want to hear how you handle it.