Agentforce vs. Amazon Bedrock AgentCore: two opposite bets on the enterprise agent

Agentforce 360 and Amazon Bedrock AgentCore both reached general availability on October 13, 2025 — the same day, which is a nice coincidence and a misleading one, because the two products are barely in the same category. One sells you an agent that already knows your customers. The other sells you the runtime to build an agent and get it to production without operating the infrastructure yourself. Reading them as competitors and picking one “winner” is how buyers end up with the wrong tool and a stalled project.

We’ve done the stack-honest version of this comparison for Microsoft Copilot Studio and Google Gemini Enterprise, and the AWS one has a sharper twist: Copilot Studio and Gemini Enterprise are, like Agentforce, opinionated application-layer products. AgentCore is deliberately not — it’s infrastructure. So the real question isn’t “which agent is smarter,” it’s “do you want to buy an agent or build one,” and that question has a right answer for your org depending on where your data lives and who’s on your team.

This post draws the line cleanly: what each actually is, where Amazon Q fits into the AWS side, the trade-offs that decide it, and why the honest answer for a large enterprise is often “both, governed centrally.”

Two different products wearing the same word

Start by naming what each one is, because the word “agent” is doing too much work.

Agentforce 360 is an agent as a feature of your system of record. You don’t build the runtime, the memory, or the grounding pipeline — Salesforce did. What you do is configure: define topics, wire actions to Flow and Apex, set guardrails, and point the agent at your data. The reasoning is handled by the Atlas reasoning engine, which plans a sequence of steps, checks its output against the goal, and revises when a step fails. The grounding is handled by Data 360 (the platform formerly called Data Cloud), which unifies your CRM records and unstructured content so answers come from your data, not the model’s training. It’s low-code, it’s governed by the Einstein Trust Layer, and it’s already sitting on top of the customer data most enterprises keep in Salesforce. The trade you’re making: less control, in exchange for not having to build or operate any of the hard parts.

Amazon Bedrock AgentCore is an agent as infrastructure. It’s a set of composable, production-grade services you assemble around an agent you write — in whatever framework you like. The modules are the tell: Runtime (a serverless execution environment with session isolation and notably long execution windows — AWS cites eight hours — plus A2A protocol support), Memory (managed short- and long-term memory, including self-managed strategies where you control the extraction pipeline), Gateway (turns your APIs and Lambda functions into agent tools, and connects to existing MCP servers), Identity (identity-aware authorization and secure token storage), and Observability (end-to-end execution visibility). AgentCore is explicitly bring-your-own-framework and bring-your-own-model — LangGraph, CrewAI, Amazon’s own Strands, or custom code — wrapped in AWS-grade isolation, VPC networking, and PrivateLink. The trade you’re making: near-total control, in exchange for having a team that can actually build and own an agent.

That’s the whole comparison in miniature. Agentforce is the assembled car; AgentCore is the engine, chassis, and a very good set of factory tools. One is not better than the other — they answer different questions.

Where Amazon Q fits

The AWS side has a second layer that confuses the comparison, and it’s worth ten seconds to place it. Amazon Q is the packaged-assistant tier that sits above the raw building blocks — the finished products for people who don’t want to build.

• Amazon Q Business is a horizontal enterprise assistant: connect it to your data sources and business apps, and it answers questions and takes actions across them. It’s the closest AWS analog to a general “assistant over everything,” and under the hood it provisions Bedrock agents and tools with enterprise search and security wrapped around them.
• Amazon Q Developer is an AI assistant for engineers — code completion, review, test generation, and large-scale code modernization. It’s a developer-productivity tool, not a customer-facing agent platform, and it’s not really in this comparison at all.

So the AWS answer to “I want an agent” has three doors: Q Business if you want a packaged assistant over your enterprise data, Bedrock Agents if you want a fully managed agent orchestrating Bedrock-hosted models with less assembly, and AgentCore if you want to build and operate a custom production agent on your own terms. Agentforce, by contrast, has one door: configure the agent Salesforce already built. That single door is a feature, not a limitation — it’s why an Agentforce agent reaches a sandbox in weeks — but it’s a real philosophical difference from the AWS menu.

The trade-offs that actually decide it

Strip away the feature lists and four questions decide this, every time.

Where does your system of record live?

This is the dominant factor and it’s not close. If the customer data, the cases, the opportunities, and the service workflows the agent needs to reason over already live in Salesforce, Agentforce starts grounded — the data dependency that decides agent quality is already resolved, because Data 360 is unifying that data natively. Building the equivalent grounding on AgentCore means standing up the retrieval, the identity mapping, and the data pipelines yourself against Salesforce’s APIs — doable, but you’re rebuilding what you already pay Salesforce for.

Flip it: if the data the agent needs lives in your own data lake, in DynamoDB, in S3, in systems that have nothing to do with CRM, then Agentforce is the one fighting uphill, and AgentCore’s bring-your-own-everything model is the natural fit.

Who is going to build and own it?

Agentforce is built for admins and low-code builders. The configuration surface — topics, actions, guardrails — is designed so a Salesforce team that has never written a line of orchestration code can ship a governed agent. An Agentforce action looks like configuration, not infrastructure:

# Conceptual shape of an Agentforce action — declarative, wired to a Flow/Apex handler
topic: Order Status
action: getOrderStatus
description: "Look up the status of a customer's order by order number."
inputs:
  - name: orderNumber
    type: Text
    required: true
handler: OrderStatusFlow        # deterministic Flow or Apex does the actual work
guardrails:
  - requiresVerifiedCustomer: true

AgentCore assumes the opposite: a platform-engineering team that writes the agent, chooses the framework, wires the tools, and owns the deployment. You get eight-hour runtimes, session isolation, and VPC-level control — capabilities that only matter if you have people who can use them, and overhead that’s pure cost if you don’t. Matching the tool to the team is the same discipline as the build-vs-buy decision itself: the most powerful platform is the wrong one if nobody on staff can operate it.

What does the workload actually need?

Some workloads genuinely need what AgentCore offers and Agentforce doesn’t expose: an arbitrary open-source framework, a specific non-Salesforce model, long-running autonomous execution measured in hours, or deployment inside your own VPC for data-residency reasons. Others need exactly what Agentforce offers and AgentCore makes you build: a governed, low-code service agent grounded in CRM, live in a sandbox in weeks, with the Trust Layer and human-handoff already handled. Name the workload’s real requirements before you name a vendor — most “we need maximum flexibility” instincts don’t survive contact with “and who’s going to maintain it.”

What does it cost, and can you predict it?

The pricing models are as different as the products. Agentforce’s default is Flex Credits — roughly $0.10 per agent action (about $500 per 100,000 credits) — plus the Data 360 consumption underneath it, which for serious grounding is a real line item (the Data 360 Starter SKU alone lists in the tens of thousands per year). It’s consumption-based and it can surprise you, which is why we wrote a whole Flex Credit optimization playbook — but it’s a single vendor’s bill. AgentCore is priced like AWS infrastructure: you pay for the underlying compute, the model inference, and each module you consume, itemized the way every AWS service is. That’s more granular and arguably more controllable, but it’s also more surfaces to watch, and the total cost of a custom agent has to include the engineering team that builds and runs it. Neither is cheap; they’re expensive in different shapes.

Why the honest answer is often “both”

Here’s the part the “which one wins” framing misses entirely. A large enterprise will very plausibly run Agentforce for its CRM-facing agents — service, sales, the customer-facing work grounded in Salesforce data — and AgentCore for bespoke, non-CRM agents its platform team builds against its own data. That’s not indecision; it’s matching each tool to the workload it fits. AWS and Salesforce are simultaneously partners and competitors, and their own protocol choices reflect it: both support A2A for agent-to-agent communication and MCP for tool and data connectivity, precisely because neither expects to be the only agent platform in your building.

Which raises the problem that outlives the vendor choice: once you have agents on both, who governs the estate? Neither vendor’s native controls can see the other’s agents — and that gap is exactly what a cross-vendor control plane like MuleSoft Agent Fabric is built to close, discovering and governing Agentforce, Bedrock, and everything else from one layer. The strategic decision isn’t “Agentforce or AWS.” It’s “how do I let each team use the right tool without losing a single, governed view of what’s running.” Answer that, and running both stops being a mess and becomes an architecture.

The takeaway

Agentforce 360 and Amazon Bedrock AgentCore are opposite bets. Agentforce is an agent as a feature of your system of record: low-code, grounded in CRM through Data 360, governed by the Trust Layer, and fast to ship if your data and your team already live in Salesforce. AgentCore is an agent as infrastructure: bring your own framework and model, get production-grade runtime, memory, identity, and observability, and build something custom if you have a platform team and workloads that aren’t CRM-shaped. Amazon Q — Business and Developer — is AWS’s packaged-assistant tier above the building blocks. Decide with four questions: where your system of record lives, who will build and own the agent, what the workload actually requires, and whether you can predict the bill. And don’t force a single answer across a big organization — the mature posture is the right tool per workload, unified under one governance layer so “both” is a strategy instead of a sprawl.

Understanding the basics

Is Agentforce built on Amazon Bedrock?

No — they’re independent platforms from competing vendors. Agentforce 360 is Salesforce’s agent platform, running on its own Atlas reasoning engine and grounded in Data 360, governed by the Einstein Trust Layer. Amazon Bedrock AgentCore is AWS’s infrastructure for building and operating agents on your own frameworks and models. Both reached general availability on the same day in October 2025, and both support the open A2A and MCP protocols so agents from either platform can interoperate, but neither is built on the other. An enterprise can absolutely run agents on both.

What is the difference between Amazon Bedrock AgentCore and Amazon Q?

AgentCore is infrastructure for teams that build agents — a set of composable services (Runtime, Memory, Gateway, Identity, Observability) you assemble around an agent you write, in any framework. Amazon Q is the packaged-product tier above it: Q Business is a ready-made enterprise assistant you connect to your data sources, and Q Developer is an AI coding assistant for engineers. Rough rule: choose AgentCore to build a custom production agent, Q Business to deploy a packaged assistant over enterprise data, and Q Developer if you want an AI pair programmer. Agentforce, by contrast, is a single configure-don’t-build product.

Which is cheaper, Agentforce or AgentCore?

Neither is cheap, and they’re expensive differently. Agentforce uses consumption-based Flex Credits (about $0.10 per action) plus Data 360 costs for grounding — one vendor’s bill, and one that can surprise you without optimization. AgentCore is priced like AWS infrastructure: compute, model inference, and per-module usage, itemized — more granular and controllable, but more surfaces to track, and you have to add the cost of the engineering team that builds and operates the agent. The genuinely cheaper option depends less on list price than on whether you’re paying Salesforce to have already built the hard parts or paying your own team to build them.

Can you use Agentforce and Amazon Bedrock together?

Yes, and many large enterprises will. A common pattern is Agentforce for CRM-facing agents (service, sales) grounded in Salesforce data, and AgentCore for bespoke agents a platform team builds against non-CRM systems. Both support A2A and MCP, so agents can communicate and share tools across the two platforms. The catch is governance: neither vendor’s native controls can see the other’s agents, so running both well means adding a cross-vendor governance layer — such as MuleSoft Agent Fabric — that discovers, secures, and meters agents across every platform from one place.

---

Trying to decide whether your next agent belongs in Agentforce, on AWS, or both — and how to keep one governed view across them? Talk to us. We build governed agents grounded in Salesforce data, and we draw the honest boundary between what belongs on your CRM platform and what your own engineers should own — because the wrong tool for the workload is the most expensive mistake in this whole category.