What is an AI agent platform?

An AI agent platform is the software layer where agents are built, deployed, governed, and run. It owns the agent loop, handles credentials and permissions, stores durable state, connects to systems of record, and keeps an audit trail of what the agent did. Judge one by what survives after a run ends rather than by how well it demos. Major takes that further: its agents build deterministic apps for the repeatable parts of a job and then run those apps, so the surviving artifact is working software with its own database and audit trail, not a transcript.

Is Gemini Enterprise Agent Platform the same as Vertex AI?

It is Google's renamed and expanded evolution of Vertex AI, announced 22 April 2026. Google uses "formerly Vertex AI" on the product page itself and has said Vertex AI services and roadmap work now arrive through Agent Platform. It adds agent integration, DevOps, orchestration, and security features across four pillars: Build, Scale, Govern, and Optimize. It is a build-and-run surface for agents that reason each time they execute, which is the design choice that separates it from Major, where the agent writes an app once and the app handles the repeatable work from then on.

What is the difference between an agent platform and an agent framework?

A framework decides what the agent does next, and a platform supplies everything around it. Frameworks give you reasoning loops, state transitions, and handoffs, then leave hosting, credentials, durable business data, access control, and audit to you. A platform supplies runtime, triggers, persistent state, permissions, integrations, and activity records. Every framework needs a platform beneath it. Major sits at the platform layer and adds an app layer under that, because work an agent turns into code stops depending on the reasoning loop entirely.

What should I look for in an agent platform?

Start with where state lives after a run ends: ask where the output exists thirty days later and who can query it. Then check how credentials are scoped, and whether an action produces an attributable audit record rather than only a trace. After that, ask who owns the agent loop, which steps run as code instead of reasoning, who is responsible for hosting, how you debug a failed past run, and what exports if you leave. That last set is where Major is opinionated: repeatable steps become deterministic apps, credentials are scoped through a proxy, and every action is logged where it happens.

Do I need an agent platform, or can I build on a framework?

Build on a framework when one engineer owns the work, the credentials reach low-stakes systems, and nobody will audit it. You take on hosting, permissions, durable state, and audit yourself, which is a fair trade at small scale. Adopt a platform once several people depend on the output, the agent touches systems of record, or someone will ask who authorized a given action. Major is built for that second case and is more platform than a single-owner side project needs.

How much does it cost to run agents on an agent platform?

Cost tracks how much reasoning the agent does, because tokens are spent every time a model works through a task. An agent that re-reasons the same workflow on every run pays for it on every run, so the bill climbs with usage rather than flattening. Platforms differ in what else they meter: seats, runs, hosting, and storage. Major's approach is structural, moving repeatable work into apps that execute as code, so spend is front-loaded into building the app and then stays flat as the app runs.

Agent Platform: What It Means Now That Google Owns the Term

Google renamed Vertex AI to Gemini Enterprise Agent Platform and now owns most of this search result. That makes "agent platform" a product name and a category at once. Here is the neutral definition, the criteria that decide the choice, and where each camp fits.

Jason BaoAugust 19, 2026Updated August 31, 2026

What an enterprise AI agent platform provides

Key takeaways

An agent platform is the layer that runs agents in production: the agent loop, credentials, durable state, system integrations, and audit records.
Google renamed Vertex AI to Gemini Enterprise Agent Platform on 22 April 2026, so the phrase is now a category label and one vendor's product name at the same time.
Vendor definitions of the category differ, and each one tends to be shaped like that vendor's own feature list. Define the term before you compare anything.
The criterion that actually separates the camps is where state and permissions live after a run ends.
A framework decides the agent's next action. A platform decides what is left over when the agent stops.

The short answer: what an agent platform is

An agent platform is the software layer where AI agents are built, deployed, governed, and run, covering the agent loop, credential handling, durable state, integrations with systems of record, and the audit trail of what the agent did.

That definition is deliberately vendor-independent, because the term is contested. Gartner's research, as OneReach quotes it, describes an agent platform as "a cohesive set of integrated technologies designed to facilitate the creation, integration, deployment, optimization..." of agents. We have not read the primary Gartner document, so treat that wording as OneReach's citation rather than an independent source. Google describes the category as four pillars of its own product. Every vendor page you will read on this topic defines the category as the set of things that vendor happens to ship. Fix your own definition first, then hold each product against it.

If you want the portable version to paste into a doc or a ticket:

Agent platform: the software layer where AI agents are built, deployed,
governed, and run. It owns the agent loop, credentials, durable state,
integrations, and audit. Judge one by what survives after a run ends.

Why "agent platform" now names a product too

On 22 April 2026, Google announced Gemini Enterprise Agent Platform. Its own framing is direct: the product is "the evolution of Vertex AI, bringing the model selection, model building, and agent building capabilities that customers love, together with new features for agent integration, DevOps, orchestration, and security." Google's product page carries "formerly Vertex AI" in the title, and Google has said that Vertex AI services and roadmap work now arrive through Agent Platform rather than as a standalone service.

The product is organized around four pillars. Build covers Agent Studio, the Agent Development Kit, Agent Garden, and Model Garden, which Google says provides first-class access to more than 200 models including Gemini 3.1 Pro and third-party models such as Anthropic's Claude family. Scale covers Agent Runtime, Agent Sandbox, Memory Bank, Agent Sessions, and agent-to-agent orchestration. Govern covers Agent Identity, Agent Registry, Agent Gateway, Model Armor, and Security Command Center integration. Optimize covers Agent Simulation, Agent Evaluation, Agent Observability, and Agent Optimizer. The component names come from Google's own Agent Platform documentation.

That is a real platform with real breadth, and the naming has a practical consequence for anyone searching this term. Half the people typing "agent platform" now want Google's product page. The other half want to know what the category requires. Those are different questions, and a vendor announcement cannot answer the second one honestly, because the answer would be its own feature list.

What an agent platform does, and how it differs from a framework

A framework decides what the agent does next. It gives you abstractions for reasoning steps, state transitions, handoffs, or graph workflows. LangGraph, CrewAI, the OpenAI Agents SDK, and Microsoft Agent Framework all live here. What they generally leave to you: hosting, scoped credentials, durable business data, access control, and the audit record. If you want a deeper map of that layer, we cover the framework layer separately.

A platform wraps execution infrastructure around that loop. Runtime, triggers and scheduling, persistent state, permissions, connections to your systems, and a record of every action. Every framework needs a platform underneath it. The buying decision is whether your team builds that layer or adopts one.

An agent builder is a third thing, usually a visual or natural-language design surface. A builder without durable runtime state, deployment, permissions, and audit produces a convincing prototype and not much else. If you are shopping at that layer, choosing an agent builder is the closer comparison.

The test that cuts through all three labels is what remains after execution. Checkpointing and session memory preserve reasoning context. That is not the same as preserving the business object the work was about.

The criteria that decide the choice

Seven questions separate the options, and the two that predict production survival are where state lives after a run ends and whether an action leaves an attributable record. Work through them in order against any shortlist.

Who owns the agent loop

Can your team read and modify the control flow, or does the platform infer it from a prompt? Inferred control flow demos well and is hard to change deliberately.

Where state lives after the run ends

Ask where the output of a run exists thirty days later, who can query it, and whether it amounts to more than chat history. This is the single most predictive question on the list.

Diagram of an agent platform run: a task arrives, the agent reasons a plan, repeatable steps become a deterministic app with its own database, permissions and audit log that produces an attributable record, while judgment steps leave only a trace that ends with the session.

Credentials, permissions, and audit

Ask for evidence that an action ran under a scoped identity and produced an attributable record. Tracing is not audit. A trace tells you the model called a tool. An audit record tells you which identity changed which row, and who authorized it. What enterprise-grade actually means goes further into that gap.

What the model does versus what runs as code

Map which steps invoke the model on every execution and which run deterministically. Steps the model repeats cost tokens every time and vary every time. Steps that run as code do neither.

Deployment and hosting reality

Establish which infrastructure you operate and which the vendor operates. Self-hosting a framework is a real staffing decision, not a checkbox.

Observability and debugging

Take a run from last month that went wrong. Can you explain why, reproduce it, and fix the cause? Replaying a conversation is not the same as reproducing a failure. Agent observability covers what that requires in practice.

What you own if you leave

Export an agent and look at what you get. Code and data travel. Proprietary flow definitions and engine-specific workflow files do not.

Is an agent platform the same as an LLM gateway or an orchestration layer?

No, and the distinction decides how much you still have to build. An LLM gateway sits in front of the models. It routes requests, caps spend, and logs the prompts and completions that pass through it, which is genuine control over model traffic and no control at all over what the agent then does in Salesforce or Postgres. An orchestration layer coordinates the calls, deciding which model or step runs next. Both sit above the work rather than holding it.

An agent platform is the layer that owns the action and its consequences: the credential the agent acts under, the record it writes, the state it leaves behind, and the audit entry attributable to it. If you already run a gateway and an orchestrator, you have cost control and routing, and you still need somewhere the agent's output lives after the run. The same gap appears when you scale to several agents at once, because coordinating multi-agent AI multiplies the reasoning without giving any of it a durable home.

The camps, and where each fits

Five camps compete for this work, and they answer the state and governance questions differently enough that the right one is usually decided by your workflow rather than by feature count. The table below maps each camp against the criteria above.

Agents that build governed apps (Major) · Who owns the agent loop: You and the agent, in code the agent writes and you can read · Where state lives after the run: In the app the agent built: managed database, file storage, and logs · Governance model: Structural. Scoped credentials and role-based access apply where the agent acts, and the work itself is inspectable code · Best fit: Repeatable internal work that multiple people depend on and auditors will ask about
Hyperscaler agent platforms (Google Gemini Enterprise Agent Platform, and equivalents from AWS and Microsoft) · Who owns the agent loop: The platform runtime, with SDK-level control through ADK · Where state lives after the run: Managed memory and session stores such as Memory Bank and Agent Sessions · Governance model: Platform-native identity, registry, gateway, and model-level policy controls · Best fit: Teams already standardized on the cloud, and anyone who needs model access, training, and MLOps at hyperscaler breadth
Developer frameworks (LangGraph, CrewAI, OpenAI Agents SDK, Microsoft Agent Framework) · Who owns the agent loop: You, explicitly, in graph or role abstractions · Where state lives after the run: Checkpoints and session state, plus whatever database you wire up yourself · Governance model: Whatever you build. The framework supplies tracing, rarely audit · Best fit: Engineering teams who want maximum control over transitions and are staffed to run the platform layer
Enterprise CX and conversational platforms (Sierra, Cognigy, Rasa, Agentforce, Copilot Studio) · Who owns the agent loop: The platform, modeled as dialogue turns · Where state lives after the run: Conversation state and CRM records in the surrounding suite · Governance model: Mature enterprise controls, scoped to the conversational and contact-center context · Best fit: Customer-facing service work across voice and chat
Automation tools used for agent work (n8n, Zapier, Make) · Who owns the agent loop: The workflow engine, with the model handling one decision step · Where state lives after the run: Run history and whatever external systems the workflow writes to · Governance model: Connector-level credentials, workflow-level logs · Best fit: Integration plumbing where the process is mostly known in advance

Two honest notes on that table. Google's platform covers model selection, model building, and MLOps at a scale Major does not attempt, and if your requirement is training and serving models alongside agents, that breadth is the reason to be there. And the camps are not mutually exclusive. Plenty of teams run a framework inside a platform, or a hyperscaler for models and something else for the work.

How to choose: a decision sequence

Six steps take a shortlist from six candidates to two, and steps four and five are where most of the elimination happens. Run them against a real workflow rather than a feature matrix.

Write down the workflow: trigger, the operations in order, the systems it touches, and how it fails.
Name the deliverable. Customer dialogue and internal organizational work pull toward different camps.
Mark every step that should behave identically each time. Those are candidates for code, not for reasoning.
Run the thirty-day state test. Where does the output live next month, and can a colleague pick the work up from it?
Demand one real controlled action in a demo: an attributable identity, a readable audit record, a scoped credential.
Estimate operating volume and exit cost together. Export an agent and see what is portable.

Steps four and five are where most shortlists collapse from six options to two. The orchestration layer matters less than either of them.

The Major take

Every platform in the sections above governs the agent. They wrap permissions, logging, and policy around a model that re-reasons the same task on every run. Google's Govern pillar is a genuinely strong version of this: Agent Identity, Agent Registry, Agent Gateway, Model Armor. But look at what you end up holding. You get an audit trail of a black box. You can see that the agent acted, when, and under which identity, and you still cannot inspect the logic it used, because the logic was regenerated on the fly and then discarded.

Major starts from a different move. When an agent works out how to handle a repeatable part of a task, it builds an app for that part. The app is code, with its own managed database, its own file storage, and its own logs. From then on the agent runs the app rather than reasoning through the step again. So the thing you audit is software you can read, version, and test, not a transcript of a decision that no longer exists. Second, scoped credentials and role-based access apply at the point where the agent acts, through the credential proxy, which is why we describe governance here as structural rather than promised. That is control at the point of action, and it holds whether or not anyone remembers to review the logs.

This does not remove reasoning from the picture. Ambiguous work still needs a model, and the app layer is more machinery than an occasional one-person experiment justifies. Major is also not a hyperscaler: there is no model garden and no training stack here. The distinction worth carrying out of this article is narrower than any of that. Most platforms let you govern an agent. The harder question is whether you can govern the software the agent leaves behind. Reason once, run forever.

If the workflow you sketched in step one has steps that should run the same way every time, that is the part to move out of the model first. Describe it on Major and watch the agent build the app that runs it, with the database, permissions, and logs already attached. Get started on Major and build your first governed agent app.

Frequently asked questions

What is an AI agent platform?: An AI agent platform is the software layer where agents are built, deployed, governed, and run. It owns the agent loop, handles credentials and permissions, stores durable state, connects to systems of record, and keeps an audit trail of what the agent did. Judge one by what survives after a run ends rather than by how well it demos. Major takes that further: its agents build deterministic apps for the repeatable parts of a job and then run those apps, so the surviving artifact is working software with its own database and audit trail, not a transcript.
Is Gemini Enterprise Agent Platform the same as Vertex AI?: It is Google's renamed and expanded evolution of Vertex AI, announced 22 April 2026. Google uses "formerly Vertex AI" on the product page itself and has said Vertex AI services and roadmap work now arrive through Agent Platform. It adds agent integration, DevOps, orchestration, and security features across four pillars: Build, Scale, Govern, and Optimize. It is a build-and-run surface for agents that reason each time they execute, which is the design choice that separates it from Major, where the agent writes an app once and the app handles the repeatable work from then on.
What is the difference between an agent platform and an agent framework?: A framework decides what the agent does next, and a platform supplies everything around it. Frameworks give you reasoning loops, state transitions, and handoffs, then leave hosting, credentials, durable business data, access control, and audit to you. A platform supplies runtime, triggers, persistent state, permissions, integrations, and activity records. Every framework needs a platform beneath it. Major sits at the platform layer and adds an app layer under that, because work an agent turns into code stops depending on the reasoning loop entirely.
Is an agent platform the same as an LLM gateway?: No. An LLM gateway sits in front of the models, routing requests, capping spend, and logging prompts and completions. That is control over model traffic, and it stops at the moment the agent acts on a business system. An agent platform owns the action itself: the scoped credential the agent runs under, the record it writes, and the audit entry attributable to it. Teams often run both. On Major the gap closes differently, because the repeatable work becomes an app whose database and logs are the durable record.
What should I look for in an agent platform?: Start with where state lives after a run ends: ask where the output exists thirty days later and who can query it. Then check how credentials are scoped, and whether an action produces an attributable audit record rather than only a trace. After that, ask who owns the agent loop, which steps run as code instead of reasoning, who is responsible for hosting, how you debug a failed past run, and what exports if you leave. That last set is where Major is opinionated: repeatable steps become deterministic apps, credentials are scoped through a proxy, and every action is logged where it happens.
Do I need an agent platform, or can I build on a framework?: Build on a framework when one engineer owns the work, the credentials reach low-stakes systems, and nobody will audit it. You take on hosting, permissions, durable state, and audit yourself, which is a fair trade at small scale. Adopt a platform once several people depend on the output, the agent touches systems of record, or someone will ask who authorized a given action. Major is built for that second case and is more platform than a single-owner side project needs.
How much does it cost to run agents on an agent platform?: Cost tracks how much reasoning the agent does, because tokens are spent every time a model works through a task. An agent that re-reasons the same workflow on every run pays for it on every run, so the bill climbs with usage rather than flattening. Platforms differ in what else they meter: seats, runs, hosting, and storage. Major's approach is structural, moving repeatable work into apps that execute as code, so spend is front-loaded into building the app and then stays flat as the app runs.