Enterprise AI Agent Platforms: How an FDE Should Evaluate the Shortlist

A customer wants an agent to investigate an account, propose a change and update the CRM. Several platforms can produce a convincing demonstration. The selection becomes harder when the customer asks who approved the change, which identity made it, and what happens if the response disappears after the write succeeds.

Those questions should shape the shortlist. An enterprise agent platform can supply useful runtime, integration and governance components. The forward-deployed engineer still has to connect them to the customer's actual workflow and prove the result is operable.

This guide compares five starting points using official documentation checked September 17, 2026. It does not report a hands-on vendor benchmark or numerical product ratings. The pilot below is a proposed acceptance exercise, not a claimed customer result.

Identify what the customer needs to own

There are three related choices: the business application where work happens, the code or configuration that determines agent behavior, and the runtime that operates it. They may come from one vendor or several. Choosing a framework alone does not decide deployment, and buying a runtime does not define the authority of its tools.

An existing platform is a reasonable first candidate because the customer may already know how to administer it. It is not an automatic winner. Use the same workflow and failure cases to compare the options that fit the customer's constraints.

Copilot Studio: inspect the environment and action identity

Copilot Studio is a candidate when the customer wants agent work close to its Microsoft and Power Platform processes. Microsoft's governance documentation covers authentication, knowledge sources, actions, connectors, HTTP requests and publication channels through data policies. It also describes tools using user credentials. Copilot Studio security and governance.

The practical question is which identity the proposed workflow uses at each step. A user can authenticate to a chat while a downstream action executes through a different connection. Write down that distinction, then test an employee who can view a record but cannot modify it.

Include the environment administrator in the pilot. Confirm that a connector allowed in the development environment is permitted in production, that the intended publishing channel is allowed, and that the support team can inspect a failed action. Do not infer that a certification or an existing Microsoft contract covers every configured data flow.

This option is most useful to investigate when the business team and platform administrators can jointly own the workflow. The FDE should leave behind a tested deployment path and an owner for connection failures, rather than a demo that depends on its maker's personal account.

Agentforce: connect reasoning to explicit business actions

Salesforce's current guide describes Agentforce Script combining deterministic control with model reasoning. It treats actions, instructions and the context available to the agent as separate design elements. This is a useful starting point for work already represented by Salesforce records and business processes. Agentforce implementation guide.

For the pilot, choose one narrow action such as proposing a case classification. Define the required record, permitted values, eligibility conditions and approval behavior before writing the agent instructions. Inspect what happens when the customer record changes between investigation and execution.

A reasoning engine selecting an action does not establish that the action is appropriate for this customer or authorized by this user. Verify the action's configured execution context and the underlying application's rules. Use the business system's durable record as evidence of completion. The agent's message saying “done” is not enough.

Also separate the data needed for this one workflow from a broader data-platform program. Ask which products, permissions and commercial entitlements the proposed implementation actually requires. A small pilot should make those dependencies visible before they become a production commitment.

LangSmith Deployment: choose the hosting responsibility deliberately

Current LangChain documentation calls the production runtime LangSmith Deployment. It supports agent workloads such as stateful runs, streaming and human review. LangGraph is one of the frameworks that can use it. The documentation distinguishes managed Cloud, standalone Agent Server and a self-hosted platform. These differ in who operates the control plane, runtime and supporting stores. LangSmith Deployment.

That distinction matters more than a generic “supports self-hosting” checkbox. In a standalone deployment, for example, the team must account for its own runtime infrastructure and supporting services. In a managed deployment, it must still understand where application data and traces go, how authentication is configured and what is covered by the service agreement.

Bring the customer's engineering and operations owners into the choice. Demonstrate a run that pauses for review, an interrupted run, a deployment update and a rollback. Explain which state is preserved and how a changed application handles older stored state.

This is a candidate when the team wants to own custom agent behavior and can maintain that code. A managed orchestration service reduces infrastructure work. It does not remove the need for application authorization, evaluation or a migration strategy.

AgentCore Runtime: session isolation still needs application ownership

Amazon Bedrock AgentCore Runtime hosts custom agent and tool code. AWS documents support for different frameworks and model providers, together with identity and observability capabilities. This row evaluates the runtime, rather than treating every service under the Bedrock name as the same product. AgentCore Runtime.

One particularly useful implementation detail is in the session documentation: AgentCore does not enforce the mapping between a user and a session ID. The application's backend must maintain that relationship. Default compute state is also ephemeral. Longer-lived storage must be designed explicitly. AgentCore sessions.

Test those boundaries directly. A user must not gain another user's context by submitting its session identifier. An approved business change must not depend on a temporary filesystem surviving indefinitely. Separate conversational state from the durable record of approval and execution.

For an AWS-oriented customer, this runtime may fit existing operational skills. The FDE should still map inbound identity, outbound credentials, session ownership and business-record permissions separately. Isolation between compute environments does not authorize every operation performed within one of them.

Google's Agent Runtime: verify the contract your application will deploy against

Google's current documentation places Agent Runtime within Gemini Enterprise Agent Platform. It describes managed deployment, configuration of authentication and IAM, and support for different languages and frameworks when the application conforms to the runtime contract. Framework-specific integrations provide different levels of assistance. Agent Runtime overview.

The deployment documentation lists several routes, including source files, a Dockerfile and a container image. Choose the route that the customer's build and release process can reproduce. Record the runtime contract, dependencies, region, application identity and permissions to each downstream resource. Deploy an agent.

The useful test is a clean deployment from a versioned artifact, followed by a request from an authorized user and a rejection for an unauthorized one. Then remove access to a required data source and inspect the resulting failure. A working local SDK call does not prove that the deployed identity has the right access.

This is a candidate for teams whose applications and operational ownership already sit in Google Cloud. Evaluate the actual service configuration rather than assuming that every feature shown in a platform overview is available in the selected region or agreement.

Give every finalist the same acceptance exercise

Use synthetic customer records and a reversible test action. The agent reads a record, cites the relevant policy, proposes one classification change and waits for approval. The executor checks the current record version before applying that exact change.

Keep the task fixed across candidates. Otherwise, a richer demo can look better simply because it uses easier data or grants broader permissions.

The table specifies what to demonstrate. It does not claim that any of the platforms passes by default. If a feature requires extra implementation, count that work in the comparison.

Compare the work left for the customer

Score the finalists against the customer's written requirements, not against a universal star rating. Distinguish a documented capability, a demonstrated result and an unresolved requirement. A vendor statement belongs in the first column until the pilot or contractual review establishes more.

Estimate costs from the same workload: model calls, tool calls, runtime duration, storage, tracing, retries and human review. Include implementation and ongoing operations. Record which prices are contractual, which are usage estimates and which remain unknown. Funding announcements and customer counts do not answer these questions.

The handoff should include a versioned application, data-flow and identity diagrams, evaluation cases, results, release instructions, rollback steps, alert ownership and an incident runbook. Name the person who can disable a failing action without waiting for the original builder.

My recommendation is to begin with the customer's existing operating environment, shortlist the options that meet its non-negotiable requirements, and run the narrow pilot before expanding scope. Select the platform whose failure behavior the customer can understand and operate, alongside its successful behavior.

Continue with the FDE playbook, knowledge-management pilot and document-processing guide to connect the runtime decision to the rest of the implementation.

Related Guides

• Build a Small RAG Pipeline and Measure What It Misses
• Three Prompt Contracts You Can Check with Evaluation Fixtures
• RL Environments for Coding Agents: Five Projects and How to Compare Them