Enterprise Agent Runtime Landscape

Decision this document supports

This document helps a Forward Deployed Engineer, enterprise architect, or platform owner decide which classes of agent runtime should advance to a client-specific comparison and proof of value.

It is a landscape, not a ranking. It does not identify a universal winner. The right shortlist depends on the client's existing cloud and application estate, required deployment boundary, engineering model, interoperability needs, and acceptance criteria.

The landscape is current as of 2026-08-16. Availability changes quickly. Every maturity statement below is tied to a dated source or is recorded as unknown.

Evidence language

The product evidence in this document is first-party unless stated otherwise.

• Vendor-documented means the supplier documents the capability. It is not independent verification.
• Independently anchored means an open specification or standards project defines the interface being discussed. It does not prove that a supplier's implementation is complete or conformant.
• Unknown means the public sources reviewed did not support a reliable claim.

MCP, A2A, and OpenTelemetry provide independent anchors for tool connectivity, agent-to-agent communication, and telemetry vocabulary respectively [R25][R26][R35]. A vendor's statement that it supports one of those interfaces remains vendor-documented until conformance is independently tested.

What counts as an agent runtime

The shared glossary defines an agent runtime as the platform that executes agents: orchestration, tool invocation, state, identity, isolation, and operational surface.

A product is included when public primary documentation shows that it passes criteria 1 and 5. Criteria 2-4 characterize the included platforms; they do not govern inclusion.

1. Managed execution: it hosts or executes the agent loop, not only a library, model API, or development kit.
2. Production lifecycle: it exposes deployment plus an operational surface for versioning, monitoring, tracing, or evaluation.
3. Enterprise boundary: it documents an access-control, identity, workspace, tenant, or customer-hosted boundary.
4. Extensibility: it supports custom tools, code, APIs, models, protocols, or agent logic rather than only a fixed catalog.
5. Available evidence: its managed runtime is publicly documented as available on 2026-08-16 and is not itself documented as deprecated or scheduled for shutdown. Feature-level preview status, and the retirement of individual capabilities within an assessed platform that itself remains supported, are recorded separately rather than treated as exclusions.

Criterion 5 asks whether current managed-runtime availability is documented, not whether a dated GA declaration, exact lifecycle label, or every region and edition is known. CrewAI AMP therefore passes on its current managed-deployment documentation even though its exact lifecycle status and GA date remain unknown [R12]. SAP Joule Studio likewise passes even though its regional and edition scope remains unknown [R23].

The two inclusion criteria demonstrably discriminate in the considered set. Criterion 1 rejects the OpenAI SDK and Responses API track and the development-framework group. Criterion 5 rejects Agent Builder. Criteria 2-4 describe the eleven included platforms. None of these criteria tests whether a platform is suitable for a particular client.

Considered set and method result

The considered set is not an exhaustive market census. It began with the six platforms named at the outset and added candidates that surfaced while researching them. Microsoft Copilot Studio, Amazon Q, Glean Agents, Sierra, and ChatGPT Workspace Agents are documented products that were not assessed in this edition and were not rejected by this method [R30][R31][R32][R33][R34]. Workspace Agents is cited elsewhere in this document as OpenAI's migration target; its launch stage was not confirmed against the first-party pages reviewed.

The method therefore produces eleven included platforms, not the six named in the initial proposal. CrewAI AMP, Databricks, ServiceNow, UiPath, and SAP passed the same threshold and cannot be dropped merely to preserve the initial list.

Two useful runtime categories

The categories describe the platform's center of gravity. They do not imply quality.

Code-first managed runtimes

Amazon Bedrock AgentCore, Microsoft Foundry Agent Service, Gemini Enterprise Agent Platform - Agent Runtime, LangSmith Deployment, CrewAI AMP, and Databricks Agents begin with developer-authored agent logic and provide a managed execution or serving path.

Suite-embedded agent platforms

Salesforce Agentforce, IBM watsonx Orchestrate, ServiceNow AI Agent Studio, UiPath Maestro, and SAP Joule Studio begin inside an enterprise application, automation, or business-process estate. They can be extensible, but their shortest path to value and strongest operational context are inside that estate.

This two-part taxonomy avoids treating every supplier as its own category. It also makes the main architectural choice explicit: start from custom agent code and choose a runtime, or start from a system of work and extend its agent surface.

Landscape at a glance

All cells in this table are vendor-documented, not independently verified.

Platform profiles

Amazon Bedrock AgentCore

Vendor-documented scope. AgentCore is a modular platform whose runtime can host custom agents and tools across multiple frameworks and model providers. AWS documents MCP and A2A support, per-session microVM isolation, long-running execution, persistent filesystems, distinct agent identities, and agent-specific tracing [R01][R02].

Deployment and operations. Runtime offers serverless microVM sessions and, as of the August 2026 notes, managed EC2-backed Instances in the customer's AWS account. The same release notes show that capabilities and quotas continue to change by month and region [R03].

Lock-in and due diligence. Framework and model choice reduce source-level lock-in, but identity, gateway, policy, memory, networking, telemetry, and operational procedures remain AWS services. Validate region parity, session semantics, trace export, fail-open behavior in gateway controls, and recovery before selection.

Evidence strength. Capability and availability claims are vendor-documented. MCP and A2A define portable interfaces independently [R25][R26], but implementation conformance was not independently tested.

Microsoft Foundry Agent Service

Vendor-documented scope. Foundry runs configuration-defined prompt agents or developer-authored hosted agents packaged as a container or source archive. Microsoft documents managed endpoints, autoscaling, dedicated Entra agent identity, session state, custom frameworks, platform tools, tracing, and Application Insights integration [R04][R06].

Deployment and operations. Microsoft's dated readiness table marks core agents GA, while memory, agent guardrails, monitoring, some trace paths, and other adjacent features remain preview or partial GA. A platform-level GA label must not be projected onto every feature [R05].

Lock-in and due diligence. Containerized agent logic can remain portable, while Entra identities, Foundry tools, Responses API behavior, networking, publishing, and project operations create platform coupling. Confirm each required feature's status and region rather than treating "Foundry GA" as blanket readiness.

Evidence strength. Claims are vendor-documented. No independent runtime conformance assessment was identified.

Gemini Enterprise Agent Platform - Agent Runtime

Vendor-documented scope. Google documents a fully managed Python runtime with managed templates for ADK, LangGraph, LangChain, LlamaIndex, and AG2 plus custom templates and A2A support [R08]. Agent Identity is documented as a per-agent SPIFFE identity with certificate-bound credentials and IAM integration. Its 3-legged OAuth user delegation, 2-legged OAuth, and API-key authentication models are marked Preview [R09].

Deployment and operations. The current Gemini Enterprise Agent Platform name replaced the earlier Vertex AI Agent Engine positioning in April 2026. The launch material describes runtime, sandbox, memory, registry, gateway, and observability surfaces [R07].

Lock-in and due diligence. Framework adapters and A2A reduce some code and communication coupling. The Python runtime contract, IAM, Agent Identity, Google observability, memory, registry, and data services remain platform-specific. Confirm launch stage, region, quota, and private-network behavior for every required component.

Evidence strength. Claims are vendor-documented. SPIFFE and A2A provide independently governed interface context, not verification of Google's implementation [R26].

LangSmith Deployment

Vendor-documented scope. LangGraph Platform was announced GA in May 2025 and renamed LangSmith Deployment in October 2025. LangChain documents a stateful Agent Server, persistence, horizontal scaling, cloud, hybrid, and fully self-hosted deployment choices [R10][R11].

Deployment and operations. LangSmith Cloud hosts the control plane, data plane, Agent Server, and supporting databases on AWS or Google Cloud, with serverless and dedicated options. Hybrid and self-hosted options change the operating-responsibility boundary [R10][R11].

Lock-in and due diligence. Self-hosting offers infrastructure placement control, but the runtime contract, persistence model, control plane, observability, evaluation, and enterprise license remain LangChain-specific. Confirm non-LangGraph workload support, upgrade responsibility, disconnected operation, and data-plane egress.

Evidence strength. Claims and GA status are vendor-documented. No independent operational assessment was identified.

CrewAI AMP

Vendor-documented scope. CrewAI AMP deploys, monitors, and scales CrewAI crews and agents on managed infrastructure. It supports GitHub, CLI, and low-code deployment, REST invocation, tools, execution traces, logs, and RBAC [R12][R13].

Deployment and operations. Public documentation establishes current managed-platform availability but did not provide a dated GA declaration in the sources reviewed. Exact lifecycle status and GA date remain unknown; availability is documented rather than inferred [R12].

Lock-in and due diligence. AMP's shortest path assumes CrewAI's crew and agent abstractions. Confirm workload identity, network isolation, regional placement, recovery, telemetry export, platform limits, and exit path using a real deployment.

Evidence strength. Claims are vendor-documented. No independent runtime assessment was identified.

Databricks Agents

Vendor-documented scope. Databricks documents custom agents, supervisor agents, multi-agent systems, MCP tools, scalable query/serving, and an evaluation and monitoring lifecycle [R14]. Production traces can be captured through MLflow [R15].

Deployment and operations. The platform can place agent code in Databricks Apps or serving endpoints and connect it to Unity Catalog assets. The exact status of individual agent, serving, and monitoring features depends on cloud and region and must be checked in the target workspace.

Lock-in and due diligence. This is strongest where the agent's data, functions, models, governance metadata, and operational team already sit in Databricks. Unity Catalog, MLflow, serving endpoints, and Databricks Apps create material platform coupling.

Evidence strength. Claims are vendor-documented. MCP is independently specified [R25], but Databricks implementation conformance was not tested.

Salesforce Agentforce

Vendor-documented scope. Agentforce is a managed agent layer inside the Salesforce platform. Salesforce documents topics and actions that integrate with platform data, Flow, Apex, APIs, and lifecycle tooling [R17].

Deployment and operations. Salesforce announced Agentforce GA on 2024-10-29 [R16]. The Agentforce Session Trace OTel API is Beta; it exports a single-session OpenTelemetry-shaped representation and documents a 72-hour query window for sessions in the Beta release [R18].

Lock-in and due diligence. Agentforce is most direct when Salesforce records, permissions, automations, and channels are the system of work. Those same assets create the dominant lock-in. Confirm behavior for external systems, trace export completeness, data residency, action rollback, and non-Salesforce channels.

Evidence strength. Capabilities and GA are vendor-documented. OpenTelemetry independently anchors telemetry vocabulary [R35], not the completeness of Salesforce traces.

IBM watsonx Orchestrate

Vendor-documented scope. IBM provides an Agent Development Kit and CLI for building and deploying agents and tools into watsonx Orchestrate [R19]. Current release notes demonstrate an active managed product surface [R20].

Deployment and operations. Feature availability changes across the SaaS product, ADK, region, and release. The exact GA state of each agent runtime capability is unknown unless the feature-specific release note says otherwise.

Lock-in and due diligence. The ADK, catalog, connections, tool model, and watsonx operating surface create coupling. Confirm supported hosting boundaries, identity propagation, trace export, model portability, recovery, and version compatibility.

Evidence strength. Claims are vendor-documented. No independent runtime assessment was identified.

ServiceNow AI Agent Studio

Vendor-documented scope. ServiceNow documents a managed studio for creating, testing, activating, and monitoring custom AI agents and agentic workflows inside its platform [R21].

Deployment and operations. Availability follows ServiceNow release families and entitlements. The reviewed source is current for the Australia family; it does not establish universal availability for every tenant.

Lock-in and due diligence. ServiceNow records, roles, workflows, skills, and release lifecycle are the center of gravity. Confirm external-agent hosting, identity propagation beyond ServiceNow, telemetry export, action compensation, and upgrade behavior.

Evidence strength. Claims are vendor-documented. No independent runtime assessment was identified.

UiPath Maestro

Vendor-documented scope. Maestro orchestrates agents, robots, systems, and people across BPMN, flow, and case-management models, with deployment and operational supervision in UiPath's cloud or suite environment [R22].

Deployment and operations. The documentation spans Automation Cloud and Automation Suite. Feature parity and lifecycle status must be established for the client's chosen deployment rather than assumed.

Lock-in and due diligence. UiPath process definitions, Orchestrator, Integration Service, robot estate, and operational model create coupling. Confirm the execution boundary for model-driven agents, identity used for downstream actions, trace granularity, and recovery of long-running processes.

Evidence strength. Claims are vendor-documented. No independent runtime assessment was identified.

SAP Joule Studio

Vendor-documented scope. SAP documents a managed deployment sequence that validates, builds, provisions, and runs Joule Studio projects, registering runtime artifacts with the agent gateway [R23].

Deployment and operations. Public documentation supports a managed runtime claim, while exact regional, edition, and feature availability remain unknown in this review.

Lock-in and due diligence. SAP BTP, Joule, business objects, actions, identity, and landscape transport are the dominant coupling points. Confirm non-SAP tool support, trace export, environment promotion, rollback, and data boundary.

Evidence strength. Claims are vendor-documented. No independent runtime assessment was identified.

Cross-platform synthesis

The first decision is operating center of gravity

Use the code-first group when the client needs custom agent logic, cross-system orchestration, or control over framework and model choices. Start with the suite-embedded group when the consequential workflow already lives in Salesforce, ServiceNow, UiPath, SAP, or IBM's automation estate and the platform's native permission and action model is an advantage.

This is a shortlist rule, not a final selection rule. A subsequent selection process applies weighted criteria to the client's actual constraints.

Deployment boundary matters more than a feature count

The products expose materially different responsibility boundaries:

• fully managed prompt/configuration agents;
• managed custom-code or container agents;
• hybrid control plane with customer-hosted data plane;
• fully self-hosted licensed runtime;
• suite-managed agents executing against native business objects.

A feature matrix that does not distinguish those boundaries will compare unlike systems.

Portability exists in layers

• Source portability: containers, Python code, and supported external frameworks can reduce rewrite effort.
• Tool portability: MCP standardizes a host/client/server protocol for resources, prompts, and tools [R25].
• Agent interoperability: A2A standardizes communication between opaque agent applications and is complementary to MCP [R26].
• Telemetry portability: OpenTelemetry's GenAI semantic conventions provide a common vocabulary, although the current documentation points to a separately evolving repository [R27].
• Operational portability: identity, policy, memory, networking, persistence, evaluation, release, and recovery remain platform-specific even when code and protocols are portable.

Protocol support therefore reduces one lock-in layer; it does not make runtimes interchangeable.

Availability labels must be decomposed

Microsoft's readiness table demonstrates the problem directly: core agents can be GA while memory, monitoring, guardrails, or individual trace paths remain preview [R05]. Apply the same feature-level discipline to every platform. A product-level GA announcement is not evidence that a required component is production-supported in the target region.

Conditions for advancing a platform to selection

Advance a platform only when:

1. its deployment boundary matches the client-approved environment;
2. its required runtime components are available in the target geography and lifecycle stage;
3. a representative agent can authenticate as both itself and, where required, on behalf of a user;
4. downstream tools can be constrained and invoked without ambient credentials;
5. state, memory, traces, and generated artifacts can meet the client's data boundary;
6. traces can reconstruct model, tool, state, policy, and human-intervention steps at the required granularity;
7. the platform exposes a credible rollback, cancellation, and recovery path;
8. the client accepts the identified code, data, protocol, and operating-model lock-in.

Apply the criteria in the companion governance and control frameworks alongside these technical conditions.

Proof-of-value due diligence

The public sources do not establish production fitness for a specific client; the proof of value should collect direct evidence for:

• exact product and feature lifecycle status;
• supported regions, quotas, concurrency, duration, payload, and storage limits;
• tenant, session, process, filesystem, and network isolation;
• private ingress and egress controls;
• agent and delegated-user identity propagation;
• secret storage, rotation, and revocation;
• tool argument authorization and human-intervention points;
• state consistency, idempotency, cancellation, retries, and recovery;
• trace completeness, export format, sampling, and sensitive-content handling;
• model, framework, tool, and protocol compatibility;
• backup, regional recovery, and platform exit;
• complete cost mechanics, which R7 will address.

Record an unknown when a vendor document or test does not answer a question. Do not convert absence of evidence into a positive or negative product claim.

Deliberate exclusions

This document does not contain:

• the weighted matrix or selection recommendation;
• reference architectures (R3);
• agent definition or implementation patterns (R4);
• evaluation design (R5);
• monitoring and incident-response design (R6);
• runtime cost and reliability controls (R7);
• governance operating model, threat taxonomy, policy or assurance checklist (GOV1-GOV3);
• regulatory mapping, compliance reporting, retention obligations, or audit evidence pack (GOV4-GOV6);
• client names, outcomes, testimonials, or case studies.

Technical identity, isolation, tool-permission, secret, egress, and telemetry capabilities appear only to describe the documented runtime surface. Their governance implications are addressed in the companion governance and control frameworks.