Google Vertex AI Agents Provide Managed Agent Infrastructure. The Agents Have No Canonical Schema.

Vendor and Product Reality

Vertex AI Agent Builder is the no-code and low-code surface: an operator describes an agent in natural language, attaches grounding sources (Vertex AI Search indexes, Google Search, custom data stores via the Discovery Engine API), wires up tools (OpenAPI specifications, Cloud Functions, first-party connectors), and deploys to a managed endpoint. Agent Engine is the runtime substrate that hosts the resulting agents at scale, handling session state, scaling, and integration with the rest of GCP. The Agent Development Kit (ADK) is the open-source Python framework that exposes the same primitives — agents, tools, sessions, callbacks — to developers building agents in code, with first-class deployment paths to Agent Engine, Cloud Run, and GKE. Gemini 1.5 and 2.x models provide the underlying reasoning, with grounding orchestrated by Vertex's retrieval surface.

The platform is genuinely strong on the dimensions Google has chosen to invest in: hosting reliability, regional availability, integration with BigQuery and the rest of the GCP data plane, identity and access management through Cloud IAM, observability via Cloud Logging and Cloud Trace, and a continuously expanding catalog of grounding sources and tool integrations. For an enterprise that has standardized on GCP and wants a hosted agent runtime, the offering is at parity with or ahead of comparable AWS Bedrock Agents and Azure AI Foundry Agent Service offerings. The architectural gap this article identifies is not a deficiency of Vertex against its peers. It is a deficiency the entire current generation of cloud-hosted agent platforms shares.

Architectural Gap

On Vertex, an agent's rules and identity live in two places, both server-side and both external to the agent object itself. Identity is a Google Cloud IAM principal — a service account with attached roles, granted permissions to call models, read grounding sources, invoke tools, and write logs. Behavioral rules are split across the Agent Builder configuration (system prompts, tool allowlists, grounding bindings), Vertex AI policies (model access, safety filters, region constraints), and the surrounding GCP project's organization policies (network egress, data residency, encryption keys). Memory, when it exists, is session state held in Agent Engine's managed store, scoped to a conversation and a project, with no agent-level schema describing what may be written, by whom, with what retention, and under what governance.

Each of these is a sound piece of cloud engineering taken on its own. Together, they leave the agent object itself empty. There is no portable artifact that says: "this is the agent, here is its identity credential, here is its declared capability set, here are its governance constraints, here is the schema of its memory, here is the lineage of how it was constructed and modified." The agent is the runtime behavior of the configuration. Move the configuration to a different project, a different cloud, or a different runtime, and the identity changes (it is now a different IAM principal), the governance changes (it is now under a different organization's policies), and the memory cannot be carried because there is no schema defining what part of the session state is the agent's memory versus the runtime's bookkeeping.

Three operational consequences follow. First, agent portability is impossible in any meaningful sense; "exporting" an agent yields a configuration blob that must be re-bound to a new identity and new policies in any new home, with no guarantee that the resulting agent is the same agent. Second, audit and compliance are bound to the runtime, not to the agent; the question "what governance applied to this agent at this moment" is answered by reconstructing IAM, Vertex policy, and organization policy state from logs, rather than by reading a field on the agent itself. Third, multi-platform agent interoperability is structurally blocked; Vertex agents, Bedrock agents, Foundry agents, and open-source agents have no common typed surface to exchange, because none of them treat the agent as an object with a canonical schema in the first place.

What the Agent-Schema Primitive Provides

The agent-schema primitive defines the agent as a typed object. Each agent carries, as fields of the object itself, a verifiable identity credential (independent of any single cloud's IAM), a declared capability surface (the tools it may call, the data sources it may ground against, the actions it may take), a governance contract (policies that travel with the agent and bind any runtime that hosts it), a memory schema (typed fields for short-term context, long-term knowledge, and operational state, with lineage on every mutation), an execution-state schema (what the agent is currently doing, what it has committed to, what it owes), and a lineage record (how the agent was constructed, by whom, from what prior agents, under what governance approvals).

These are not implementation details a runtime may or may not honor. They are fields of the canonical object, and a runtime that hosts the agent is required to validate them, enforce them, and record their evolution. An agent moved between runtimes carries the same identity credential, the same governance contract, and the same memory schema. The runtime changes; the agent does not. Audit becomes trivial: the question "what governance applied to this agent at this moment" is answered by reading the governance field of the agent at that timestamp, with the lineage record providing the chain back to whoever authorized that governance.

Crucially, the primitive does not prescribe a runtime, a model, or a tool ecosystem. Vertex's Gemini reasoning, Vertex AI Search grounding, and Agent Engine hosting are entirely compatible. What the primitive prescribes is the shape of the object the runtime hosts.

Composition Pathway with Vertex

Composition is additive at every layer of the Vertex stack. Agent Builder's natural-language and form-based agent description becomes a UI for editing fields of a canonical agent object, with the existing tool, grounding, and prompt configurations mapping directly to declared capability and grounding fields. Agent Engine becomes a runtime that validates the canonical agent on ingest, enforces its governance contract during execution, and writes lineage records on every state-affecting operation. The ADK gains a typed Agent class whose fields are the canonical schema, with the existing Python-developer ergonomics preserved. Cloud IAM continues to provide runtime-level identity for the GCP-side service account that hosts the agent, while the agent's own identity credential — the one that travels — is carried in the agent object itself and verifiable independently of any cloud.

The compliance and audit story improves immediately. A regulated enterprise running Vertex agents under HIPAA, GDPR, SOC 2, or sector-specific frameworks can answer governance questions by reading the agent object, with the runtime's lineage record providing the chain of custody. Inter-cloud and on-premise agent deployment becomes coherent: an agent defined under the schema runs on Vertex today, on Bedrock or Foundry tomorrow, and on a private Kubernetes cluster the day after, with the same identity, the same governance, and the same memory contract. Multi-agent systems gain a common typed surface for delegation, with one agent able to verify another agent's credentials and capability declarations rather than relying on out-of-band trust.

For Google specifically, the composition is the answer to the platform-lock-in concern that enterprise buyers raise about every hosted agent service. Adopting the schema converts Vertex from "a place where your agents live, configured against our APIs" into "the best place to run agents that you actually own, defined by a schema that makes them portable." The runtime quality, the Gemini reasoning, the Google Search grounding, and the GCP integration become the reasons enterprises choose Vertex, rather than the reasons they cannot leave it.

Commercial and Licensing Posture

The agent-schema primitive is the architectural element that converts the current generation of cloud-hosted agent services — Vertex AI Agent Builder, AWS Bedrock Agents, Azure AI Foundry Agent Service, and the rapidly multiplying open-source frameworks — from configurations of a hosting platform into instantiations of a canonical object. Google's commercial position benefits in two distinct ways from licensing the primitive into the Vertex stack. First, Vertex becomes the reference implementation of canonical-agent hosting on a major cloud, which is the credibility position for the enterprise buyers who currently treat hosted agent services as procurement risk. Second, the schema's portability properties remove the lock-in objection that gates large-account adoption, converting it into a quality-of-runtime competition that Google's Gemini-and-Search combination is well positioned to win.

For enterprise customers, the commercial proposition is an agent estate that they actually own — auditable, portable, governable as objects rather than as runtime side-effects — running on the cloud whose runtime quality they prefer. For Google, the proposition is the agent-platform layer that survives the next cycle of cloud-and-model competition, in which agents are the unit of enterprise AI and the question of who defines the agent object is the question of who anchors the next decade of the stack.