Our AI Created 1,042 Tasks in Four Months

Between June 4 and September 30, our company brain created 1,042 tasks in our project tracker. It read our email and meeting transcripts at the end of each day, pulled out every action item, and filed each one as its own task. Most of those tasks were noise, and the fix that finally worked was taking the job of counting away from the model entirely.

What the day-end run does

My co-founder and I each run a command at the end of the day (we call it day-end). It reads the day’s meetings and email threads, figures out who owes what to whom, updates project docs, syncs contacts, and drafts tasks. A gate shows us the drafts before anything gets written, and we approve, edit or drop them.

Over 39 runs in those four months it processed 460 meetings and 1,420 email threads, surfaced 626 threads where someone was waiting on a reply, made 303 doc edits, and created 1,042 tasks. Only 40 drafts in that whole stretch were merged into a task that already existed.

On paper those numbers look great. A tool that finds a thousand things to do sounds like a tool that’s paying attention.

Why 1,042 was the problem

A meeting with a client produces a dozen action items. “Send the updated deck.” “Confirm the call time.” “Ask about the staging credentials.” “Follow up on the invoice question.” The model was correct that each of these was something someone said they’d do. It was wrong that each one deserved its own row in a task database.

The worst single run created 76 tasks. Several others landed in the 40s and 50s. At that rate nobody reads the list, and a list nobody reads is worse than no list, because it still feels like the work is tracked.

We found out how bad it was in early September during a cleanup of the tracker. One person had 243 active tasks assigned to them. 182 of those still carried the “AI Generated” tag, meaning nobody had touched them since the brain created them. When we ran a fresh batch of day-end drafts against that backlog, 7 out of 19 were duplicates of something already sitting there.

That cleanup produced one of the more useful lines in our learnings file: review AI-generated tasks within about two days of creation or they go stale and start duplicating. The two days came from a habit the team had already picked up on its own, noticed live during the cleanup. The 7-of-19 duplicate rate is what made us write it down.

Fix one: tell the model to bundle

The obvious fix was instructions. On September 28 we rewrote the task-sizing rules in the day-end guide. The new rule said to bundle same-owner, same-project steps into one outcome-level task with a checklist of steps, and only split at hard seams: a different project, a different owner, work that’s genuinely blocked, or something bigger than a day.

The model read it. The model agreed with it. If you asked it to explain the rule back, it explained it perfectly.

The very next run covered a three-day window and produced 42 raw drafts. After the bundling step, it still proposed 24 new tasks.

I’ve seen this pattern enough now that I don’t find it surprising anymore. A rule like “group these by owner and project” sounds like judgment, but it’s mostly arithmetic. You have a list, you have two keys, you group. Language models are good at the judgment part (is this a real commitment, who owns it, what’s a good title) and unreliable at the arithmetic part, especially when the grouping has to hold across 40 items extracted by different subagents reading different sources. Each extraction looked reasonable in isolation. The bundling had to happen across all of them, and prose instructions don’t enforce anything across a list.

Fix two: take the grouping out of the model’s hands

Two days later my co-founder made it a ruling, and it went into our decisions log as D-2026-041: day-end creates at most one new task per owner per project per run, plus one daily catch-all per owner for the small stuff.

Then we wrote a script to enforce it. rollup_drafts.py takes the raw drafts and does the grouping deterministically. No model calls. The logic is boring on purpose:

• Group drafts by owner plus project (the project ID if there is one, else the project name, else the client firm).
• The group’s due date is the earliest due date among its items. Its priority is the highest.
• Each original draft becomes a step in a checklist on the task page.
• Split only when the owner differs, the project differs, or a single item is itself a multi-day deliverable.
• Anything low-value (personal, networking, “waiting on them”, low priority, or no project and no client) goes into one task per owner titled something like “Gabe: misc follow-ups 10/02”.

The model still does the parts it’s good at. It extracts the action items, decides who owns them, and after the script groups everything, it writes a real title and summary for each rolled-up task. The script decides how many tasks exist. The model decides what they say.

That run’s gate, re-bundled under the new rule before anything was applied, ended with 13 tasks created and 8 merged into existing ones. Down from 24 proposed under the prose rule. More importantly, each of those 13 maps to a piece of work someone would actually sit down and do.

The script is 442 lines. The tests for it are 431 lines. That ratio felt right for something that would otherwise silently decide how my week looks.

The details that mattered

A few smaller decisions made the rollup trustworthy.

Existing tasks are never absorbed automatically. The rollup only merges drafts from the same run with each other. If a draft looks like a step of a task that’s already open (“send the deck” when “finalize and send the Q4 deck” exists), the deduper flags it and the gate defaults to merging it as a note, but a human still sees that call. Silently folding new work into old tasks is how things disappear.

Steps became real checklist items. The first version put steps in the task’s Notes field, which our tracker truncates at 2,000 characters. Long checklists were getting cut off mid-item. Now each step is written as a to-do block in the page body.

The catch-all has a date in the title. One “misc follow-ups” task per owner per day means yesterday’s catch-all is visibly yesterday’s. If it’s still open three days later, that tells you something.

What I’d tell anyone building this

Task counts are a vanity metric for AI systems. “Created 1,042 tasks” reads like output. What you want to know is how many got done, how many were duplicates, and how many were still untouched a week later. We didn’t track any of that until the cleanup forced us to look.

When a rule is really a counting rule, put it in code. Prose instructions work well for judgment calls, and they decay into suggestions when the rule needs to hold across a whole list. The prose rule lasted two days, and the 42-drafts run was the evidence that settled it.

The tracker is also shared between two founders, which added its own flavor of duplicate. I wrote about that separately in Two Founders, One Brain, and the Duplicate Problem. And if you want the bigger picture of what this system does all day, start with the pillar post.

If you want a brain like this for your team, with the noisy parts already fixed, I build them in 14 days.