44 Appointed Agents, One Attention Budget: Three Lines on the Charter

Jakob Nielsen published a taxonomy this morning that I've needed a name for since April. Three interaction styles for AI, sorted by the user's verb: ask, assign, appoint. Turn-taking AI, task agents, always-on agents.

He says, in so many words, that nobody knows how people use the third kind. I have one data set, and it says the appointment is where the design work is.

The short version

Jakob Nielsen's piece "3 AI Interaction Styles: Turn-Taking, Task Agents, Always-On" argues that always-on agents change the design problem because initiative flips: the agent decides when to act and when to interrupt, the interruption budget belongs to the user, and every appointed agent draws on the same account. He also says nobody has measured how people use these agents. I appointed 39 of them by April and audited the fleet: 13 of 39 fired between 7 and 9 a.m. without anyone planning it, and 13 of 39 were orphans that nothing outside the fleet ever read. The fleet is 44 today and 15 still name a 7, 8, or 9 a.m. time. So the rewrite for "appoint an agent" is three lines on the charter before the appointment is made: a slot, a budget line, and a reader's name. Blank reader, no appointment.

What Nielsen sorted out

The piece is long and worth the time. The parts that matter here are short.

The three styles coexist. Nielsen rejects "generations" because generations replace each other and these don't. A standing goal spawns tasks, every task contains turns, and users climb up and down the ladder all day. Alice asks which competitors changed prices, assigns a full report, appoints a watcher for changes above 5%, and when the first alert arrives she's back on the first rung asking questions about it.

The dividing line for the third rung isn't "runs in the background," since a two-day research task does that too. It's who starts each unit of work, and what counts as done. On rung three it's no longer you, and a role runs until dismissed.

Then five ways the user experience changes. Two of them are the subject of this post.

First, on initiative. "The interruption budget belongs to the user, and all that user's agents draw on the same account. Each of 10 agents can send a reasonable number of questions, and together they turn Alice's workday into an approval queue. Every agent sees its own assignment; only Alice experiences the combined burden."

Second, on silence. Always-on agents have no request and no endpoint, so "silence becomes ambiguous: is everything fine, or did the agent die on Tuesday?" And later, the sentence I'd put on the wall of any team building these: "A quiet agent may be doing excellent work or missing everything. Its own reports can't tell you which."

He closes the evidence section plainly. Few studies exist, the best one had four participants who were all authors of the paper, and "how do people use Always-on Agents? Nobody knows." His guess is that most use of rung-three products is still rung-two behavior, one-off tasks sent to something that happens to stay on.

I can't speak for most people. I can speak for one fleet that is rung three by construction.

The fleet I appointed

Every agent in my fleet is appointed, in Nielsen's sense. Each has a stage in the PM operating model, a schedule, and a standing job. None of them waits for a question.

In April I audited them and wrote it up in 39 PM AI Agents Deployed: What Stuck, What Died, and Why. Two findings from that post are Nielsen's two problems with numbers attached.

Thirteen of 39 agents fired between 7 and 9 a.m. local time. A third of the fleet in one window. Nobody designed it. Every agent I built with some version of "tell me the most important thing in X from yesterday" drifted to the hour a PM wants the answer, because that's the hour the answer is useful. Each decision was right on its own. The result was thirteen briefs arriving together, which is the approval queue Nielsen describes, built by a person who thought he was designing each agent carefully.

Thirteen of 39 were orphans. Zero references from anything outside the fleet: no page, no ritual, no other agent consumed their output. Some were new. Several had run for over a month, reliably, producing clean output that nothing read. In that post I called it the cleanest "we built it but it didn't stick" signal I have.

The fleet today is 44 agents with a stage and a schedule. I counted the schedules again this morning: 15 of the 44 name a 7, 8, or 9 a.m. time. Six months later, the slot still chooses itself.

Nielsen says each agent sees only its own assignment and only the person sees the combined burden. I'd go one step further. The person doesn't see it either, until they count. I was the person, and I found the thirteen in an audit, not in my mornings.

The check that isn't the log

The orphan count is also an answer to Nielsen's harder question, the one about what a quiet agent is doing.

He writes that a log answers "what did you do?" and stays mute on "what did you miss?", and that detecting omissions requires an independent check of what the agent should have noticed. A second AI can help, he says, but only if it examines the underlying evidence rather than the first agent's activity log.

My check was cruder than that and it worked. I didn't read the agents' reports to find out which ones were alive. I counted, for each agent, how many things outside the fleet referenced it. Pages, prototype demos, handbook chapters, other agents. The three agents with three or more references were the ones the broader system had decided were load-bearing. The thirteen with zero had been voted off by silence.

That's the shape of the independent check: it looks at the consumer, not the producer. An agent's own heartbeat says it ran. Only something downstream can say it mattered.

The same post found that the single biggest predictor of agent survival was a named human owner, someone who notices within hours when it breaks. Which is why, if I had to pick one of Nielsen's five changes as the one to design first, it would be the reader.

The rewrite: three lines on the appointment

Nielsen's seven guidelines are good and the fifth is the one I'd sharpen. "Budget the user's total attention. Coordinate escalations across agents and measure the net attention saved." He's describing a system-level fix, a shared queue that ranks requests by consequence and deadline.

I'd move it earlier, to the moment of appointment, because the queue gets designed after the thirteen are already in it.

"Appoint an agent" becomes: the appointment carries three lines before it's made.

1. A slot. The time it may speak, chosen against the other agents' slots rather than in isolation. If your fleet has a morning window, the new agent either earns a place in the one consolidated brief or takes a different hour. My April post called the fix a meta-agent that consolidates the morning briefs into one read; I'd now say the charter has to carry the slot before that meta-agent exists, or the thirteen reassemble.
2. A budget line. How many escalations a week it may spend from the shared account. Nielsen notes that an agent can raise its precision just by saying less, so this isn't a precision target. It's a share of a fixed budget, and the budget is the person's, not the agent's.
3. A reader's name. The person who opens the output. Not the owner who fixes it when it breaks, though that's the same person more often than not. The one who reads. If that line is blank at appointment, the agent is an orphan on day one, and I have thirteen examples of what that looks like a month later.

Three lines. The first two are Nielsen's budget made per-agent. The third is the one I'd add, because the orphan count said that the thing missing from my charters wasn't a limit. It was a person.

Where this sits

The design handbook has a chapter on the user's side of this. Latency Is Interface argues that open-ended agent work needs legibility instead of a loading state, because the person can't tell a system that's working from one that's stuck from one that finished and failed to say so. An appointed agent is that problem with no request to anchor it, which is Nielsen's "no response time, no percent-done."

The Stop Rule is the same discipline for a single loop: attempts, spend, and the name it escalates to, written before the loop runs. This post is the fleet version. The stop rule bounds one agent's run. The slot, the budget line, and the reader bound what a fleet of them does to one person's week.

And it belongs to the Enterprise AI Agents argument that agent count is a vanity metric and what matters is how many agents still do production work after ninety days. Thirteen of mine were running at ninety days. Thirteen were also unread. Those are different numbers, and the second one is the one I'd report.

This week: for every appointed agent you have, write down the hour it speaks and the name of the person who reads it. Sort by hour. If more than three land in the same window, that's your queue, and it was never designed. If any reader line is blank, that's your first retirement.

Related answer: What should an always-on AI agent's charter include?

Sources: Jakob Nielsen, "3 AI Interaction Styles: Turn-Taking, Task Agents, Always-On," UX Tigers, October 14, 2026, read in full; the studies he cites are mentioned only as he reports them. 39 PM AI Agents Deployed: What Stuck, What Died, and Why, falkster.com, April 27, 2026, for the April counts. The count of 44 agents and of 15 with a 7, 8, or 9 a.m. time is from the fleet's own schedule fields on October 14, 2026.