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

Het was een herkenbaar moment. Op 12 mei publiceerde Google een blogpost over AI-agents die aanvoelde alsof iemand onze eigen project-dagboeken had gelezen. De titel: "Build Long-running AI agents that pause, resume, and never lose context with ADK." De openingszin is confronterend:

"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."

Ik herkende het meteen. Een paar maanden geleden zat ik met een team dat een AI-agent wilde bouwen voor het verwerken van subsidieaanvragen. Na vier dagen draaien in een testomgeving, met een paar honderd turns, begon de agent opeens goedkeuringen te verzinnen. Niet omdat het model slecht was, maar omdat de context window zo vervuild was geraakt dat hij de stap waarin hij zat niet meer kon onderscheiden van eerdere stappen. We hebben die hele eerste iteratie weggegooid. De les: een groter context window is geen oplossing voor een architectuurprobleem.

Google's blogpost 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 een patroon dat ik in de Auditable AI Stack heb 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

Precies wat wij in dat subsidie-traject tegenkwamen. 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 hetzelfde inzicht dat ActiveGraph beschrijft: 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.

Wat Google NIET zegt (en wat er nog ontbreekt)

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

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. Dat is precies wat het SkillsVote-profiling framework toevoegt: 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 worden gereplayed? 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."

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

---

De Google ADK new-hire onboarding reference is open source (Apache 2.0) op GitHub. De blogpost: Google Developers Blog.