Task Management Is a Knowledge Problem

There is a task in your to-do app right now that you don't understand anymore.

Maybe it says "follow up with Marcus about pricing." Maybe it says "look into Supabase." Maybe it's just "call dentist" and you don't know which dentist — you switched last year and can't remember if this is about the old one or the new one. You can't do it because you don't have what you need to do it. The task exists. The context doesn't.

This isn't a motivation problem or a prioritization problem. It's a knowledge problem. And to-do apps are built as if it isn't.

The atomic unit is wrong

A task in almost every to-do app is a string. Maybe with a due date attached. Maybe with a label. But fundamentally: text. Write the action. Check the box.

David Allen's Getting Things Done, published in 2001 and still quietly running half the productivity advice on the internet, treats tasks as "next actions." The idea is that any commitment needs to be broken down into its next physical action. "Finalize the proposal" becomes "email Erin the draft." Concrete. Actionable. Done.

The GTD insight was real. Vague intentions are not tasks. But the system still treats the task as the atom. The context lives nowhere. It lives in your head, which is fine until you come back to the task three days later and find a string of text that makes no sense without the meeting that spawned it.

What actually makes a task completable

The tasks I can do immediately share a common property: I know why they exist. Not just what to do. Why this action, at this moment, connected to what.

"Email Erin the draft" is opaque. The version I can act on says: email Erin the draft, because this is about the Riverstone renewal, she needs it before Thursday's call, and the relevant notes are in last week's meeting doc. I have orientation. I know what success looks like.

That second version isn't really a to-do item. It's a node in a knowledge graph. It's attached to a project, a person, a timeline, and a document. That structure already exists somewhere. The problem is that it lives in your notes app, your email, your calendar, and your memory, and the to-do app has no access to any of it — because to-do apps were designed to be separate from all of that.

That separation is a historical accident. Not a philosophical choice.

What integration actually means

The obvious response is: just use Notion, just link your tasks to your docs. But linking is not the same as integrating.

Notion lets you put a task next to a document. But the task is still a flat item in a database. The links are manual and fragile. The structure is cosmetic. It doesn't know about the decision that caused this task, or the person it's addressed to, or how it relates to the other tasks in the project. You've added a hyperlink, not a relationship.

What would genuine integration look like? A task that is a first-class entity in your knowledge base, with a person attached as a typed relationship, a project as a parent, and a created-date that tells you when you were thinking about this and in what context. When you open the task, you see the note from the meeting where it came up. When you look at the person, you see all open tasks associated with them. When you close the project, the tasks close with it.

Not complicated to imagine. Genuinely hard to build, because it requires tasks and knowledge to share a data model rather than being stitched together through integrations after the fact.

The AI angle

This matters more now because AI tools are starting to create tasks on your behalf. An AI that reads your meeting notes, identifies follow-ups, and adds them to a list is useful in theory. But if those tasks land in a separate app with no connection to the source material, you get more orphaned strings in a queue. You've automated the problem, not the solution.

An AI that creates a task and attaches it to the person it's about, the project it belongs to, and the document it came from is doing something categorically different. It's writing structured knowledge. It's making the task something you can act on without reconstruction.

The distinction is whether your task system is a queue or a graph. Queues are fast and dumb. Graphs take longer to build and stay useful. Most to-do apps are queues dressed up with labels and due dates.

Pick five tasks from your to-do app at random. For each one: do you know why you added it? Do you know enough to do it right now, or do you need to go find context first?

If the answer is usually "go find context," your task system is costing you the time it was supposed to save. The fix isn't a better to-do app. It's a knowledge base that treats tasks as what they actually are: not action items floating in space, but the crystallized output of decisions that were made somewhere, in a context you should be able to get back to.

---

Asgeir Albretsen is the founder of Harbor.