AI Agents Creating Too Many Tasks? Treat the Backlog as a Flow

If your AI agents are creating too many tasks, the backlog is not a pile to clear. It is a flow: items arrive every day from several sources, and a person can only close so many. Clearing the pile by hand will lose, because tomorrow’s arrivals refill it. The fix is to measure how many items arrive and leave per day, find which producers send the most, and close those pipes at the source.

We learned this the slow way in September 2026. This post covers what happened, the four changes that held, and a count you can run on your own system this week.

Why does clearing the backlog by hand fail?

Clearing by hand fails when arrivals per day exceed closures per day. A queue grows whenever the arrival rate is higher than the rate at which work leaves, so every item you close is replaced by a new one, and effort spent triaging does not change the trend.

Queueing theory has said this since John Little’s 1961 result, which the Scrum.org Kanban Guide for Scrum Teams (2019 edition) restates in plain terms: for a given throughput, the more items in progress at once, the longer each one takes to finish. Its first recommendation when waits get long is to lower the amount of work in progress, not to push people harder.

Agents change the arithmetic because they are cheap producers. A person files a handful of tasks a day. An agent that notices a problem at 3am can file one per run, and ten agents can do it all week. Microsoft’s 2026 Work Trend Index (published May 2026, 20,000 knowledge workers surveyed across 10 markets) found that people rank quality control of AI output as the top skill they need, at 50%. Review is the scarce resource. Production is not.

What did we see in our own backlog?

In September 2026 we spent three days clearing the decision backlog that agents had built up for the executive. It got worse each day, not better. The number waiting at the end of day three was higher than at the start.

When we stopped clearing and counted, the picture was a flow of roughly the same size every day, from three sources:

• Automatic defaults. A routine that applied a default to an unanswered question also filed a follow-up card about it.
• Review requests for machine-made changes. Our coding agents opened changes, and each green one produced a request for a person to click merge.
• Improvement proposals. A scheduled improvement agent filed suggestions faster than anyone could read them.

Triage throughput could not beat that inflow. So we stopped treating it as a stock and treated it as a pipe system. One part drained the pile into work the agents could pick up themselves. The other part shut the pipes. Merging a change that passed a fixed list of checks no longer needed a person, and the ones that did need a person (anything touching data structures, secrets or build configuration) stayed manual. We covered the check-before-merge idea in Your AI agent says the task is done. How do you know?.

Why were so many cards false alarms?

A month later, in October 2026, we audited the cards themselves and found a second flow problem hiding under the first. The cards were claims, not facts.

One card sat open for weeks about a credential we believed was stale. The note that started it said the credential was “strongly suspected” to be wrong. Every later session repeated it as established fact. Nobody had ever compared the values. The credential was fine.

The audit showed the same pattern across producers:

• No machine-runnable check. The cards agents had filed carried nothing a machine could run to test whether the problem still existed.
• No recheck. Only one producer closed its own cards when the fault recovered.
• Answers not written back. A person answered in a chat session, the answer never reached the card, and the card returned to the pending pile.
• One fault, many cards. Each producer used its own de-duplication key, so one outage produced a card per producer.
• Silent inserts. Tasks written straight into the store notified nobody, so a large share of person tasks over two weeks had no assignment notice at all.

Google’s SRE book makes the principle for paging: every alert should call for a response that a person must make and that the system cannot make itself. A card that cannot be tested, and that nobody was told about, fails that bar.

Which fixes held?

Four changes did most of the work. We shipped them in early October 2026.

Problem	Flow cause	Fix that held
Duplicate cards for one outage	Each producer deduplicated alone	One shared issue key per fault, across producers
Cards that never close	Nothing rechecked them	An hourly sweep runs a named check and closes the card when it passes
Claims repeated as facts	No test at filing	The card carries a check the machine can run, or it is marked a suspicion
Decisions piling on one person	Defaults landed on the executive	Secrets, console work and excluded tasks stay with the owner; the executive sees decisions only

Two details matter more than they look. First, person cards close as “cancelled” by the sweep, never as “done”, so a recovery does not get counted as someone’s work. Second, an answered question completes its card only when the card was written to close on an answer. Otherwise a stray reply can close the wrong thing.

The email flood was the same disease in a smaller body. One sender produced dozens of messages a day: a reminder per open task that duplicated the daily overdue digest, plus copies of other people’s digests. We kept the three messages that needed action and cut the rest. Inbox volume fell from the dozens to a handful a day.

How do you check your own flow this week?

You need one afternoon and a spreadsheet. Pull the last 14 days of tasks that agents created and answer five questions:

1. Arrivals per day, by producer. Which agent or routine files the most?
2. Closures per day, by closer. Are items closed by a person, by the producer, or by nobody?
3. Oldest open item. If the age of the oldest keeps rising, you are on the wrong side of the line.
4. Share with a runnable check. What fraction of open items could a machine retest today?
5. Share with an assignment notice. How many tasks did the assignee actually hear about?

If arrivals beat closures for two weeks, no amount of triage will help. Pick the top producer and apply a cap: it may hold only a set number of open items, and a new one needs an old one closed or a reason. This is the same logic as limiting work in progress on a kanban board. We wrote up the single-store design that makes this count possible in AI Task Management for Teams: One System for People and Agents.

What is still open?

We would rather say so than imply it is finished. The recheck sweep supports only a small set of named checks so far, so cards about anything else still wait for a person. Answered cards in one chat path still need a manual write-back. And the pile is smaller, not gone. As of mid-October 2026 we are measuring whether the inflow stays down for a few weeks, because a fix that holds for two days proves nothing.

Where this fits

Counting arrivals against closures, setting producer caps, and reviewing what your agents filed each week is the standing job of a Fractional AI Officer: $2,900 a month, written reports, no meetings. You own the delivered code, data and documentation.

Our agent fleet proof page shows the fleet this runs on. Each agent there is a tomte, our word for one production agent with one defined job. The rule we apply to every one of them is the one in this post: if it files work for a person, it must say how that work can be tested and when it closes itself.

Start async

Send us the name of the agent or routine that files the most tasks on your team and a rough count from the last two weeks. We reply in writing within one business day with where we would put the first cap. No meetings. Start async.