When there are several sessions, the bottleneck becomes not the machine but the human. Every agent sooner or later runs into a decision it is not entitled to make itself, and calls you: to confirm an action, to resolve an ambiguity, to accept a finished result. If it calls for any reason at all, your attention spills onto noise, and a real blocker drowns among trifles that could well have waited.
The naive move is to turn notifications on for absolutely everything and react as they arrive, in order of arrival, like incoming mail. It seems this guarantees you miss nothing. In fact you lose exactly the important: an urgent approval comes mixed with "the agent called one more tool", the eye gets used to the stream and stops telling things apart, and the critical event is in no way distinguished against the routine.
It breaks on the nature of attention: it does not scale like a processor and does not divide without loss. The devin.agentNotifications setting sends a single native OS notification when a session finishes or waits for your answer - and this is one mechanism at once for Cascade, Devin Local and ACP. Its point is to pull you on a change of a session's state, not on each of its internal steps. Turn notifications into a stream per tool call, and the mechanism devalues itself, and you switch it off entirely - along with the useful signals.
Hence the first rule: notifications are for blockers and completions, not for the course of the work. Let the agent silently do what is allowed to it and call a human only when it truly waits: an approval of a sensitive action, an ambiguous decision, a review-ready result. The Command Center meanwhile shows everything at once - a kanban-style board by status, where you see who is working now, who is blocked and who is ready for review. The course of the work is watched by a glance at this board on your own initiative, not by a stream of alerts yanking you out of another task.
The second rule is about the order of answering, when several sessions wait at once. Answering in order of arrival is wrong here; sessions are sorted by type and risk. First security and approval - what blocks further work and is at the same time sensitive. Then ambiguous decisions where your choice specifically is needed, not the agent's guess. Then review-ready, which can be calmly checked. And at the very end - informational, which it is enough to merely note. Such a queue puts first not the earliest in time but the most expensive if it goes wrong.
Separately - about the temptation to confirm identical things on autopilot. Two sessions ask to allow the same-looking command, and the hand reaches to press "yes" a second time already without looking, on the inertia of the first. But their CWD and scope may differ: the same command by text in a different working directory or with a different file scope is effectively a different action with different consequences. Identical text does not mean an identical result, and each confirmation is worth reading as a separate one, however many similar ones came before it.
The cost of a bad queue is measured not in lost seconds but in lost switches. Every jump between sessions costs context: you recall anew what task this is, what step it is at and what is allowed in it at all. So it is reasonable to optimize agents not only by their execution time but by the number of human switches they demand. A good queue groups checks by repository and type of risk, so that neighboring decisions rest on the same context and do not force you to retune every time.
All this discipline is justified precisely when there is more than one session. On a single task a plain glance at the window is enough, and there is no point building a queue. But once there are three or four, the difference between "reacting to every call" and "working the queue by risk" is the difference between managed work and being yanked around, which by the end of the day exhausts more than the work itself.
You should check the attention you have set up by a few concrete signs. Do notifications arrive only on blockers and completions rather than on every tool call. Are the waiting sessions grouped by type of risk rather than piled into one feed by time. Do you read CWD and scope before every repeated confirmation. Do you count the number of switches, not only the minutes spent. If the Command Center board clearly shows who waits and why, while notifications stay silent on routine - the queue is set up right.
The typical failures are predictable and recognizable. "I missed something important" - notifications were noisy about everything, and one real blocker drowned among a dozen informational ones. "I confirmed the wrong thing" - pressed "yes" on inertia, while the second session's CWD was quite different. "I am tired of switching" - jumped across sessions in order of arrival, loading someone else's context anew each time. The sign is the same: attention was managed as if it were infinite. Recognize it as the narrowest resource and spend it strictly by risk, and multi-agent work stops being exhausting while staying fast.