Your Coding Agent Has a Built-in Task Manager, But It Shreds the Task List Every Session.

Roman Studenikin — Tue, 29 Sep 2026 07:20:00 +0000

Do you need a task manager for your AI agent? It already has one. You just can’t access it.

Give a coding agent something complex and watch what it does first: it splits the work into subtasks, shows you a checklist, and ticks items off as it goes. That checklist is a task manager. It’s also implicit and ephemeral. It dies when the agent decides the work is done, or when the session ends — and every design decision, rejected alternative and open question recorded along the way dies with it.

It’s like tracking all your work on paper and shredding each page the moment the item feels complete. It might not be complete. Tomorrow you might find out a follow-up is needed, and by then the original design notes are gone. Months later, nobody — not you, not a colleague, not the next agent — can explain why the code ended up the way it did.

This article is about making that task list explicit, external and permanent. And you don’t need a fleet of agents to benefit. One agent in one repository is enough, because a single agent is already a team: every new session is a new teammate who has never met the previous one.

The markdown trap

Once you agree that decisions have to outlive the session, the obvious move is: “I’ll just have my agent keep documentation as it works.” That’s what most people do, and it works — for about a week.

Then the files pile up. PLAN.md, PLAN-v2.md, NOTES-auth-refactor.md. Nobody can tell which ones are still relevant and which outdated. The agent reads all of them and trusts the stale ones as much as the current ones, and at some point the notes start costing more than they save: they quietly poison the context of every session that loads them. Many of us have been there.

The problem isn’t that the agent writes things down. It’s that a folder of prose has no status, no structure and no query. You can’t ask it “what’s still open?”, “what’s blocked on what?” or “why did we drop the SQLite backend?”

What a task manager really is, for an agent

Some time ago I read Steve Yegge’s post about his task tracker designed for coding agents to use from the terminal. Around the same time I noticed that nearly every multi-agent orchestration tool has a task manager at its core. That’s not a coincidence. Tracking tasks is the tip of the iceberg. Underneath, a task manager is:

Structured, queryable long-term memory. Decisions are attached to the work they were made for, and carry a status that says whether they still apply.
A dependency graph. What has to happen before what — so “what should I do next?” has a computed answer instead of a guess.
Auditable handover interface. Between agent and human, and between today’s session and tomorrow’s.

That last one is why this matters for one agent and not only for fifty. A hand-off between sessions is still a hand-off. We coordinate our own work through task trackers; our agents should too.

A real, queryable backlog: taska’s own store — open tasks and dependency tree:

Why I built my own

When I read that post I got goosebumps — the feeling you get when you’ve just understood something important. I installed beads straight away and pointed my agents at it.

I was disappointed quickly. In my setup its database kept drifting out of sync, records went missing, and my agent spent a lot of its time working out how to use the tool and recover lost records instead of doing the actual work. It also wanted a fairly invasive change to my git setup and a specific workflow. beads’ author did a great job on the features and thought deeply about agent integration — the ideas were right. The foundations just weren’t right for how I work.

So I started building my own: simple, predictable, non-invasive, and fitting whatever workflow you already have. I’ve been building it for months, adding features only when they proved necessary. It’s called taska.

The core idea: an append-only log, in your repo

taska keeps the whole task database in your git tree, as an append-only log of mutation events — the same technique high-throughput databases use to absorb concurrent writes. Here the point isn’t throughput — it’s branch merging.

Most in-repo trackers store tasks as markdown files or as one JSON file. If two branches touch the same task, that’s a merge conflict — and now your agent is resolving JSON conflicts by hand. beads sidesteps that by keeping its database out of your git history, synced through a git ref of its own.

taska’s model is simpler. ta init registers a git merge driver that handles exactly one file — the task log — and sees nothing else. When branches merge, it combines both sides’ events and settles them per field: “the agent set status=review on its branch” and “I set priority=high on mine” both survive. No database, no daemon, no git hooks, no server — and no way for it to corrupt any of your other files.

Your fields, one syntax

The log is what makes taska robust. What makes it pleasant is that it doesn’t put you in a box.

Every tracker I tried came with a fixed set of fields — title, priority, owner — and a flag for each: -t my-task -p high -o alice. In taska you decide what fields a task has: declare a strict schema in the config, or let it grow as you go. Either way, creating, updating and filtering use one syntax:

$ ta create fix-login title=”Fix login redirect” priority=high owner=alice notes=”Suspect the session cookie”
$ ta update fix-login status=review notes+=”Root cause: stale cookie, fixed in auth.rs”
$ ta list priority=high status=review

No flags to memorize — not for you, and not for your agent. And when you or an agent mistypes a field name, the write is refused instead of silently inventing a new field:

$ ta update fix-login titel=”oops”
error: `titel` is not a field any task uses — did you mean `title`? (pass — new-field to add it as a new column)

Arbitrary fields, one syntax for writing and filtering, and a typo caught with a did-you-mean

What changed with a single agent

I’ve used taska on personal projects and at work for months now, and I keep using it because it makes a real difference:

Decisions survive sessions. A new session picks up where the last one stopped, including why it stopped there. Can query anytime, months later.
Ideas stop getting lost. A thought that comes up mid-task becomes a task that is impossible to lose.
Technical debt gets filed instead of buried. This one surprised me. Agents take shortcuts, sometimes deliberately. With a tracker in the loop they file follow-up tasks for that debt before reporting completion — so it gets fixed later instead of silently disappearing inside a long session.
The code gets better. Mostly as a consequence of the three above.

taska tracks its own development this way. Since May: 136 tasks, 130 of them closed, and every design decision still queryable.

And when one agent becomes many

The same properties that help one agent are what a multi-agent setup needs. I recently added features for exactly that and tested them with 14 agents running at once, handing work to each other through taska. Your workflow can scale to as many agents as you want, taska will never be a bottleneck.

Try it

$ curl -fsSL https://raw.githubusercontent.com/justpresident/taska/master/scripts/install.sh | bash
$ cd your-project && ta init

(Or cargo install taska. Windows binaries are on the releases page.

Then restart your agent. ta init adds a short section to your AGENTS.md or CLAUDE.md, so the agent knows how to use the tracker from its very first session. On Claude Code there’s also a plugin: /plugin marketplace add justpresident/taska, then /plugin install taska@justpresident.

Give it something non-trivial to plan, then look at ta list and ta dep tree yourself. You’ll look at agent workflows differently after a week of this — I’m fairly sure of it.

DEV Community: Roman Studenikin

An easy way to make your agent predictably better