Google’s newest Agent Development Kit tutorial is notable because it treats “agentic” as an infrastructure problem, not a prompt-engineering trick.
Published on May 12, the post walks through a New Hire Onboarding Coordinator Agent that can run for weeks. It sends a welcome packet, waits while an employee signs documents, delegates IT provisioning to a specialised sub-agent, waits for hardware delivery, then sends a day-one schedule. The key detail is not the HR example. It is that the agent pauses, resumes and keeps its state without relying on an ever-growing chat transcript.
Google frames the problem bluntly: most agent tutorials end at a stateless chatbot. That pattern works for a five-minute Q&A loop. It breaks when a workflow waits days for a signature, approval, vendor reply or delivery confirmation. Long histories pollute prompts, token costs grow, and the model may “remember” steps that never happened.
The proposed fix has three parts: durable memory schemas, event-driven dormancy gates, and multi-agent delegation. In the tutorial, ADK’s session service persists state using SQLite locally or Cloud SQL in production. Webhook endpoints wake the agent when external events occur, hydrate the saved session, transition the state machine and resume the workflow. The agent sleeps during idle time instead of polling or holding a blocked thread.
That sounds like conventional backend engineering because it is. And that is the point.
For software teams, the same pattern applies to coding agents. A serious codebase migration may wait on CI, human review, package releases, staging approval or client sign-off. If the agent’s only memory is “the conversation so far”, it is fragile. If the agent has explicit checkpoints, event triggers and a recoverable state machine, it starts to look like a real workflow worker.
This is especially relevant for agencies and internal platform teams. Many useful AI tasks are not single-shot “write a function” jobs. They are multi-step maintenance flows: inspect a repo, propose a dependency update, wait for tests, respond to review comments, re-run checks, pause for approval, then prepare release notes. The more those flows span systems and days, the less a chat interface is enough.
The caveat is that Google’s post is a tutorial, not evidence that ADK agents can safely run arbitrary long-horizon business processes. The hard parts remain: permissions, observability, rollback, cost control, evaluation, and deciding when the model is allowed to act versus when it must ask. But the architecture is the right conversation.
The agent boom has produced plenty of demos where a model appears to do ten minutes of work. Google’s ADK piece is about the duller requirement underneath the useful ones: agents need to stop, wait, wake up and know exactly where they are.