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, though flag that Web Search runs in only three regions and Canada is not one of them. 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 Registry, plus Runtime session storage. Payments reached GA on 18 August 2026. And Registry's namespace migration 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.

Two newer controls worth volunteering

Announced 6 August 2026, and both answer objections the original Policy story could not. Temporal policies make authorization stateful, so a rule can require human approval before a privileged action, or require that a tool argument exactly match the output of an earlier call. That second one is a real defence against an agent being talked into passing a fabricated argument. Rate limiting caps requests, inference tokens and concurrent connections per user or group, which is the first good answer to "what stops a runaway loop from taking down our downstream API."

The gap. The announcement does not list regions, and Canada is unconfirmed as of 10 August 2026. Describe them as announced, not available, and offer to confirm.

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.