My Google Tasks lists used to have a polite but important lie built into them.

They mixed things I needed to do with work my AI assistant, Closp, could do. A reminder to make a phone call sat beside a research job Closp was perfectly capable of completing. Both appeared in the same list, in the same form, as if both were waiting for me.

That is not a shared system. It is an AI quietly adding its own homework to the human’s pile.

The recent fix was small enough to fit in a task title: every active task now says who owns the outcome. That one change turned Today, This Week, and Later from my personal backlog into a shared operating queue.

Time and ownership are different questions

The existing lists already answered when:

  • Today
  • This Week
  • Later

They did not answer who. I did not want a second app or a parallel “AI tasks” list, because then planning the week would require reconciling two systems. Instead, we added ownership as a second dimension inside Google Tasks.

Every active task carries one of three title prefixes:

[Timur] Renew a document
[Closp] Draft the September update
[Joint] Review the household budget

The same owner is repeated in the first line of the notes:

Owner: Closp

That duplication is deliberate. The prefix makes ownership visible in the normal Google Tasks interface. The notes line gives scripts a stable field to validate instead of hoping that a title was typed consistently.

Google Tasks does not provide a writable assignee field for an ordinary personal list. This is not elegant database design. It is, however, a useful schema that works in the interface I already use.

“Joint” needs a baton

The dangerous category is [Joint]. Without more information, it can mean “everyone is responsible”, which usually means nobody is.

Every joint task therefore adds a second notes line:

Owner: Joint
Next actor: Closp

The next actor is the current baton, not another owner. Closp might research three options, then pass the task to me for a decision. Once I decide, the baton can return to Closp for implementation.

This also makes [Joint] relatively rare. If Closp can take a piece of work all the way to a verified result, it is a Closp task. If only I can make the call, attend the appointment, authenticate, approve, buy, or send the message, it is mine. Shared ownership is reserved for outcomes that genuinely alternate between us.

The daily plan now has two lanes

Ownership matters only if the planning routines respect it.

My daily and weekly reviews used to treat the whole board as one human workload. Now they plan two lanes:

  • my lane is constrained by attention and the number of realistic commitments;
  • Closp’s lane is constrained by dependencies, access, risk, and execution capacity.

A Closp task no longer consumes one of my focus slots. It should be advanced autonomously, completed to its acceptance gate, or left with a concrete blocker and next step. It must not reappear as a vague suggestion that I “look into” the work assigned to the assistant.

Joint tasks appear in the lane named by their baton. When the baton changes, the task is updated rather than copied. Cross-list moves preserve the owner, baton, due date, notes, and task meaning.

This sounds like project-management hygiene because it is. Giving an assistant tools does not remove the need to define responsibility; it makes that definition more important.

Migrating the live board without losing it

There were 24 active tasks across the three lists when we introduced the scheme. A guarded migration classified them as:

  • 9 owned by me;
  • 8 owned by Closp;
  • 7 joint tasks with an explicit next actor.

The migration preserved every task ID, list, status, due date, parent link, position, and original notes body. It then read all 24 tasks back from the API and ran a whole-board audit.

The result was zero missing or conflicting ownership markers and zero duplicates after comparing titles without their new prefixes. The helper and its integrations also passed the full 116-test workspace suite.

Those numbers matter because a command returning success is not proof that a task board survived a bulk edit. The observable result is the board that exists afterwards.

There is one more honest distinction: the configuration is verified, but the behavioural rollout is not complete until a scheduled planning ritual uses the new lanes correctly. That first real cycle must advance a Closp-owned task, keep it out of my focus limit, preserve the metadata through any move, and deliver one normal review. A neat migration is not yet proof of a useful habit.

Ownership is not permission

Calling something a Closp task does not grant new authority. The assistant still cannot silently publish a post, send an email, make a purchase, delete data, or take another consequential action merely because its name is on the task.

Ownership answers who is responsible for moving the outcome forward. Existing approval and safety rules still answer what actions are allowed.

That separation is useful beyond AI. Teams often confuse assignment with permission, and automation systems often confuse capability with authority. Keeping the two explicit prevents a convenient queue from becoming an accidental escalation mechanism.

The first task to prove the idea

The task that produced this post is itself labelled [Closp].

That means it belongs in the assistant’s queue, not in my weekly list as a writing chore. Its acceptance gate is also concrete: create distinct drafts, keep them unpublished, build the site, commit the files, and push them to GitHub for review.

This is the real improvement. The prefix is only six characters. The change is that my task list can now hold work for both of us without pretending that all of it is mine.

This is part of a short series on recent improvements to my personal AI system. Next: how Quick Notes learned the difference between a thought and a commitment.