Advisory whiteboard drill

Four capabilities, and no more: Runtime, Gateway, Identity, Memory. Add Observability if they will actually look at it.

• Runtime, because the state-bleeding incidents are the whole story. That's a session isolation failure, and session isolation is the hardest thing on the list to retrofit onto their own infrastructure. Their LangGraph app deploys as-is, no rewrite.
• Gateway + Identity, because the enterprise customer's security questions are going to land on credential scoping. If their agent holds one shared API key, every clinic effectively has the union of all permissions it carries.
• Memory on the built-in with overrides tier, which is cheaper storage and keeps inference pinned.

What NOT to recommend: Policy, Evaluations, Optimization, Registry. Two engineers can't operate them, and suggesting them makes you sound like you're selling rather than advising. Registry solves a problem they won't have for two years.

The discipline here is subtraction. A four-capability recommendation that they actually adopt beats a nine-capability one they abandon.

Memory retrieval, almost certainly, and they won't expect it. A records-lookup agent consults memory on nearly every turn. Retrieval is a separate meter at $0.50 per thousand, and in the worked support-agent sketch it was 58% of the total bill and roughly three times the entire Runtime cost.

The advice: decide now how many times per turn the agent needs to consult memory. Halving that saves five times more than switching storage tiers does.

Runtime compute is genuinely cheap at their scale. Don't let them optimise it first.

Agree, then reframe, because it's not a migration.

"You're not migrating. Your LangGraph code deploys unchanged; AgentCore runs underneath it. And you don't have to take all of it. Start with Runtime alone if you like, because the capabilities work independently. The isolation problem you've already had twice is the one thing you genuinely can't fix cheaply yourself, and it's the thing your enterprise customer is about to ask about in writing."

The honest concession to make: they will take on an operational dependency: IAM policies, endpoints, credential providers. That's real. It's also precisely the layer a two-engineer team should not be building.

Runtime, Gateway, Identity, Policy, Observability, Memory. This time the fuller set is justified, because they have a platform team to operate it.

• Gateway is the load-bearing choice. Every tool call passing through one chokepoint is what makes the other two requirements achievable at all.
• Policy in Cedar, evaluated at the Gateway perimeter and outside the agent's code, so enforcement holds regardless of the agent's autonomy. That sentence is the answer to the CISO's prompt-injection question: a prompt instruction is advisory, a perimeter check isn't.
• Identity outbound against their existing Okta, with no user migration, giving a credential scoped to the individual customer service agent rather than a shared service account. That's the "never more authority than the human it serves" requirement, structurally.
• Observability is the audit trail, since every Policy evaluation is logged through it, so authorization decisions and execution traces are in one pipeline.

Two problems, and you should raise both unprompted.

1. Guardrails within Policy isn't in ca-central-1, five regions only and Canada not among them. So the managed prompt-injection and PII screening the CISO is implicitly asking for isn't available in-region. Options: an out-of-region deployment for that layer, or screening in their own application code.
2. Policy's own inference routes globally. Canada is one of only four source regions using global cross-region inference. Authorization prompts may be processed in any commercial AWS region, there is no documented opt-out, and CloudTrail doesn't record where it happened. For a regulated fintech with a data residency obligation, that may be disqualifying, and if it's, Policy is currently not usable for them and you should say so plainly rather than hoping it doesn't come up in the security review.

Memory and Evaluations are both fine here: bounded to Canada plus US, and both can be pinned, Memory via the overrides tier and Evaluations via custom evaluators.

Raising this yourself is the single highest-credibility move available to you in this meeting. They will find it eventually. Far better it comes from you.

Don't argue. Ask two questions and let the answers do the work:

• "How do you scope credentials per end user today?" If it's a shared service account, that's the compliance requirement they have already written down, unmet.
• "Where is your authorization check?" If the answer is the system prompt, that's advisory and degrades as the agent gets more capable.

Then make the modular offer: keep their tool layer, put Gateway and Policy in front of it. They're not replacing anything, only adding an enforcement perimeter to something that already works.

If their answers are good, meaning real per-user token exchange and a deterministic authorization service outside the agent, say so. "You've already built the important parts" is a legitimate answer, and giving it's what makes your recommendation trusted the next time.

harness, Gateway, Payments, Registry, and the last two come with a preview warning attached.

• harness, because they have no orchestration code they're attached to and speed matters more than control. Declare the agent in configuration; AWS runs the loop. It's free, and it exports to Strands code with one CLI command if they outgrow it, so the choice is reversible, which is what makes it responsible advice to a startup moving fast.
• Payments Preview for the pay-per-use data sources. Their agent hits a paid resource, gets HTTP 402, and AgentCore handles x402 negotiation, wallet auth, stablecoin payment, and proof delivery without interrupting the reasoning loop. Coinbase CDP or Stripe Privy wallet. And the Coinbase x402 Bazaar MCP server is available through Gateway with over 10,000 endpoints to discover, which is probably more interesting to their CTO than anything else in this course.
• Registry so other agents can discover theirs, published as an A2A agent card.

The spending-limit point to make explicitly: per-session limits are enforced deterministically at the infrastructure layer, not in the prompt. For a founder about to let an autonomous agent spend real money, that's the difference between a product and a liability.

Both of the interesting capabilities are unavailable in Canada, and one is preview.

• Payments: preview, no announced GA date. N. Virginia, Oregon, Frankfurt, Sydney only. Not ca-central-1.
• Registry: GA as of 6 August 2026, but N. Virginia, Oregon, Ireland, Sydney, Tokyo only. Not ca-central-1.

So: pilot in us-west-2, keep the core agent wherever they like, and be explicit that the payments layer isn't something to put on a funded roadmap yet. Volunteer this before they ask. "Two of the three things you're most excited about aren't in Canada, and one is preview" costs you nothing said early and costs you everything discovered later.

If they were already on the Registry preview, they also have a migration with a 17 September 2026 deadline and breaking schema changes. Worth checking.

This is the objection where you should partly concede. They probably could, since the spec is public and they're strong engineers.

What they would also be building: wallet credential management, spending governance that holds when the agent is autonomous, per-transaction observability, and the billing relationships with every provider. AWS's framing is that this is months of engineering, and that a misconfigured payment flow doesn't produce a bad answer, it moves real money.

The strongest single argument is the enforcement one, and it's the same argument as Policy at the Gateway: spending limits enforced at the infrastructure layer can't be reasoned around by the agent. If they build limits into their agent's own logic, they're trusting a model not to exceed a budget. That's the part that's genuinely hard to get right, not the 402 handshake.

Honest closing: it's preview, so "build it yourself" is a defensible choice today. Say that. Then point out that the x402 Bazaar's 10,000 endpoints are reachable through Gateway either way.