Когда сессий несколько, узким местом становится не машина, а человек. Каждый агент рано или поздно упирается в решение, которое сам принять не вправе, и зовёт вас: подтвердить действие, снять неоднозначность, принять готовый результат. Если звать он будет по любому поводу, ваше внимание расплещется на шум, и настоящий блокер потонет среди мелочей, которые вполне могли подождать.
Наивный ход - включить уведомления на всё подряд и реагировать по мере поступления, в порядке прихода, как на входящие письма. Кажется, что так гарантированно ничего не пропустишь. На деле так теряешь именно важное: срочное подтверждение приходит вперемешку с "агент вызвал ещё один инструмент", глаз привыкает к потоку и перестаёт различать, а критичное событие ничем не выделено на фоне рутины.
Ломается это на природе внимания: оно не масштабируется, как процессор, и не делится без потерь. Настройка devin.agentNotifications шлёт одно нативное уведомление ОС, когда сессия завершилась или ждёт вашего ответа - и это единый механизм сразу для Cascade, Devin Local и ACP. Смысл его в том, чтобы дёрнуть вас на переход состояния сессии, а не на каждый её внутренний шаг. Если превратить уведомления в поток по каждому tool call, механизм обесценит сам себя, и вы отключите его целиком - вместе с полезными сигналами.
Отсюда первое правило: уведомления - для блокеров и завершений, а не для хода работы. Пусть агент молча делает разрешённое ему и зовёт человека только тогда, когда действительно ждёт: подтверждение чувствительного действия, неоднозначное решение, готовый к review результат. Command Center при этом показывает всё разом - доску в стиле kanban по статусам, где видно, кто сейчас работает, кто заблокирован и кто готов к проверке. Ход работы наблюдают взглядом на эту доску по своей инициативе, а не потоком алертов, выдёргивающих вас из другой задачи.
Второе правило - о порядке ответа, когда ждущих сессий сразу несколько. Отвечать в порядке прихода здесь неверно; сессии сортируют по типу и риску. Сначала security и approval - то, что блокирует дальнейшую работу и притом чувствительно. Потом неоднозначные решения, где нужен именно ваш выбор, а не догадка агента. Затем готовое к review, что можно спокойно проверить. И в самом конце - информационное, что достаточно просто заметить. Такая очередь ставит вперёд не самое раннее по времени, а самое дорогое в случае ошибки.
Отдельно - о соблазне подтверждать одинаковое на автомате. Две сессии просят разрешить одну и ту же на вид команду, и рука тянется нажать "да" второй раз уже не глядя, по инерции первого. Но CWD и scope у них могут отличаться: та же по тексту команда в другом рабочем каталоге или с другим охватом файлов - это фактически другое действие с другими последствиями. Одинаковый текст не значит одинаковый результат, и каждое подтверждение стоит читать как отдельное, сколько бы похожих ни было до него.
Цена плохой очереди измеряется не потерянными секундами, а потерянными переключениями. Каждый прыжок между сессиями стоит контекста: вы заново вспоминаете, что это за задача, на каком она шаге и что в ней вообще разрешено. Поэтому агентов разумно оптимизировать не только по времени их выполнения, но и по числу человеческих переключений, которых они требуют. Хорошая очередь группирует проверки по репозиторию и типу риска, чтобы соседние решения опирались на один и тот же контекст и не заставляли перестраиваться каждый раз.
Вся эта дисциплина оправдана ровно тогда, когда сессий больше одной. На единственной задаче хватает простого взгляда в окно, и городить очередь незачем. Но как только сессий становится три-четыре, разница между "реагирую на каждый звонок" и "разбираю очередь по риску" - это разница между управляемой работой и дёрганьем, которое к концу дня выматывает сильнее самой работы.
Проверять настроенное внимание стоит по нескольким конкретным признакам. Приходят ли уведомления только на блокеры и завершения, а не на каждый tool call. Сгруппированы ли ждущие сессии по типу риска, а не свалены в одну ленту по времени. Читаете ли вы CWD и scope перед каждым повторным подтверждением. Считаете ли вы число переключений, а не только потраченные минуты. Если на доске Command Center ясно видно, кто ждёт и почему, а уведомления при этом молчат на рутине - очередь настроена правильно.
Типичные провалы предсказуемы и узнаваемы. "Пропустил важное" - уведомления шумели на всё, и один настоящий блокер потонул среди десятка информационных. "Подтвердил не то" - нажал "да" по инерции, а CWD у второй сессии был совсем другой. "Устал от переключений" - прыгал по сессиям в порядке прихода, каждый раз заново загружая чужой контекст. Признак один: вниманием управляли как будто оно бесконечно. Признать его самым узким ресурсом и тратить строго по риску - и многоагентная работа перестаёт изматывать, оставаясь при этом быстрой.