The framework IVE was built on has already had its biggest architectural revision since launch. IVE’s own reference page describes an agent built with Google ADK’s LlmAgent, Runner, and RunConfig — the classical, hierarchical way of building an ADK agent. Since then, Google has shipped ADK 2.0, which replaces that hierarchical executor with a graph-based Workflow Runtime. This is what changed, stated as precisely as the public record allows.
What IVE was built with, exactly as documented
Public evidence: IVE’s own reference implementation page describes its orchestration as “a LlmAgent of the Google ADK, executed by a Runner with RunConfig(max_llm_calls=10) as an iteration limit,” built during the All Things Agentic Hackathon 2026 (submissions ran August 3–31, 2026). It also explicitly discloses what the implementation does not do: no automatic retries, no exactly-once guarantees across requests, no persistent ADK sessions between calls.
This article cannot independently confirm the exact ADK version pinned in IVE’s codebase. The GitHub repository linked from IVE’s own reference page returned a 404 at the time of writing and could not be checked. Everything below about “what IVE was built with” is limited to what InsightValues has already publicly disclosed in prose — not a verified dependency file.
What changed: ADK 2.0’s Workflow Runtime
External research, official documentation: ADK Python 2.0 reached general availability on May 19, 2026 — before the hackathon window closed. According to Google’s own ADK 2.0 documentation, the release replaces the hierarchical agent executor with a graph-based execution engine, where “Agents, Tools, and Functions are evaluated as individual nodes within a workflow graph.”
Execution model
THEN: a hierarchical tree of agents, each calling the next. NOW: a workflow graph supporting routing, fan-out/fan-in, loops, retry, and nested workflows as first-class constructs.
Human-in-the-loop
THEN: an application-level concern, built outside the framework (this is exactly how IVE’s own Human Gate policy check works — as an external authorization step, not an ADK primitive). NOW: the Workflow Runtime supports human-in-the-loop pausing as a native node type in the graph.
Retry and error handling
THEN: IVE explicitly discloses it implements no automatic retry. NOW: ADK 2.0 “auto-catches exceptions for retries and human-in-the-loop pausing” at the framework level — broad exception handling in agent code now risks masking failures the framework would otherwise catch.
Backward compatibility
Google’s documentation states ADK 2.0 is designed to be compatible with agents built on ADK 1.x, and base agent classes now extend a common node type, preserving functional compatibility. A codebase using LlmAgent/Runner/RunConfig is not obsolete — it simply doesn’t use the new graph capabilities without migration work.
What this would plausibly change for something like IVE’s Human Gate
Interpretation, not a roadmap claim: IVE’s Human Gate — the policy/risk check that sits between a proposed action and its execution — was necessarily built as external application logic, because the classical ADK executor had no native concept of a pause-for-human-decision node. If a team built the same system today on ADK 2.0’s Workflow Runtime, the human-in-the-loop pause could plausibly be modeled as a node in the graph itself, rather than as a check wrapped around the agent from outside. This is a reasonable inference from what Google’s documentation describes, not a statement about InsightValues’ actual plans or a claim that this is a strict improvement — moving a policy check into the framework’s own execution graph also means the policy logic becomes coupled to that framework’s versioning and breaking-change cycle.
What stays true regardless of the framework version
The parts of IVE’s architecture that have nothing to do with ADK specifically are unaffected by any of this: identity derived only from a validated Supabase JWT, database access scoped by Row Level Security rather than a shared credential, and success confirmed by reading a record back rather than trusting the model’s own report. None of that is an ADK feature. It would need to exist whether the orchestration layer underneath it were ADK 1.x, ADK 2.0, or a different framework entirely.
Trade-offs of upgrading, stated plainly
Migration is not free
ADK 2.0’s event schema adds new fields (node_info, output, routes, isolationScope) that require a database schema update for any system with custom session storage — not a drop-in upgrade for a production system with real persisted sessions.
Legacy override patterns silently stop working
Custom overrides of legacy execution methods are silently ignored by the new engine per Google’s own documentation — a subtle failure mode where code appears to run but a customization quietly no longer applies.
Framework-level retry is not a substitute for application-level verification
Automatic retry at the orchestration layer answers “did the call complete.” It does not answer “was the result what we intended” — that is still a read-after-write check a team has to build itself, on ADK 2.0 exactly as much as on the version before it.
Practical takeaways for teams currently on classical ADK
1. Compatibility does not mean parity
Your ADK 1.x-style agent will likely keep running on 2.0, but it will not gain graph routing, native retry, or native human-in-the-loop until it is migrated to use them.
2. Audit custom overrides before upgrading
Anything overriding low-level execution methods needs to move to the documented callback hooks, or it will be silently ignored.
3. Budget for a session-schema migration, not just a version bump
If you persist session state yourself, the new event fields are a real schema change, not a transparent upgrade.
4. Keep verification logic outside the framework’s retry story
Whatever the framework auto-catches, still confirm the actual outcome independently — a pattern that holds regardless of which orchestration layer is underneath.
The description of IVE’s own architecture (LlmAgent/Runner/RunConfig, disclosed limitations on retry and session persistence, Human Gate as an external policy check) is drawn directly from IVE’s already-published reference implementation page, not newly disclosed here. ADK 2.0 details are drawn from Google’s official ADK 2.0 documentation and release notes.