Hey,

Last week I wrote about the shift from building to coordinating, and I mentioned the one rule that holds my whole setup together, which is that an agent has to claim a task in the log before it starts working on it, the same way you would write your name on the whiteboard next to a job so nobody else picks it up, and a few of you asked what that actually looks like in practice, so today we are going to build the entire thing, the task log itself, the scheduled agent that reads it, the claim step, and the review handoff at the end, with enough detail that you could set this up yourself this weekend.

TL;dr: keep every task as a row in one shared log with a status column, have each scheduled agent check the log for unclaimed work when it wakes up, claim the task by writing its name and a timestamp into the row before doing anything else, run the task, then flip the status to for review and send you a short summary of what was done and what needs your decision.

Setting up your task log

The task log is just a table, and I keep mine in a Google Sheet because it is easy to read at a glance and every agent I run can read and write to it, though a database table works just as well if you are comfortable with that, and the point is that every piece of work your agents might do lives here as one row per task, with these columns:

• task_id: a short unique id, like fx-042, so you and the agents can refer to the exact task without ambiguity.
• title: one line describing the task, written the way you would say it out loud.
• status: one of four values, and only these four: todo, in_progress, for_review, done.
• claimed_by: the name of the agent or person working on it, empty until someone claims it.
• claimed_at: the timestamp of the claim, which is your safety net if an agent dies halfway through.
• brief: the actual instructions, what done looks like, and where to put the result.
• result: what the agent produced, filled in when the work finishes.
• review_notes: your notes back to the agent after review, or the agent's notes to you.

Breaking this down, because every column earns its place. The four statuses are doing most of the work, since todo means nobody has touched it, in_progress means someone has claimed it and owns it, for_review means the work is done and waiting on a human, and done means reviewed and closed, and keeping for_review separate from done is what guarantees that nothing ships without a human looking at it. The claimed_by and claimed_at columns together are the claiming rule made concrete, since a row with a name and a timestamp in it is visibly owned, and a row without them is visibly free. And the brief column deserves more care than all the rest put together, because an agent is only as good as its instructions, so write the brief like you are handing the task to a capable colleague who has never seen it before, with the inputs, the expected output, and where the output should go.

The scheduled agent's loop

Every scheduled agent I run follows the same five steps, in this order, and the order is the whole point, because each step only makes sense once the one before it is done:

1. Check the log. When the agent wakes up on its schedule, the first thing it does is read the task log and filter to rows where status is todo, and if there is nothing with that status, it goes back to sleep and does nothing, which is the correct behavior, because an agent with nothing to do should do nothing.
2. Claim the task. It picks the top todo row and immediately writes its own name into claimed_by, the current timestamp into claimed_at, and flips status to in_progress, and this write happens before any other work, because the claim is what stops a second agent from picking up the same row five minutes later.
3. Run it. It reads the brief column and does the work, writing files or updating sheets or whatever the task calls for, and as it works it can add progress notes to the result column, though the status stays in_progress until the work is actually finished.
4. Send it for review. When the work is done, it flips status to for_review and writes a short summary into the result column covering what was done, where the output lives, and anything that needs a human decision.
5. Notify you. The agent sends you that summary, which in my setup is a message with the task title, what changed, and the specific question I need to answer, because a review request without a clear question attached is how tasks stall in for_review for a week.

Why the claim has to come first

This is the step people skip, and it is the step that matters most, because without it you get the exact failure I wrote about last week, which is two agents doing the same task at the same time with one of them overwriting the other's work, and the claim prevents it the same way the whiteboard prevents it in an office, since the first agent to write its name on the row owns the row.

A few details that make the claim actually work instead of just looking like it works. First, the claim is a single write that happens immediately after the read, with no work in between, because any gap between reading the log and claiming the row is a window where a second agent can read the same todo row. Second, the claimed_at timestamp is your safety net, because agents do die halfway through tasks, and when that happens the row sits in in_progress forever unless something can spot it, so my rule is that any claim older than a few hours with no progress gets released back to todo, and the next agent that wakes up can pick it up and try again. Third, keep the agent names distinct and human readable, like saturday-deals-agent instead of agent-1, because when something goes wrong late at night you want to know which one did it.

What "send it for review" actually contains

The review handoff is not just the word done, it is a short report, and I ask my agents to always include the same four things, because a consistent format means I can review five of these in as many minutes. What was done, in one or two sentences. Where the output lives, with a link or a file path. What changed versus the last run, if it is a recurring task. And the decision I need to make, stated as a plain question, because "review please" with no question attached is how tasks stall.

When I have reviewed it, I write my notes into review_notes and flip the status myself, either to done if it is good, or back to todo with notes on what to fix, and the agent picks it up on its next scheduled run, which closes the loop without any back and forth in chat.

What if two agents check the log at the same time?

This is the question I get most often, and the honest answer is that the claim write is the lock, so the first agent to write its name into claimed_by owns the task and the second one sees in_progress when it reads the row and moves on to the next todo, and in practice my agents run on staggered schedules so true collisions are rare, but the mechanism handles them anyway, which is the point of having the mechanism instead of just hoping.

Next week we will look at the other half of this system, which is what actually goes into the brief column, because the task log handles the coordination and the brief handles the quality, and a good brief is what lets an agent do useful work without supervision.

TL;dr: one shared task log with a status column, agents check it on schedule, claim before working, and hand back a structured review note, and the whole system takes maybe thirty minutes to set up in a spreadsheet and protects you from the most expensive failure in agent workflows, which is two agents confidently doing the same job.

More to come, I am writing regularly again.

- Francois

P.S. If you already run any kind of scheduled agent, what does your version of the task log look like, or do you just let them run and hope? Hit reply, since I read every response, and the best answers will shape the follow-up post.