AgentCore course → Field cards → Whiteboard patterns
Three whiteboard patterns
One pattern per printed page, each held under eight boxes — the test is whether you can redraw it from memory in ninety seconds while someone watches. Reasoning in Lesson 7. Verified 2026-08-05.
All three say one thing: constraints on autonomous systems belong outside the model's reasoning. Session isolation in the platform, not the prompt. Authorization at the Gateway perimeter, not in instructions. Spending limits at the infrastructure layer, not in the agent's logic.
| If the customer… | Draw | Capabilities |
|---|---|---|
| Has working agent code and a small team | A, minimum viable | Runtime, Gateway, Identity, Memory |
| Is regulated and needs every action auditable | B, auditable | + Policy, Observability |
| Wants agents to transact and be discoverable | C, transacting | harness, Gateway, Payments, Registry |
Pattern A: minimum viable adoption
For: seed to Series A, working agent code, one or two engineers, no platform team. The pitch: four capabilities, no rewrite, and the one thing you cannot cheaply build yourself.
| Element | Why it is there |
|---|---|
| App unchanged | The reassurance that does the most work. No rewrite. |
| Runtime | Session isolation, the hardest thing to retrofit. |
| Gateway → Identity | Per-user credentials, not one shared key. |
| Memory, overrides tier | Cheaper storage and pinnable inference. |
| Observability | Only if they will actually look at it. |
Cost driver: Memory retrieval, and they will not expect it. Separate meter at $0.50 per thousand; in the worked sketch it was 58% of the bill and about three times the entire Runtime cost.3
Do not add: Policy, Evaluations, Optimization, Registry. Two engineers cannot operate them, and offering them makes you sound like you are selling.
Pattern B: the auditable pattern
For: Series B and up, regulated, with a platform team and an existing IdP. The pitch: every action authorised before execution and every decision logged, enforced outside the agent's code.
| Element | The sentence that sells it |
|---|---|
| Gateway as sole path | One chokepoint is what makes everything else enforceable rather than requested. |
| Policy, in Cedar | Evaluated at the Gateway perimeter, outside the agent's code, so enforcement holds regardless of the agent's autonomy. This is the prompt-injection answer. |
| Identity, outbound | The agent never acts with more authority than the human it serves. Works with their existing Okta or Entra ID, no user migration. |
| Observability | Every Policy evaluation lands here, so authorization decisions and execution traces share one pipeline. That convergence is the audit trail. |
Cost driver: usually still Memory retrieval, but check Policy. It publishes both $0.000025 per authorization request and $0.13 per thousand input tokens processed, and the docs do not make clear which configurations incur the token meter. Do not model Policy at scale without verifying.3
Raise both of these unprompted
- Guardrails within Policy is not in
ca-central-1— N. Virginia, London, Stockholm, Sydney, Tokyo only. No managed prompt-injection or PII screening at the perimeter in-region.1 - Policy's inference routes globally from Canada, one of only four such source regions. No opt-out, and CloudTrail does not record where. If that is disqualifying for their compliance framework, Policy is currently not usable for them. Say so plainly.2
Memory and Evaluations are both fine — bounded to Canada plus US, both pinnable. Detail on the Canada card.
Pattern C: the transacting pattern
For: agent-native startups, pre-revenue, technically strong. The pitch: agents that pay for what they use and can be hired by other agents. The caveat: the two most interesting pieces are outside Canada and one is preview.
| Element | What to say |
|---|---|
| harness | No orchestration code. Free. Exports to Strands code with one CLI command, so the choice is reversible. |
| Gateway → paid MCP | The Coinbase x402 Bazaar is reachable through Gateway, with over 10,000 endpoints an agent can search and pay for autonomously. |
| 402 → Payments | Agent hits a paid resource, receives HTTP 402, and AgentCore handles x402 negotiation, wallet auth, stablecoin payment, and proof delivery without interrupting the reasoning loop. |
| Spending limit | Enforced deterministically at the infrastructure layer, not in the prompt. For a founder letting an agent spend real money, that is the whole argument. |
| Registry | Publish their agent as an A2A card so others can discover and call it. |
Volunteer this before they ask
- Payments: preview, no announced GA date. N. Virginia, Oregon, Frankfurt, Sydney. Not Canada.1
- Registry: GA 6 Aug 2026, but N. Virginia, Oregon, Ireland, Sydney, Tokyo. Not Canada. Anyone on the preview has a 17 September 2026 migration deadline with breaking schema changes.1
Recommend piloting in us-west-2 and treating the payments layer as
something to experiment with rather than plan around.
← Back to Lesson 7 · Objections → · Canada & data residency →