I’ve written before that your AI agent needs a task manager, and I stand by it. Chat history is not project state. Context windows compact. Sessions end. If the work matters tomorrow, it needs to live somewhere tomorrow’s agent can find it.

The part I didn’t mention: not every task matters tomorrow.

Some work should disappear with the session. Turning all of it into durable project state doesn’t make your agent more organized. It gives the next session a bigger pile of bookkeeping to misunderstand.

Tasks Have Different Lifetimes

When we say “task,” we’re lumping together several different things.

“Add filtering to the search API” is a project commitment. It might take several sessions, affect other work, and need a record of why the behavior changed.

“Inspect the existing query code” is not a project commitment. It’s one step the agent needs to finish the larger task.

“Run the focused tests” is even shorter-lived. Once they pass and the result has informed the work, that checklist item has done its whole job.

These all deserve attention. They don’t all deserve permanent storage. I think about them in two buckets:

• Session tasks help the current agent organize execution. They live in a plan or checklist, then disappear when the work is complete.
• Durable issues preserve commitments, decisions, dependencies, and unfinished work across sessions.

The distinction isn’t importance. A database backup check can be a critical session task. The distinction is whether the information needs to outlive the work happening right now.

If it doesn’t, let it die.

Ephemeral Does Not Mean Sloppy

There’s a temptation to treat ephemeral tasks as unstructured work. Just tell the agent, plz fix and see what happens.

A session still benefits from a clear plan. The agent should inspect before editing, break a change into steps, mark progress, run focused tests, run the full quality gate, and verify the result. A visible checklist makes long work easier to supervise, and it reduces the chance the agent quietly skips the boring last step.

The checklist just doesn’t need to become part of the project’s permanent record. Picture something like this:

- inspect the repository method
- find every caller
- update the shared comparison helper
- add focused tests
- run the full suite

Those are excellent session tasks. They tell the agent how to move through one change. After the implementation lands, keeping all five around adds nothing. The commit and tests preserve the result. The issue, if one exists, preserves the reason.

An Issue Should Earn Its Permanence

A durable issue is more expensive than it looks. Someone has to write it clearly, connect dependencies, update its state, close it, and eventually decide whether it’s stale. An agent also has to read it. Every open issue becomes part of the project’s apparent reality.

That cost is worth paying when the issue preserves something important. I create one when at least one of these is true:

1. The work will survive the current session. If we’re likely to stop before it’s done, the next session needs a reliable handoff.
2. Other work depends on it. A dependency belongs in a system that can represent blocked and ready work, not in a paragraph buried in chat history.
3. It represents a real commitment. A user-reported bug, an accepted feature, or a promised follow-up shouldn’t vanish because a terminal closed.
4. The decision needs a record. If future maintainers will ask why the system behaves this way, the issue preserves context a diff can’t.
5. The work crosses boundaries. Changes spanning repos, services, migrations, or people need coordination beyond one agent’s checklist.
6. We found valid work but aren’t doing it now. That’s exactly what a backlog is for.

If none of those apply, a session task is probably enough.

Promote Work When It Changes Shape

You don’t have to pick the perfect tracking level before the agent starts.

Begin with a session plan. During inspection, the agent may discover that the “small fix” requires a migration, depends on another repository, or exposes a separate bug. If the work changes shape. Promote it.

Agents are very good at expanding scope. They inspect one path, notice three adjacent problems, and offer to fix everything while the files are open. Sometimes that’s useful…

Your Backlog Is an Agent Prompt

Humans are pretty good at looking at an old issue and thinking, “yeah, we don’t care about that anymore.”

Agents are more literal. If the tracker says the issue is open and ready, the agent has a strong reason to treat it as authorized work. A stale backlog can send a perfectly capable agent down an obsolete implementation plan just as it easily as it can with a valid one.

No issue hygiene needs to be a part of your process. An open issue tells the agent this work is still wanted, this description is still accurate, these constraints still apply, and finishing it would improve the project.

If any of that is false, the issue isn’t harmless clutter. It’s a bad prompt waiting to be executed.

Use the Smallest State That Survives Long Enough

After six months with git-native issue tracking, my workflow has gotten a lot more varied.

I use a session plan when the current agent only needs help organizing the work in front of it. I use an issue tracker when the project needs to remember something after that agent is gone. For local projects i’m very rarely reaching for Beads. For team work it’s always GitHub or GitLab.

Too little tracking and the project forgets real commitments. Too much and it accumulates stale instructions, duplicate tasks, and chores whose only purpose is maintaining the tracker.

Start small. Let the agent make a checklist. Promote the work when it makes sense. Close it when the feature is satisfied. Delete old tasks like you are pulling weeds to make space for the flowers to bloom.

Your agent needs a task manager. It does not need a permanent record of every box it checked along the way.

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].