Objection handling

1. "This is vendor lock-in."

The honest answer. Less than it looks, and there are four specific facts rather than a reassurance:

• AgentCore is framework-neutral: CrewAI, LangGraph, LlamaIndex, Google ADK, OpenAI Agents SDK, Strands, and custom frameworks. You keep your agent code as written.
• It is model-neutral, including models outside Bedrock: OpenAI, Gemini, Claude, Nova, Llama, Mistral.
• It is protocol-native: MCP and A2A are first-class, so tools and agents are addressable by open protocols rather than a proprietary interface.
• The harness exports to Strands code with one CLI command, on the same compute and primitives. The managed abstraction has a documented exit.
• Capabilities are independently adoptable, so take Gateway alone and change nothing else.

The real gap. Adopt Gateway, Identity, Policy, and Memory together and you have a genuine platform dependency. Your agent logic stays portable; your operational surface does not: IAM policies, endpoints, credential providers, memory namespaces, and traces. Migrating away would mean rebuilding that operational layer even though the agent code itself is portable. Say so. The right framing is that the lock-in is at the plumbing layer, which is exactly the layer the customer said they did not want to build. That is the trade they are making, and it is a reasonable one made knowingly.

2. "It'll be more expensive than running it ourselves."

The honest answer. Nobody knows, including AWS, and you should say that. Consumption pricing with no minimums means the floor is low, and a real list of things carry no charge: harness, the AgentCore CLI, skills, Identity when used through Runtime or Gateway, cross-region inference, Optimization during preview, and Registry's free tiers. Then redirect to what is actually knowable and find their dominant meter. Chatty stateful agent, it is Memory retrieval. Research agent, it is Web Search at $7.00 per thousand queries. Long-running autonomous agent, it is vCPU-hours. Send them to calculator.aws rather than leaving your number in their notes.

The real gap. No credible independent benchmark exists comparing AgentCore against self-managed ECS or EKS for the same agent workload, so any claim either way is unproven. Argue Runtime on session isolation and undifferentiated engineering removed, not on unit cost — that argument you can defend. Policy's second, token-based meter is the other trap; see the pricing card.

3. "There are thirteen services. This is too complicated."

The honest answer. Agree with the observation and reject the conclusion. AWS's own framing is that the capabilities work together or independently, and that is the whole answer to sprawl: nobody adopts thirteen things. Give them a starting order instead of a catalogue:

The real gap. The naming genuinely does not help: harness versus Runtime, Policy versus Guardrails, "Built-in Tools" meaning Browser and Code Interpreter, and inconsistent capitalisation across AWS's own material. A customer's confusion is a reasonable response to the surface, not a failure of attention. Point them at the terminology card rather than defending the names.

4. "It's too new to bet on."

The honest answer. Separate the parts. Runtime, Memory, Gateway, Identity, Browser, Code Interpreter, and Observability have been GA since October 2025; Policy since around December 2025; Evaluations since March 2026; harness since June 2026; Registry since 6 August 2026. At GA every service gained VPC support, AWS PrivateLink, CloudFormation, and resource tagging, which is the specific, checkable answer to "is this enterprise-ready," and much better than reassurance.

The real gap. Two capabilities remain preview with no announced GA date, Optimization and Payments, plus Runtime session storage. And Registry's GA is a live demonstration that preview APIs really do change: it moved namespace, endpoints, IAM prefix, and API schema, and preview customers have a hard 17 September 2026 migration deadline. Use that as evidence you are being straight with them: this is why you say pilot, not plan.

5. "We already built all this ourselves."

The honest answer. Often true, and the wrong response is to argue. Ask which parts they are still maintaining, and let the list do the work. The two most productive probes:

• "How do you scope credentials per end user?" If the agent holds one shared credential, every user of it has the union of all permissions that credential carries, and no prompt fixes that. Per-user outbound credentials are the piece teams almost always skip because they are tedious rather than hard.
• "Where is your authorization check?" If the answer is "in the system prompt," that is advisory and degrades as the agent gets more capable. A check at the Gateway perimeter holds regardless of the agent's autonomy.

Then make the modular offer: keep everything that works, replace the one piece that keeps them up at night. That is a far easier yes than a platform migration.

The real gap. A team with a mature, working stack may genuinely gain little, and a bad AgentCore recommendation costs you credibility for the next three conversations. ECS or EKS is the right answer when they need custom sidecars, GPUs, or an existing service mesh. Knowing when to say "you're fine, don't change anything" is what makes your recommendation trusted the time it matters.

Canada-specific objections

These will not appear in any AWS enablement material, and they are the ones your customers will raise. Full detail on the Canada card.