01As requests pile up, the work of ordering them falls on the person
In September 2026, the operator's requests to AI were multiplying within a single week: drafting articles automatically, rebuilding a video, finding mismatches between the Japanese and English pages, and starting a long series. In that month alone, the record shows 17 requests tagged as a "work reservation".
Queuing requests was the subject of the first episode in this series. Once the queue grows, a new problem appears. Who decides which request comes first, and by what rule?
On 12 September, the operator handed this problem to the AI. The request was to sort the growing list at regular points, turn task management and the setting of priorities into a system, and make the working environment remember it.
The rule that came out of that exchange is short. There is one ledger for requests. There is one scoring formula for order. And there is one foreground task, the single piece of work the AI is actively doing. This episode looks at why limiting each to one is what makes it safe to hand the ordering over.
02Handing priorities to AI means the person sets the method once
"Let the AI set priorities" can sound like letting it work in whatever order it likes. The operator asked for the opposite.
What was handed over was the job of producing the order. The method for producing it was decided by the person and written down as a rule. Each time a request arrives, the AI applies that rule and returns an order.
This split has a clear benefit. The person no longer has to ask "is this one urgent?" for every request. The only question left is whether the method itself is right. Fix the method, and the order of every later request changes in the same way.
If you skip the method and only say "keep things organised", the AI works out an order from the current conversation each time. If its method differs between yesterday and today, you will not see it.
03With two methods, the same request moves up and down from day to day
The reason for limiting the ledger, the formula and the foreground to one each is the same in all three cases. With two, the result depends on which one was used, and afterwards no one can tell which one that was.
| Aspect | Two or more | Exactly one |
|---|---|---|
| Ledger | Requests scatter across chats, notes and files, and some end up on none of them | A request not on the ledger was, by definition, never made |
| Scoring formula | The same request rises or falls depending on which method was applied | The same inputs give the same score, so the order can be explained |
| Foreground | Partial results of two tasks mix, and neither finishes | Tasks finish one at a time, and the next is chosen afresh at each finish |
| What the person checks | The whole conversation | One ledger and one line of formula |
The last row matters most to the person using the AI. When an order looks wrong, there is one place to look. The scores on the ledger show why things came out in that order.
04Four parts close the rule: ledger, formula, foreground and sorting points
Here are the terms the rule uses.
Ledger
One list, one row per request: content, the condition for calling it done, deadline, status and score.
Scoring formula
The same formula is applied to every request, and requests are sorted by score.
Foreground
The work the AI is doing in the conversation now. Everything else waits on the ledger.
Sorting points
Fixed moments: when a task finishes, when a request arrives, when a conversation starts.
The fourth part corresponds to "at regular points" in the operator's request. It does not have to be a clock interval. It means that scores are always redone at moments agreed in advance.
It also helps to say what the rule does not decide. Whether to accept a request, whether to delete one, and whether to start work that cannot be undone are not settled by the formula. The person settles those. The formula only orders the requests that have been accepted.
On the same day, the operator asked for a series that would take three months. The AI put it on the ledger as a long-term item, and the sorting procedure gained a line: pause it while urgent requests are waiting, and resume when there is spare time. Long requests and short ones sat on the same ledger under the same method.
05In material review, the same rule can order the materials waiting for review
In promotional material review at a pharmaceutical company, requests arrive at once from teams for several products. A piece for a congress, a replacement after a label revision, an urgent item from sales. Which one is reviewed first often depends on who pushes hardest.
Pharmaceutical quality work already has this idea. ICH Q9(R1) describes risk ranking and filtering, a tool that breaks a risk question into factors and combines them into a single relative score used to rank diverse risks. The same guideline warns that poorly designed scoring scales let subjectivity into the decision.
If you manage review requests with AI, the ledger can hold each material's planned release date, the number of times it has been sent back, and whether it contains a new indication or safety statement. The formula can be one line, for example: the fewer days until release, the higher the score, with extra points for safety content. The AI sorts incoming requests with this formula, and reviewers work in that order.
The person still owns changes to the order. When a reviewer swaps two items, the reason goes on the ledger. If the same reason keeps appearing, it is a factor the formula is missing. In this way the method improves through its own record.
Check your company's rules on what information may go to an AI before you build the ledger. The order can be set from title, deadline and status alone, without the text of the material.
06Each AI conversation starts without memory, so the rule has to be written and read
The method has to be written down because of the way the AI works. Anthropic's documentation for Claude Code says that each session begins with a fresh context. What carries over between sessions is instructions written in files such as CLAUDE.md, which are loaded at the start of every session.
Without a written rule, the AI orders requests from the conversation in front of it. The request that arrived last has the advantage. Older requests drift out of the conversation and lose any chance of being scored.
The same documentation says loaded instructions are treated as context, not enforced configuration, and that specific, concise instructions are followed more consistently. A rule as short as "one ledger, one formula, one foreground" benefits from that.
Research on people supports the limit on the foreground. In experiments by Rubinstein and colleagues in 2001, switching between two tasks cost time at every switch, and the cost grew as the rules of the tasks became more complex.
In November 2025, Anthropic published an account of running long tasks with AI agents. A single file held the list of features to build, and the agent worked on only one feature at a time. At the start of each session it read the progress notes and the list, then picked the highest-priority feature not yet done. That is the same structure as the ledger, the formula and the foreground.
07From tomorrow: settle the three "ones" and write them into the file the AI reads every time
There are five steps.
- Choose one ledger. A spreadsheet or a document will do. Use five columns: content, the condition for done, deadline, status and score. Have the AI move requests made in conversation onto it as well.
- Write the formula in one line. Keep it to three factors, for example closeness of the deadline, size of the impact, and whether someone is waiting. State the scoring in words, and have the AI record the reason for each score on the ledger.
- Keep one task in the foreground. When a new request arrives mid-task, the AI only adds it to the ledger and scores it, then carries on with the current work.
- Fix the sorting points. Have the AI rescore and return the order when a task finishes, when a conversation starts, and when a new request arrives.
- Put the rule where the AI reads it every time. In Claude Code that is CLAUDE.md. In other tools, use the field for instructions loaded at the start of each conversation.
After a week, reread the rows where a person changed the order. If the same reason appears twice, add it to the formula. When the formula changes, note the date and the reason at the top of the ledger.
- Handing priorities to AI means the person sets the method once and the AI produces the order. Accepting, deleting and irreversible work stay with the person.
- With one ledger, one formula and one foreground task, requests are not lost, order does not wobble, work does not mix, and one ledger explains the order.
- Each AI conversation starts without memory. Keep the rule short, put it where it is loaded every time, and improve the formula from the reasons people give for overriding it.
When requests multiply, what the person should give up is not judgement but the repeated sorting. Write the method as one rule, and the AI keeps producing the order the same way, while the person only checks that the method is right. The next episode looks at how a request that takes three months fits on this ledger.
- Anthropic. How Claude remembers your project. Claude Code Docs. https://code.claude.com/docs/en/memory
- Anthropic. Effective harnesses for long-running agents. Anthropic Engineering, 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
- ICH. Quality Risk Management Q9(R1). ICH Harmonised Guideline, 2023. https://database.ich.org/sites/default/files/ICH_Q9%28R1%29_Guideline_Step4_2025_0115.pdf
- Rubinstein, J. S., Meyer, D. E., Evans, J. E. Executive control of cognitive processes in task switching. Journal of Experimental Psychology: Human Perception and Performance, 27(4), 763-797, 2001. https://doi.org/10.1037/0096-1523.27.4.763