ADK выводит агентов за пределы chat session

ADK показывает, как строить long-running AI agents с durable state, webhooks и resume после пауз без потери контекста.

2026-05-16 GIGATAP Team #security
#AI agents#Google ADK#developer tools

Сдвиг — не в более умном чате. Сдвиг — в durable execution.#

Google Developers Blog опубликовал tutorial о создании long-running AI agents с помощью Agent Development Kit, или ADK. Пример — automation enterprise workflow: задачи вроде HR onboarding, которые не завершаются в одном chat window и могут растягиваться на дни или недели.

Это важное различие. Многие agent demos всё ещё ведут себя как расширенные chatbots. Они получают prompt, вызывают tools, возвращают answer и сильно зависят от текущей runtime session. Если process останавливается, server перезапускается или user пропадает на два дня, system часто требует специальной обработки, чтобы корректно восстановиться.

ADK tutorial указывает на другую operating model. Agent рассматривается не столько как live conversation, сколько как workflow participant с durable state. Он может pause, пока ждёт external events. Может resume после idle time. Может пережить server restart без потери working context, нужного для продолжения task.

Это практический разрыв между prototype agent и тем, что enterprise может безопасно подключить к реальным processes.

Что ADK добавляет к agent model#

Source material выделяет два architectural shifts: durable state machines и persistent session storage.

Durable state machine даёт workflow явную форму. Вместо опоры только на in-memory chain of reasoning или transient chat history system записывает, где agent находится в process. Это важно, когда workflow содержит steps, которые нельзя завершить сразу: ожидание manager approval, webhook от другого service, заполненная form или update во external system.

Persistent session storage решает связанную memory problem. Long-running agents нуждаются не только в prompt и response. Им нужно помнить, что уже произошло, какие decisions были приняты, какие data собраны и какой step следующий. Если этот state существует только в running process, он хрупок. Если он stored persistently, agent может resume с правильным context после pause или infrastructure interruption.

Tutorial также описывает event-driven webhooks. Это важно, потому что long-running enterprise work редко бывает continuous conversation. Большую часть времени ничего не происходит. System ждёт. Form pending. Ticket reviewed. Person ещё не clicked link.

В такой model agent не должен продолжать притворяться active. Он должен cleanly sleep, затем wake, когда приходит external event. Webhooks — trigger path для такого resume behavior.

Source также упоминает multi-agent delegation. На практике это означает, что complex workflow можно разделить между specialized agents или components, вместо того чтобы заставлять одного agent обрабатывать каждую subtask. В onboarding scenario одна часть может заниматься document collection, другая — взаимодействовать с internal systems, третья — координировать status или next steps.

Полезный вывод не в том, что каждому workflow нужно много agents. А в том, что ADK позиционируется для systems, где важны task ownership, handoff и state continuity.

Почему это важно для production agents#

Сложная часть enterprise agents часто не в способности model выдать plausible answer. Сложность в том, ведёт ли себя surrounding system корректно, когда реальность становится messy.

Long-running workflows создают несколько failure points:

  • user уходит и возвращается позже;
  • server перезапускается в середине process;
  • approval приходит через несколько часов после original request;
  • external tool отвечает asynchronously;
  • другой service меняет state workflow;
  • agent должен понимать, продолжать, retry, ask for input или stop.

Stateless chatbot pattern слаб в таких условиях. Он может реконструировать часть context из prior messages, но это не то же самое, что надёжный workflow state. Reconstructing state from conversation также может вносить ambiguity. Agent может incorrectly infer, повторить work, пропустить step или действовать на stale assumptions.

Durable state меняет trust model. System не просит model помнить всё только из language. Она записывает operational state и даёт agent определённую точку для resume.

Это особенно актуально для workflows, связанных с HR, finance, legal, access provisioning, procurement, support escalation или compliance-sensitive internal operations. Это не те области, где принцип «model remembers» достаточно силён для design.

Практический takeaway: если agent должен жить дольше одного request, ждать approvals или webhooks, переживать restarts и продолжать workflow без ручного восстановления context, его нужно проектировать как durable workflow, а не как chatbot с длинной history. Минимальный production checklist: явная state machine, persistent session storage, idempotent webhook handlers, retry policy, audit trail и tests на restart, duplicate events, partial tool failure и stale state.

Source утверждает, что такой подход поддерживает resilient systems, которые могут pause, resume и сохранять high reasoning accuracy across complex tasks. Цель правильная. Более сильные доказательства для любого конкретного deployment всё равно должны приходить из testing: restart behavior, interrupted sessions, duplicate webhook delivery, partial tool failures.