Enterprise AI Agent Platforms: An FDE's Shortlist Test

A customer wants an agent that looks into an account, suggests a change, and updates the CRM. Plenty of platforms can show a good demo of that.

The hard part comes later, when the customer asks three questions. Who approved the change? Which account actually made it? And what happens if the update went through but the confirmation never came back?

Those questions should decide your shortlist. A platform can hand you useful pieces: somewhere to run the agent, ways to connect it to other systems, and controls over what it's allowed to do. The forward-deployed engineer still has to wire those pieces into how the customer actually works, and prove the customer's team can keep it running.

This guide compares five starting points using official documentation checked on September 17, 2026. Nobody ran a hands-on benchmark of these vendors for it, and there are no star ratings. The pilot at the end is a test you can propose to a customer, not a result from one.

Identify what the customer needs to own

There are really three choices here, and they're easy to blur together:

• The business app where the work happens, like Salesforce or Microsoft 365.
• The code or settings that decide how the agent behaves.
• The service that runs the agent day to day.

One vendor might supply all three, or you might mix several. Picking a framework doesn't decide where the agent runs. Paying for a place to run it doesn't decide what its tools are allowed to do.

The platform a customer already uses is a fair first pick, because their admins already know how to run it. It doesn't win by default, though. Give every option that fits the customer's limits the same workflow and the same failure cases.

Copilot Studio: inspect the environment and action identity

Copilot Studio makes sense when the customer wants the agent close to its Microsoft and Power Platform work. Microsoft's governance docs explain how data policies control sign-in, knowledge sources, actions, connectors, web requests, and where an agent can be published. They also cover tools that run with the user's own credentials. See Copilot Studio security and governance.

The question to ask is which account does each step. A person can sign in to the chat while the action behind it runs through a different connection. Write that down. Then test it with an employee who can view a record but isn't allowed to edit it.

Bring the environment admin into the pilot. Check three things:

• A connector allowed in the test environment is also allowed in production.
• The channel you plan to publish to is allowed.
• The support team can see what went wrong when an action fails.

Don't assume a certification or an existing Microsoft contract covers every data flow you set up.

This option is worth a look when the business team and the platform admins can own the workflow together. When the forward-deployed engineer leaves, there should be a tested way to deploy it and a named person who handles broken connections. Not a demo that only works from its builder's personal account.

Agentforce: connect reasoning to explicit business actions

Salesforce's current guide describes Agentforce Script as mixing fixed rules with model reasoning. It treats actions, instructions, and the information the agent can see as separate things to design. That's a good fit for work that already lives in Salesforce records and processes. See the Agentforce implementation guide.

For the pilot, pick one narrow action, like suggesting a category for a support case. Before you write any agent instructions, pin down:

• which record it needs,
• which values it's allowed to pick,
• when the action is allowed at all, and
• how approval works.

Then change the customer record between the moment the agent looks at it and the moment it acts. See what happens.

The agent picking an action doesn't mean the action is right for this customer, or that this user is allowed to take it. Check what permissions the action runs with, and the rules in the underlying app. For proof the work is done, use the saved record in the business system. The agent saying "done" isn't enough.

Keep this one workflow separate from any bigger data project. Ask which products, permissions and paid licenses this pilot actually needs. A small pilot should surface those before anyone signs up for them in production.

LangSmith Deployment: choose the hosting responsibility deliberately

LangChain's current docs call their production service LangSmith Deployment. It handles agent runs that keep state between steps, stream their output, or pause for a person to review. LangGraph is one of the frameworks that can use it.

The docs describe three ways to host it: managed Cloud, a standalone Agent Server, or a self-hosted platform. They differ in who runs the control plane, the runtime, and the storage behind it. See LangSmith Deployment.

That difference matters more than a "supports self-hosting" checkbox. With a standalone server, the team runs its own infrastructure and the services it depends on. With the managed option, the team still needs to know where app data and traces end up, how sign-in is set up, and what the service agreement covers.

Get the customer's engineering and operations owners in the room for this decision. Show them four things: a run that pauses for review, a run that gets interrupted, an update, and a rollback. Explain what state survives, and how a new version of the app handles state saved by the old one.

This fits a team that wants to own custom agent code and can keep maintaining it. A managed service cuts infrastructure work. It doesn't do the app's permission checks, its testing, or its upgrade plan for you.

AgentCore Runtime: session isolation still needs application ownership

Amazon Bedrock AgentCore Runtime runs your own agent and tool code. AWS says it works with different frameworks and model providers, and it comes with identity and monitoring features. This section looks at the runtime only, not everything else under the Bedrock name. See AgentCore Runtime.

The session docs have the most useful detail. AgentCore does not check which user owns which session ID. Your backend has to track that. Also, anything stored on the agent's machine is temporary by default. If you need it to last, you have to build that storage yourself. See AgentCore sessions.

Test both directly. A user who submits someone else's session ID must not see that person's conversation. An approved change must not depend on a temporary disk sticking around. Keep the chat history separate from the permanent record of what was approved and what was done.

For a customer already on AWS, this may match the skills their team has. The forward-deployed engineer should still map four things separately: who's calling in, what credentials the agent uses going out, who owns each session, and who can change each business record. Keeping one session's machine apart from another's doesn't make everything inside it allowed.

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

Google's current docs put Agent Runtime inside Gemini Enterprise Agent Platform. They describe managed deployment, setting up sign-in and permissions, and support for different languages and frameworks, as long as the app follows the runtime's required format. Some frameworks get more built-in help than others. See the Agent Runtime overview.

The deployment docs list several ways in, including source files, a Dockerfile, or a container image. Pick the one the customer's build and release process can repeat. Write down the runtime format, dependencies, region, the app's identity, and its permissions on every resource it touches. See Deploy an agent.

The test that tells you the most goes like this. Deploy fresh from a versioned build. Send a request from a user who's allowed and one who isn't, and confirm the second is turned away. Then cut access to a data source the agent needs and look at the failure. A call that works on your laptop doesn't prove the deployed agent has the right access.

This fits teams whose apps and operations already live in Google Cloud. Check the actual service settings. Don't assume every feature in the overview is available in your region or under your agreement.

Give every finalist the same acceptance exercise

Use fake customer records and a test action you can undo. The agent reads a record, cites the policy that applies, suggests one category change, and waits for approval. Before applying the change, the part that does the write checks that the record hasn't changed since it was approved.

Keep the task the same for every candidate. Otherwise a flashier demo can look better just because it used easier data or broader permissions.

One row deserves a plain-English version. Say the update to the CRM goes through, but the reply saying so gets lost. If the agent just tries again, you could end up with the change made twice. The safe move is to check whether the first one landed, using a status lookup or a unique key the system recognizes. That's what idempotency means.

The table lists what to show. It doesn't claim any platform passes out of the box. If a platform needs extra work to pass a row, count that work.

Compare the work left for the customer

Score the finalists against what this customer wrote down as requirements, not against a generic rating. Sort every claim into one of three buckets:

• Documented: the vendor says it can.
• Demonstrated: you saw it work in the pilot.
• Unresolved: nobody's shown it yet.

A vendor's claim stays in the first bucket until the pilot or a contract review moves it.

Estimate cost from the same workload for everyone: model calls, tool calls, run time, storage, tracing, retries, and human review time. Add the cost to build it and to keep running it. Mark which prices are in a contract, which are estimates, and which are still unknown. Funding news and customer counts don't answer any of this.

The handoff should include:

• a versioned app,
• diagrams of where data goes and which account does what,
• the test cases and their results,
• how to release and how to roll back,
• who gets the alerts, and
• a runbook for incidents.

Name the person who can switch off a broken action without waiting for whoever built it.

So, where to start. Begin with the platform the customer already runs. Cut the list to the options that meet their must-haves. Run the narrow pilot before growing the scope. Then pick the one whose failures the customer can understand and handle on their own, not just the one with the best successful run.

To connect this choice to the rest of the build, read the FDE playbook, the knowledge-management pilot, and the document-processing guide.

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