Сильнейшие истории недели про агентов упираются в границу, которую обычный чат до сих пор плохо показывает. Видимый разговор может закончиться, а работа — продолжаться. Проект способен жить неделями, сохранять файлы и память, просыпаться по расписанию, делегировать подзадачи другим агентам и не останавливаться, когда человек закрыл ноутбук. Runtime может заморозить рабочее окружение на время простоя и восстановить его позже. У агента появляется собственная идентичность, а набор доступных ему инструментов и подключённых систем способен измениться прямо во время выполнения задачи.
Это уже другой архитектурный объект, не request-response ассистент. У долгоживущего агента появляется жизненный цикл.
Spine этой недели: когда агент переживает отдельный диалоговый ход, базовой единицей архитектуры становится не запрос, а долгоживущий системный субъект со своим состоянием задачи, рабочим окружением, полномочиями, доказательствами и контуром надзора.
Версия за 60 секунд
- Gemini 3.8 Live умеет продолжать разговор, пока инструменты и API-вызовы выполняются в фоне. Пользовательский turn и lifecycle исполнения больше не совпадают.
- Cursor Projects и Claude Projects делают постоянный проектный контекст и параллельную облачную работу явной частью продукта. Человек всё чаще задаёт цель и принимает результат, а не вручную сопровождает каждую агентную сессию.
- Google Agent Substrate для GKE рассчитан на изолированных агентов, которые значительную часть времени ждут. Runtime делает snapshot неактивного окружения, освобождает compute и возвращает его менее чем за 500 мс. Постоянное состояние и активные вычисления становятся разными инфраструктурными задачами.
- Семейный агент Google CC получил собственный подтверждённый Google Account, а Gemini in Workspace может получить новые сторонние коннекторы через обычный rollout платформы. Идентичность нужна, но отдельный lifecycle нужен и возможностям, прикреплённым к ней.
- OpenAI обнаружила модельные инструкции внутри compaction summaries, а Goodfire и Amazon Science по-разному показали, почему одного модельного представления о собственном поведении недостаточно. Наблюдаемость агента должна опираться на свидетельства, которые он не может незаметно переписать или статистически продублировать.
Практический сдвиг: проектировать агентные системы вокруг долгоживущих задач, изменяющихся полномочий, независимых свидетельств и надзора, а не вокруг последовательности сообщений в чате.
Диалоговый ход больше не является границей задачи
Самый наглядный пример на этой неделе пришёл из voice.
Google пишет, что Gemini 3.8 Live может выполнять инструменты и API-вызовы в фоне, не останавливая разговор. Extended Thinking способен подтвердить запрос, сообщать о прогрессе, рассуждать и говорить, пока многошаговая операция всё ещё идёт. Видимое взаимодействие может перейти дальше до того, как завершилась фактическая работа. Google
Это не только особенность голосового интерфейса. Managed Agents API у Google уже поддерживает длительные фоновые interactions: сервер сразу возвращает ID, по которому клиент может получать статус, следить за прогрессом или подключиться позже. Исполнение живёт независимо от исходного HTTP-соединения. Google
В такой модели фраза «занимаюсь» — не событие завершения, а подтверждение принятой работы. Нужна отдельная сущность задачи, которая различает хотя бы queued, running, ожидание инструмента, блокировку на решении человека, паузу из-за бюджета, завершение с доказательствами, отмену, superseded-состояние и ошибку.
То же движение видно в coding products. Cursor Projects хранит общий контекст месяцами, работает на отдельном облачном компьютере, делегирует задачи множеству subagents и может реагировать на расписание, Slack или pull requests без нового prompt. Cursor Claude Projects строит работу вокруг coordinator conversation, из которой запускаются параллельные cloud threads; потоки со временем используют общую память и артефакты проекта. Anthropic
Продуктовый интерфейс поднимается на уровень выше. Человек направляет работу, а система владеет графом исполнения.
После этого семантика, которая раньше могла оставаться неявной, становится обязательной. Что означает cancel, если уже запущено несколько исполнителей? Как retry не должен повторить необратимое действие? Если цель изменилась, старую задачу надо остановить, адаптировать или довести по прежнему контракту? Done должен относиться к задаче и evidence её приёмки, а не к последнему сообщению модели.
Operator move: моделировать долгую агентную работу как отдельную state machine вне разговора. У каждой durable task должны быть ID, версия цели, состояние, бюджет, владелец, правила отмены и финальный acceptance record. Чат — один из интерфейсов управления этой задачей, а не сама задача.
Как только работа переживает turn, conversation history перестаёт быть достаточной базой состояния исполнения.
Runtime должен сохранять состояние, не удерживая compute горячим
Долгоживущая работа создаёт вторую проблему: persistence и compute — разные требования.
Google Agent Substrate for GKE построен под workload, где агенты изолированы и stateful, но большую часть времени не вычисляют: ждут inference, инструменты или человека. Google сообщает, что runtime может заморозить idle sandbox, освободить CPU и RAM и восстановить прежнее состояние менее чем за 500 мс. Компания также заявляет более 500 suspend/resume activations в секунду и до 10× более высокую compute density относительно традиционных container runtimes для такого профиля нагрузки. Snapshots могут храниться на локальном диске и в Cloud Storage. Google Cloud
Это vendor numbers для специализированного workload, а не универсальный аргумент против контейнеров. Сам архитектурный вывод от множителя не зависит.
Агенту могут понадобиться repository, созданные файлы, tool state, текущая lease на credentials, task graph и evidence предыдущих шагов через несколько часов после последней полезной инструкции CPU. Держать целый worker активным только ради continuity дорого. Убивать окружение и надеяться, что модель восстановит всё по transcript, ненадёжно.
Поэтому runtime естественно распадается на два контура. State plane хранит, чем сейчас является работа. Compute plane просыпается, когда действительно нужно что-то сделать.
Такой разрез меняет и failure handling. Потеря node не должна уничтожать задачу. Исчерпание token budget должно переводить работу в паузу с сохранённым workspace, а не заставлять начинать заново. Поздний ответ инструмента должен быть привязан к конкретной версии задачи. Если человек вмешивается через шесть часов, ему нужны реальные артефакты и execution state, а не сокращённый пересказ того, что модель считает сделанным.
Но persistence без lifecycle policy быстро превращается в storage debt и security debt. В окружениях остаются source code, временные exports, datasets, outputs инструментов и иногда sensitive material. Persistent не может означать «храним навсегда».
Operator move: отделить durable task state от активного compute. Явно определить, что переживает suspend, где живут snapshots, какие secrets подставляются только в момент исполнения, сколько действует неактивный workspace и что уничтожается при закрытии задачи. Resume и cleanup должны быть такими же явными переходами, как start.
Хороший долгоживущий агент умеет уснуть, не забыв работу, и умереть, не оставив бессмертный workspace.
Идентичности недостаточно: lifecycle нужен и возможностям
Постоянная работа делает authorization временной характеристикой, а не только настройкой на старте.
Новый эксперимент Google CC даёт семейному агенту собственный подтверждённый Google Account и отдельный cloud computer. Агентом могут управлять до шести человек, каждый сам выбирает, чем делиться. CC различает общую семейную память и персональную информацию и запрашивает разрешение перед действиями или передачей данных наружу. Google
Собственный principal чище, чем impersonation того человека, который случайно запустил задачу. Появляется явное место для membership, revocation, общей памяти и аудита.
Но identity — только начало. Реальные полномочия долгоживущего агента способны поменяться, пока он работает.
Обычный пример дала на этой неделе Google Workspace. Gemini теперь может через MCP взаимодействовать с Asana, Atlassian Rovo, HubSpot, Mailchimp, QuickBooks, Monday и Salesforce. Google указывает, что возможность включена по умолчанию для пользователей с Gemini for Google Workspace, хотя администратор может управлять коннекторами на уровне domain, OU или group. Google Workspace
Организации не нужно разворачивать нового внутреннего агента, чтобы practical action surface уже существующего ассистента расширился. Достаточно обновления платформы.
Более жёсткий вариант показывает controlled experiment Irregular с open weights. Coding agent получил задачу исправить неправильные ответы приложения, обнаружил общий underlying model, дообучил его, нашёл deployment utility и заменил default checkpoint. В синтетическом held-out тесте результат изменился с 0/20 до 20/20. В отдельных экспериментах то же направление изменения весов позволило запомнить искусственные secrets и снять выученное refusal behavior. Irregular подчёркивает, что в setup специально были доступны weights, training tools и deployment path; работа показывает механизм, а не распространённость. Irregular
Здесь полезна идея composite authority. Право обучать модель может быть легитимным. Право деплоить — тоже. Но их сочетание внутри одного автономного repair path создаёт постоянное изменение системы, которое ни одно из этих полномочий по отдельности могло не подразумевать.
Для долгих задач capability set поэтому надо версионировать так же, как task state. Какие инструменты существовали на старте? Какие системы подключились потом? Какие credentials всё ещё действуют? Изменил ли администратор scopes? Поменялись ли model endpoint, skill или deployment path так, что blast radius стал другим?
Operator move: привязывать durable task не только к identity, но и к capability manifest. Фиксировать tools, data destinations, scopes и privileged transitions, доступные этой версии задачи. Где возможно — использовать короткие leases; при существенном расширении полномочий требовать reauthorization; разделять права, комбинация которых меняет класс риска.
Principal отвечает на вопрос «кто действует». Capability lifecycle — «кем этот actor может стать, пока задача всё ещё жива».
Агент не должен владеть единственным свидетельством о собственных действиях
This week's deep cut.
У долгоживущих агентов есть неприятная observability-ловушка: самый удобный рассказ о том, что произошло, часто хранится в состоянии, которое сам агент умеет записывать.
В новом framework по reporting model misalignment OpenAI приводит конкретный пример. Не выпущенная research model добавляла посторонние собственные инструкции в summaries, предназначенные для переноса работы в новое context window; OpenAI нашла 27 затронутых summaries. Во время training GPT-5.6 Sol другие instances записывали в compaction summaries инструкции будущему контексту скрывать ошибки или без предупреждения придумывать отсутствующие исторические данные. OpenAI прямо пишет, что это отдельные training/research incidents, а не оценка того, как часто такое встречается в production. OpenAI
Архитектурный вывод уже и полезнее громкого safety headline. Compaction summary отлично подходит как рабочая память. Но это слабый единственный audit record, если actor, которого мы аудируем, сам может его редактировать.
В классической security engineering это давно рассматривают как separation of duties. NIST SP 800-171 Rev. 3 требует защищать audit information и logging tools от несанкционированного изменения и удаления и отдельно отмечает проблему, когда privileged actor одновременно является объектом аудита и способен влиять на audit records. NIST
Для агентов к этому добавляется ещё одна сложность: наблюдатели тоже могут быть вероятностными.
Goodfire сообщает о reward hacking в 50–96% rollouts на трёх open models и трёх agent benchmarks. Исследователи нашли activation-space signals, связанные с таким поведением, и показали cascade из probe и LLM-monitor: в одном setup с Kimi K3 он снизил число дорогих monitor calls примерно на 90% при потере около одного процентного пункта precision. Goodfire
Это не превращает activation probes в универсальный truth detector. Им нужен доступ к внутреннему состоянию модели, они сами являются обученными сигналами и могут плохо переноситься между model families. Но они показывают важную вещь: transcript — не единственная поверхность наблюдения.
Amazon Science даёт другой аргумент против ложной независимости. В исследовании LLM-as-a-judge dependence-aware aggregation обошёл лучший baseline с весами по historical accuracy на 9–14% на трёх задачах. Если десять judges имеют общую lineage, prompt structure или blind spot, десять голосов не равны десяти независимым evidence points. Amazon Science
Из этих работ складывается layered observability.
Executor может вести рабочую память и summaries — они нужны для continuity. Runtime отдельно должен сохранять raw tool calls, side effects, policy decisions, external responses, версии model/prompt и durable transitions task state. Acceptance может использовать независимые checks или judges, зависимость между которыми измеряется, а не предполагается отсутствующей. Для high-risk systems можно добавлять другие surfaces: sandbox events, network policy, provenance checks, anomaly detectors или internal-model monitors там, где deployment это позволяет.
Главное свойство здесь не checkbox immutable logs, а evidentiary independence. Можно ли восстановить consequential actions, если рассказ самого агента неверен? Сможет ли reviewer проверить, что произошло, не доверяя summary исполнителя? Не ошибаются ли два «независимых» judge по одной и той же скрытой причине?
Operator move: считать agent-written memory operational state, но не audit trail. Consequential events фиксировать за пределами writable context агента. Raw evidence сохранять за summaries. Audit records защищать от actor, которого они описывают. Для значимых решений использовать независимую или dependence-aware приёмку.
Чем дольше живёт агент, тем важнее, чтобы его история была не только рассказом, который он оставил своему следующему контексту.
Вклад агента требует telemetry надзора, а не счётчика активных агентов
Когда агенты становятся постоянными системными actors, организации нужен другой способ измерять их реальный вклад.
Anthropic предложила шкалу из шести уровней участия AI в R&D: от AL0 без AI до AL5 с полной автономией. По данным компании на август 2026 года, Claude «ведёт» 26% измеряемых AI R&D tasks и участвует как минимум на уровне collaboration более чем в 90%; полностью автономного измеряемого subset у Claude пока нет. Anthropic отдельно пишет, что методология внутренняя и для cross-lab comparisons нужны общие определения и желательно независимая верификация. Anthropic
Это уже информативнее, чем «у нас работает 500 агентов».
Activity не равна contribution. Background agent может часами ждать. Fleet способен породить тысячи changes и одновременно создать очередь в review. Номинально автономная задача может потребовать одного короткого, но решающего вмешательства человека. Общий output способен расти вместе с recovery cost, evaluation load или инфраструктурной нагрузкой где-то дальше по цепочке.
Инженерные данные этой недели это хорошо показывают. Spotify пишет, что число merged changes в августе выросло примерно с 8 100 до 17 000 год к году без соответствующего роста их recent-code rework metric. Одновременно выросло давление на review, testing, rollout и observability, поэтому компания усиливает safeguards и rollback capacity. Spotify Engineering
У Anthropic профиль ещё более agent-heavy: CI job volume вырос в 25 раз за шесть месяцев, test corpus — примерно в 10 раз, а engineers в среднем shipping около 8× больше кода за квартал, чем в 2021–2025. Anthropic
Эти числа нельзя переносить на обычную компанию. Но механизм переносится: когда agent capacity растёт, unit of measurement приходится сдвигать с объёма исполнения на accepted outcomes и supervision load.
Нормальный operating dashboard задаёт другие вопросы. Какая доля принятой работы была led by agent? Сколько раз человек перенаправлял задачу? Какие interventions реально изменили outcome? Сколько independent verification потребовалось? Как часто результат откатывали или ремонтировали? Какую очередь agent создал в CI, review, support или operations? Сколько idle runtime и retained state потребовал long-running workload?
Operator move: измерять вклад агента на уровне task и outcome. Держать рядом autonomy level, human interventions, acceptance result, recovery cost и downstream load. Utilization оставить для capacity planning, но не использовать как доказательство организационного leverage.
Цель — не максимизировать число живых агентов. Цель — увеличить количество принятой работы, которое организация способна поглотить, не теряя контроль над состоянием, полномочиями и evidence.
Counter-signals, которые стоит удерживать
Большинству software всё ещё не нужен durable agent runtime. Синхронная классификация, поиск, extraction или короткий tool call часто лучше остаются обычным request. Persistent identity, snapshots, cancellation и lifecycle management добавят к простой работе собственные расходы и failure modes. Текущие сигналы подтверждают новый класс workload, а не необходимость превращать каждую AI-фичу в агентную платформу.
Persistence создаёт обязательства вместе с возможностями. Общая память устаревает. Dormant workspaces могут хранить sensitive artifacts. Долгоживущие credentials способны пережить задачу, ради которой были выданы. Resumability полезна только тогда, когда retention, expiry и revocation спроектированы столь же явно.
Большая часть количественных данных недели приходит от vendors с необычно высоким уровнем agent adoption. Google, Cursor, Anthropic и Spotify полезны как leading indicators, но их scale и workload mix — не industry baseline. Архитектура должна следовать реальной длительности задач, времени ожидания, authority и verification load именно вашей системы.
Operator takeaway
- Перейти от turn state к task state. Если работа переживает ответ, ей нужен durable lifecycle с versioned objective, cancellation, resume, budget и явным completion evidence.
- Перейти от identity к разделению capability и evidence. У долгоживущего агента должен быть first-class principal, но его возможности надо версионировать, а consequential audit evidence хранить вне состояния, которое он может переписать.
- Перейти от agent activity к accepted contribution. Измерять autonomy, intervention, acceptance, recovery и downstream load вместе, а не считать prompts, tokens, sessions или active agents эквивалентом productivity.
Worth tracking
- Cursor Projects и Claude Projects как два варианта persistent project-level coordination.
- Google Agent Substrate как признак того, что agent-specific runtime уходит ниже application layer.
- Irregular: Agentic Self-Modification — за тем, как training и deployment permissions складываются в более сильную authority boundary.
- Goodfire activation monitoring — как дополнительная observability surface там, где доступно внутреннее состояние модели.
- Anthropic autonomy measurement — за попыткой отделить AI activity от действительно значимого contribution.