Google's ADK bewijst het: productie-agents hebben state machines nodig, geen grotere context windows

Op 12 mei publiceerde Google een opvallend eerlijke blogpost over AI-agents. De titel: "Build Long-running AI agents that pause, resume, and never lose context with ADK." De openingszin liegt er niet om:

"Most agent tutorials end at a stateless chatbot — a conversational loop that forgets everything the moment the container restarts. Real enterprise workflows don't wrap up in a single API call."

Het is een impliciete erkenning dat de dominante agent-architectuur — de LLM chat-loop met tools — fundamenteel ongeschikt is voor productie. En het is een expliciete validatie van wat wij in de Auditable AI Stack hebben beschreven: de toekomst van agents is event-driven, state-machine-gebaseerd, en expliciet — niet chat-driven, context-venster-gebaseerd, en impliciet.

Wat Google zegt (en waarom het ertoe doet)

De Google Developers Blog beschrijft drie faalmodi van stateless agents over multi-day workflows:

1. Prompt context pollution — na honderden turns volgt het model niet meer in welke stap het zit
2. Token cost explosion — een volledige twee-weken conversatiehistory herhalen bij elke inference call
3. Reasoning hallucinations over idle time — na dagen dormantie "herinnert" het model zich approvals die nooit gegeven zijn

De conclusie van Shubham Saboo en Eric Dong: "The fix isn't a bigger context window. It's a fundamentally different architecture."

Die architectuur heeft drie pijlers:

1. Durable memory schema — niet raw JSON in een vector database

In plaats van conversatie-history te dumpen in een vector store, gebruikt de ADK een expliciete enum-based state machine die in SQLite of Cloud SQL wordt gepersisteerd. De state is een simpel Python enum:

class OnboardingStep:
    START = "START"
    WELCOME_SENT = "WELCOME_SENT"
    DOCUMENTS_SIGNED = "DOCUMENTS_SIGNED"
    IT_PROVISIONED = "IT_PROVISIONED"
    HARDWARE_DELIVERED = "HARDWARE_DELIVERED"
    COMPLETED = "COMPLETED"

Dit is fundamenteel hetzelfde inzicht dat ActiveGraph twee weken later zou publiceren: expliciete, durable state is de bron van waarheid, niet de conversatie-history. Waar ActiveGraph een event-sourced model gebruikt, gebruikt Google een enum state machine. Het principe is identiek.

2. Event-driven dormancy gates — niet actief pollen

De agent draait niet in een oneindige loop. Hij pauzeert bij dormancy gates — momenten waarop een extern event nodig is — en de container schaalt naar nul. Een webhook (receive_signed_documents_callback) hydrateert de sessie en resumed de runner:

async for event in self.runner.run_async(
    user_id=user_id,
    session_id=session_id,
    state_delta={
        "current_step": OnboardingStep.DOCUMENTS_SIGNED,
    },
):
    ...

Dit elimineert idle compute-kosten én voorkomt dat het model gaat hallucineren over wat er "waarschijnlijk" gebeurd is tijdens de wachttijd. De agent resumeert alleen wanneer er daadwerkelijk een state change is.

3. Multi-agent delegatie — niet alles in één prompt

De HR-coordinator delegeert IT-provisioning naar een gespecialiseerde sub-agent:

it_agent = Agent(
    name="it_agent",
    model=Gemini(model="gemini-3.1-flash-lite"),
    tools=[provision_software_accounts],
)

root_agent = Agent(
    name="hr_onboarding_coordinator",
    sub_agents=[it_agent],
)

De coordinator's instructie zegt: "Delegate the IT accounts provisioning to the 'it_agent' subagent. Do not call tools directly." Dit ontkoppelt complexe workflows en voorkomt prompt-bloat. Het is ook precies wat SkillsVote beschrijft als lifecycle governance: gespecialiseerde skills met duidelijke boundaries.

Wat Google NIET zegt (en wat de Auditable AI Stack toevoegt)

De ADK is een productie-patroon — maar het is geen compleet antwoord op auditable AI. Drie dingen ontbreken:

1. Self-evolving memory. De ADK gebruikt een fixed state machine. Als de onboarding-workflow verandert (nieuwe compliance-stap, ander document), moet een mens de enum aanpassen. EvolveMem laat zien dat retrieval-configuraties zichzelf kunnen verbeteren via een AutoResearch-loop. Diezelfde logica kan worden toegepast op state machines: een agent die zelf ontdekt dat een nieuwe stap nodig is en die toevoegt aan de enum.

2. Skill governance. De ADK's tools (send_welcome_packet, provision_software_accounts) zijn hardcoded Python functies. Er is geen lifecycle management — geen profiling op kwaliteit, geen verifiability-check, geen evidence-gated evolution. SkillsVote's profiling framework (runtime requirements, quality, verifiability) is exact wat ontbreekt: een manier om te bepalen of een tool veilig, correct en verifieerbaar is vóórdat hij in een productie-agent wordt geladen.

3. Deterministische replay. De ADK logged uitgebreid naar Cloud Trace en BigQuery — maar kan een volledige run byte-identiek replayed worden? Nee. ActiveGraph's determinism contract en content-addressed LLM response cache maken replay mogelijk zonder nieuwe model calls. Voor forensisch onderzoek na een AI-incident is dat het verschil tussen "we hebben logs" en "we hebben bewijs."

De complete stack: Google's ADK + de Auditable AI Stack

Wat gebeurt er als je Google's productiepatroon combineert met de drie papers uit mei 2026?

┌────────────────────────────────────────────────┐
│ SkillsVote: Tool lifecycle governance          │ ← Profiling, attribution, controlled evolution
├────────────────────────────────────────────────┤
│ EvolveMem: Zelf-verbeterend geheugen           │ ← AutoResearch op retrieval + state
├────────────────────────────────────────────────┤
│ ActiveGraph: Event-sourced state machine       │ ← Deterministische replay, cheap forking
├────────────────────────────────────────────────┤
│ Google ADK: Dormancy gates + multi-agent       │ ← Productie-runtime, webhook resume, observability
└────────────────────────────────────────────────┘

De ADK levert de productie-runtime. ActiveGraph levert de event-sourced fundering. EvolveMem levert de self-adaptatie. SkillsVote levert de tool governance. Samen is dit een architectuur die:

• Wekenlang draait zonder context pollution (ADK)
• Volledig replayable is vanaf de event log (ActiveGraph)
• Zichzelf verbetert zonder handmatige tuning (EvolveMem)
• Elke tool change documenteert met evidence en attribution (SkillsVote)

Waarom dit nú relevant is voor de Nederlandse overheid

De EU AI Act wordt vanaf augustus 2026 van kracht voor hoog-risico AI-systemen. De eisen aan transparantie, traceerbaarheid en menselijk toezicht zijn niet te halen met een stateless chatbot die conversatie-history in een vector database dumpt.

Google's ADK-blogpost is in feite een erkenning van dit probleem vanuit 's werelds grootste AI-bedrijf. Het productie-antwoord is geen groter context window — het is een fundamenteel andere architectuur.

Voor Nederlandse overheidsorganisaties betekent dit:

• Vergunningaanvragen die dagenlang wachten op aanvullende documenten → dormancy gates
• Inkoopprocessen die wachten op leveranciersoffertes → state machine met webhook resume
• Bezwaarschriften die wachten op dossiers en hoorzittingen → multi-agent delegatie
• Allemaal met BIO2-compliant logging, traceerbare state transities, en volledige audit trail

DjimIT bouwt deze architectuur — met het beste van Google's productiepatronen én de nieuwste inzichten uit het onderzoek — op soevereine, Nederlandse infrastructuur.

---

De Google ADK new-hire onboarding reference is open source (Apache 2.0) op GitHub. De blogpost: Google Developers Blog. DjimIT helpt organisaties met het implementeren van auditable, long-running agents voor de Nederlandse publieke sector — neem contact op.