The mandate
A tier-one bank should not adopt an agent framework because it is fashionable. The defensible starting point is a measurable backlog that a large language model might shorten. Reconciling trade breaks, preparing suspicious-activity-report drafts for qualified review, answering relationship managers' questions against an authorised document set, or triaging incident tickets in a payments platform. A useful mandate is not “deploy an agent” but “reduce trade-break handling time within an agreed error, escalation and loss budget.” That distinction fixes the engineering brief without promising a result before measurement.
Every architectural choice is judged against controls that predate generative AI. These include model risk management, data residency and audit requirements. The audit question is not only whether the agent was right. A reviewer must be able to reconstruct what it produced, which data it touched and who authorised that access.
This piece is about the runtime and orchestration layer beneath that mandate. Agent Runtime, formerly Vertex AI Agent Engine, is the managed execution environment in Gemini Enterprise Agent Platform. LangGraph is the orchestration graph many enterprise teams use today. The Agent Development Kit (ADK) is a plausible end state once the estate stabilises.
One credible migration path starts with LangGraph because the graph abstraction maps well to explicit process controls. ADK becomes a candidate when bespoke session, memory and tool-registration code creates an estate-wide maintenance burden. The threshold is organisational, not universal, and should be measured rather than assumed. All workload volumes, costs, timelines and operating results below are illustrative planning inputs, not disclosed client results or Google benchmarks.
Why agent runtime, not a hand-rolled runtime
The instinctive move for a strong platform engineering team is to build the runtime itself: a Cloud Run service, gateway, checkpoint store, work queue and audit pipeline. The make-versus-buy worksheet used here is a worked planning scenario. It assumes four to six engineers for three to five months, followed by two engineers for continuing operation. Those figures reflect one internal delivery model, not a Google benchmark or a general staffing rule.
Agent Runtime deploys and scales agents and integrates with Cloud Trace, Cloud Logging and Gen AI evals. Its documented enterprise controls include VPC Service Controls, CMEK and data residency for data at rest. Those properties do not apply uniformly to every adjacent service. Agent Platform Sessions and Agent Platform Memory Bank support the controls at regional and multi-regional endpoints, but global instances cannot use CMEK. Example Store does not currently support VPC Service Controls, CMEK or at-rest data residency.
The economics matter too. The worked worksheet assumes twenty concurrent sessions, four tool calls per turn and a blended cost of $0.02 to $0.09 per completed turn. It also assumes $650,000 to $1.1 million a year for an internal platform team. These are scenario inputs, not current list prices or portable benefits. Replace them with measured tokens, Agent Compute, memory, storage, operations, staffing and support costs from the intended region and traffic profile.
LangGraph as the working substrate
A common regulated pattern uses LangGraph as the orchestration layer and packages it for Agent Runtime. The appeal is specific: LangGraph can model the agent as an explicit state graph rather than an implicit ReAct loop. Every controlled node is a named function, every deterministic edge is readable. The compiled graph gives internal audit a concrete routing artefact rather than a description that “the model decides what to do next.”
Consider a trade break triage agent built for a rates desk. The graph has nodes for intake (parsing a break notification), retrieval (pulling the relevant trade, counterparty. Settlement instruction records), classification (is this a booking error, a settlement timing issue, or a static data mismatch), a human-approval gate for anything above a notional threshold. A resolution node that drafts the correction ticket. Below is the shape of that graph.
The graph structure gives you three things a flat agent loop does not. First, deterministic checkpoints: LangGraph's checkpointer (backed here by a managed Postgres instance, typically AlloyDB, rather than the default in-memory saver) persists the full state after every node. Therefore, a session interrupted by a human review gate can resume days later with complete fidelity, and a validation reviewer can replay any historical session node by node.
Second, conditional routing that is visible in code and in the compiled graph, rather than buried in a system prompt that says "if the amount is large, ask a human first," an instruction the model can silently ignore under context pressure.
Third, clean separation between the reasoning node (where the LLM is called) and the deterministic nodes (threshold checks, data writes), which matters enormously to a model risk reviewer who wants to know exactly which decisions are made by a statistical model and which are made by ordinary code.
The operational discipline that teams new to the framework often skip is treating every LangGraph node as independently testable. Each node needs a unit test that mocks its model call and asserts state transitions, plus an integration test against a sandboxed retrieval index. The worked rates-desk plan uses roughly 340 node-level tests and 60 graph-level tests for a graph of a dozen nodes. That ratio illustrates test shape, not a universal target; risk and branching complexity should determine the local suite.
State, checkpointing and the ledger analogy
A useful mental model for risk and audit stakeholders is that durable checkpointed state can support a ledger-like reconstruction. Every persisted transition needs a timestamp, an actor (which node made the change), and a before-and-after value. Persisting checkpoints to an approved PostgreSQL-compatible store such as AlloyDB avoids the volatility of an in-memory saver. Ledger-like does not mean automatically immutable: append-only history, tamper evidence and retention still need an explicit event or audit design.
In practice this means every checkpoint row carries a session identifier, node name, monotonically increasing step number, serialised state and wall-clock timestamp. A bank deployment should exclude raw personally identifiable information where possible, favouring tokenised references back to the source system of record. The worked sizing case assumes 2,200 sessions a day and nine checkpoints per session, or roughly 20,000 rows daily. Benchmark the operational resume path in AlloyDB and land a governed event projection in BigQuery for retrospective analysis; do not assume an operational checkpoint schema is also an efficient audit warehouse.
The failure mode to design against here is silent state truncation. A team can adopt an in-memory checkpointer in a load-test environment, pass every functional test and still lose in-flight sessions when an instance is recycled. The production-readiness gate should therefore restart or terminate the runtime mid-session and prove deterministic recovery from the approved durable store.
The identity perimeter around the agent
An agent that can query a trade database, draft an email or call an internal reconciliation API is, from a security architecture point of view, a workload identity with a persuasive natural-language front end. Treat it with the same rigour as any other service-to-service integration. Google Cloud workloads should use attached service accounts or managed workload identity mechanisms; external and multicloud workloads should use workload identity federation. Neither path requires a downloaded long-lived service-account key.
The recommended pattern uses a dedicated runtime service account with narrowly scoped IAM bindings. It receives read access only to named BigQuery datasets and AlloyDB resources, plus write access to the audit ledger and approved action tools. Every binding is resource-scoped and checked against an access matrix maintained as code. External workloads exchange their existing identity through workload identity federation rather than downloading service-account keys.
VPC Service Controls encloses the Agent Platform project and supported Google-managed data services. The project must join the perimeter before the agent is deployed; adding it later does not retroactively protect that deployment. VPC Service Controls reduces exfiltration paths for protected services, but it is not a general network firewall. External SaaS calls need an explicit proxy and egress design, and unsupported Agent Platform features need separate treatment.
Where LangGraph runs out of road
LangGraph can be a reasonable choice while the estate is small and explicit graph control outweighs local maintenance. The inflection point arrives when bespoke deployments become a portfolio that a central platform team must govern. Measure that point through duplicated tools, divergent session handling, evaluation effort and control exceptions rather than an arbitrary agent count.
The friction shows up in three specific places. First, tool registration is bespoke per graph: every LangGraph agent defines its own tool schemas. There is no first-class, cross-team registry that lets a fraud-detection agent and a client-service agent share a validated, versioned definition of "look up counterparty KYC status" without copy-pasting code between repositories.
Second, session and memory management, while workable with a custom AlloyDB checkpointer, is something every team re-implements slightly differently: one team stores full conversational history, another stores only structured state. A platform team trying to write one unified data-retention policy across fifteen agents ends up writing fifteen slightly different retention jobs.
Third, and most acutely, evaluation harnesses do not travel between LangGraph graphs cleanly, because the graph structure itself varies agent to agent. There is no shared notion of "agent" that Agent Platform's evaluation service, or an internal red-teaming tool, can point at generically.
None of these are defects in LangGraph. They are the natural consequence of using a general-purpose graph orchestration library, built for flexibility across any Python workload, inside an enterprise that needs standardisation across dozens of workloads for governance reasons. This is precisely the gap ADK is designed to close on Google Cloud.
Adk as the end state
The Agent Development Kit provides graph-oriented, code-first control through standardised primitives: an Agent abstraction, declared tools, session interfaces and a shared evaluation harness. First-party integrations include Agent Platform Sessions and Agent Platform Memory Bank. ADK agents can deploy to Agent Runtime and emit OpenTelemetry-compatible traces into the platform observability path. Deployment simplicity does not remove the need to configure location, identity and service-level controls.
The practical opportunity for a bank is to build a shared registry around typed ADK tool contracts. KYC lookup, trade retrieval and settlement-instruction validation can then be validated and versioned once rather than reimplemented by each agent team. Shared registration does not make one security review permanently portable: every consuming agent still needs its identity scope and journey-specific use approved. ADK's composition primitives also map cleanly onto explicit sequential and parallel workflows, provided routing decisions and approval gates remain observable rather than buried in a system prompt.
A wholesale rewrite of a working LangGraph estate is rarely the lowest-risk move. The worked programme uses a twelve-to-eighteen-month coexistence hypothesis: new candidates are assessed for ADK, existing LangGraph agents move at a major revision, and both frameworks write to the same governed audit schema in BigQuery. That period is a planning assumption to validate against portfolio size and change capacity, not a promised migration duration.
The migration path in practice
A controlled sequence starts by extracting tool definitions into a framework-neutral schema registry. Next, define one session and retention contract while keeping each framework on a supported persistence path. LangGraph checkpoints may remain in AlloyDB, while ADK can use Agent Platform Sessions or an approved custom session service. Normalise both into one audit-event schema rather than pretending their internal state formats are identical. Migrate low-impact, single-path capabilities first, then move multi-agent workflows only after dual-run evidence covers routing, tool use, approvals and recovery.
For a planning scenario of twenty agents, use eight to ten months for contract and telemetry unification, six months for twelve simple capabilities, and six to nine months for eight complex workflows. These ranges are budget hypotheses, not observed benchmarks. Replace them after inventorying code paths, approval gates, benchmarks, vendor dependencies and release windows.
| Migration phase | Scenario duration | Primary risk if rushed |
|---|---|---|
| Tool schema unification | 2-3 months | Divergent access matrices per agent, duplicate security reviews |
| Shared session and retention contract | 2-3 months | Data retention gaps between framework-specific stores |
| Simple agent migration (FAQ, single-tool) | 4-6 months | Evaluation regressions hidden by small sample sizes |
| Complex multi-agent migration | 6-9 months | Loss of tacit business logic embedded in LangGraph conditionals |
Failure modes worth naming
Four failure modes recur often enough to name explicitly. The first is silent checkpoint truncation: an in-memory saver left in place past load testing can drop every in-flight session on restart. The fix is a deployment gate that rejects any non-local environment without an approved durable checkpointer and a tested recovery path.
The second is tool-call privilege creep. A tool originally scoped to "read a single trade record by ID" gets extended, under deadline pressure, to accept a free-text query parameter that is passed through to a broader database view, because a developer needed to unblock a demo. Six months later that tool is being called by three other agents with access patterns nobody reviewed against the original access matrix.
The mitigation is treating every tool definition as a change-controlled artefact with its own owner and its own IAM binding, reviewed independently of the agent that happens to call it, which is precisely the discipline ADK's shared tool registry is designed to enforce.
The third is evaluation drift after a model version upgrade. A prompt tuned against one model version can degrade on the next, particularly around a human-approval gate. The worked rates-desk scenario assumes a six-point decline in notional-threshold detection for eleven days after a version change. A weekly evaluation over 400 labelled breaks finds it. The figures illustrate the control: pin versions where the service permits it, record every dependency change and rerun the frozen set before accepting a new release.
The fourth is human-in-the-loop fatigue. In the worked scenario, routing 40 percent of cases to review against an operating hypothesis of 8 to 12 percent would overwhelm the control and encourage rubber-stamping. Those percentages are not a universal target. Set the local range from loss severity, reviewer capacity and observed precision-recall trade-offs, then revisit it against outcome data.
Worked scenario, a trade break investigation agent
The following figures form an illustrative operating scenario, not a disclosed client result or an Agent Platform benchmark. It assumes a rates operation handling 6,000 trade breaks a month. The modelled manual process averages 55 minutes per break across retrieval, comparison, classification and escalation.
The agent, built on LangGraph and deployed on Agent Runtime, performs retrieval and classification automatically. On intake it parses the break notification, retrieves the trade and authorised counterparty fields, and retrieves the relevant confirmation through a hybrid search path. It classifies the break into one of six modelled categories. Any break above the scenario's $50 million notional ceiling or below its 85 percent classification threshold routes to a human reviewer with source excerpts, tool results, policy checks and the proposed classification: not hidden model chain-of-thought.
In the worked four-month case, average handling time falls from 55 minutes to 21 minutes for the 78 percent of breaks classified above threshold. Escalated cases average 34 minutes because reviewers still receive retrieval and draft classification support.
The scenario assumes 91 percent classification accuracy on escalated cases against the reviewer's final determination. Roughly one in eleven suggestions is therefore wrong. That modeled error supports the escalation gate rather than its removal.
The worksheet assigns $4,100 in monthly agent cost and $310,000 in estimated fully loaded operations savings. Both values are assumptions to replace with local measurements. They demonstrate the business-case calculation; they do not claim a platform return.
Observability and continuous evaluation
None of the preceding architecture is worth much without a way to know whether the agent is still doing what it was validated to do. A defensible observability design has three layers, and a model risk function should expect all three before production approval.
The first layer is turn-level tracing. Every turn emits a structured event record into Cloud Trace and Cloud Logging. The input envelope, retrieved-context identifiers and excerpts, explicit graph transitions, policy results, tool calls and arguments, approvals, final output and component versions. Do not collect or present hidden model chain-of-thought as audit evidence. Export governed events to a partitioned and clustered BigQuery table so an authorised analyst can query which sessions invoked a settlement tool above a defined notional threshold.
The second layer is scheduled evaluation against a frozen benchmark. For the trade break agent, this is the 400 case labelled set referenced earlier, re-run weekly through the Agent Platform Gen AI evaluation service, scoring classification accuracy, groundedness of the retrieved context against the final answer, and instruction following on the escalation threshold specifically. Groundedness scoring matters more than raw accuracy in a banking context, because a classification that happens to be correct but is not traceable to the retrieved trade and confirmation data is not something a reviewer can defend in an audit, even when the answer itself was right.
The third layer is drift monitoring on live traffic, not just the frozen benchmark. This tracks distributional shifts: the proportion of cases escalated to human review, the average confidence score, the average retrieval latency. The token cost per turn, each compared against a trailing thirty day baseline with an alert threshold of roughly two standard deviations.
A sharp jump in escalation rate is usually the earliest signal of either a genuine change in the underlying business (a new product type generating breaks the agent has not seen) or a silent model regression. Distinguishing between the two is exactly the kind of judgement call that should sit with a named owner, not an on-call rotation reading a dashboard for the first time.
An illustrative diagnostic scenario shows the value of this layer. Retrieval latency rises from 340 milliseconds to 1.1 seconds without an accuracy change as the index outgrows its initial shard sizing. A capacity alert triggers investigation and scheduled reindexing. Accuracy-only monitoring would miss both the cost and user-latency effect.
Notes for practitioners
Start with LangGraph when explicit state transitions materially improve review and the team can operate the supporting persistence layer. Use an approved durable checkpoint store from the first non-local deployment. Treat tool definitions as change-controlled artefacts with named owners because privilege creep is a predictable review finding. Enclose supported services with VPC Service Controls, use workload identity federation for external workloads, and use managed Google Cloud workload identities internally. Do not issue long-lived service-account keys to an agent workload.
Plan the migration to ADK as a multi-year attrition programme tied to natural revision points in each agent's lifecycle, not as a discrete project with its own end date. Fund the schema and session-service unification work first because it delivers governance value even before a single agent's orchestration code changes.
Re-run a frozen evaluation set on every model version change before accepting it in production. Treat any regression above roughly 2 to 3 percentage points on a labelled benchmark as a release blocker, the same way a market risk model change would be blocked pending revalidation. Finally, tune human-in-the-loop thresholds as a precision-recall problem with a quarterly review cadence, because a threshold set once at launch and never revisited is the most common reason a well-built agent quietly stops earning its keep.
An architecture review pack
The earlier worked figures describe an illustrative planning context. They are not universal benchmarks. A review committee needs a smaller set of artefacts that survives a change of model, framework or use case. The first is a control-plane map. The second is a migration decision record. The third is an evaluation contract with named owners.
The model must never be the policy decision point. It can propose an action and assemble evidence. A deterministic policy service decides whether the action is permitted. The tool then checks the same decision at execution time. This double check prevents a stale plan from becoming a live transaction.
This map separates four responsibilities. Identity establishes who is asking. Policy establishes what may be done. Orchestration establishes what happens next. The ledger establishes what can later be proved. Combining any two makes review harder. Combining all four inside a prompt makes the design indefensible.
| Review surface | Minimum evidence | Release blocker | Accountable owner |
|---|---|---|---|
| Identity | caller, workload and delegated-user identifiers in every trace | shared or long-lived credential | IAM platform owner |
| Tool authority | versioned schema, allowed operations and resource scope | tool can exceed the approved journey | business service owner |
| State | retention, residency, encryption and replay behaviour | checkpoint cannot be reconstructed | agent platform owner |
| Evaluation | frozen cases, live sentinels and threshold rationale | material regression without disposition | model-risk owner |
| Human control | queue, service level and override record | high-impact path can bypass approval | operations owner |
| Change | model, prompt, graph and tool versions | untraceable production change | release owner |
The table is deliberately technology-neutral. Agent Platform provides useful runtime services, but a managed runtime does not transfer accountability to the cloud provider. The institution still owns the control design, decision thresholds, evidence retention and operator response.
Choosing the migration unit
A framework migration should not be planned by repository. It should be planned by control-bounded capability. A capability includes its graph, tools, benchmark, identity scope, runbook and owner. Moving that unit together avoids a half-migrated state. Such a state can execute in one framework while its evidence still assumes another.
| Capability condition | Recommended move | Why |
|---|---|---|
| Stable, low-impact, single-tool journey | migrate early | exposes packaging and telemetry gaps cheaply |
| High-volume journey with a mature benchmark | dual-run next | produces useful comparison data |
| Multi-agent flow with implicit hand-offs | refactor before migration | translation can hide ownership gaps |
| High-impact action without replayable evidence | do not migrate yet | there is no defensible acceptance test |
| Capability near retirement | leave in place | migration cost has no control return |
Dual-running is an evidence exercise, not a race for identical text. Compare tool selection, policy outcomes, escalation decisions, source use, latency and cost. Exact prose equality is neither expected nor useful. A candidate can differ stylistically and still be equivalent. It cannot silently call a different tool.
Minimum evaluation contract
The release contract should name the population, slices and failure budget before testing begins. Include ordinary cases, boundary cases, denied requests, missing data and tool failure. Report uncertainty when a slice is small. One aggregate accuracy number can conceal a dangerous subgroup. A settlement agent that performs well overall but fails on cross-currency amendments is not ready for that journey.
Retain the input envelope, source identifiers, policy response, tool arguments, tool result, approval event, output and component versions. Avoid presenting hidden model reasoning as audit evidence. Observable actions and cited records are stronger evidence. The trace should prove behaviour without pretending to expose cognition.
Check current product boundaries against Agent Runtime, the Agent Platform release notes, supported locations, VPC Service Controls guidance, the Agent Development Kit and Workload Identity Federation.
For US supervisory context, Federal Reserve SR 26-2 superseded SR 11-7 in April 2026. Its formal definition explicitly excludes generative and agentic AI. The document says institutional governance should determine suitable controls for systems outside its scope; it should not be cited as though it directly governs an agent. The Bank of England's PRA SS1/23 remains a separate jurisdictional reference.
Those sources set boundaries, not a finished design. The review pack is complete only when each boundary is tied to an institutional control and a named decision-maker.