feat: add support for TS memory

[nborges-aws]

Description

Wires up memory for typescript strands agent template. When a user picks a memory option during agentcore create for a TS Strands agent, the generated project now ships ready-to-run with the new Strands memory integration from the (SDK PR #187). Same devEx as we support for python strands path.

Changes:

• TUI: agentcore create now shows the memory step for typescript strands
• Schema mapper: TS Strands now flows through hasMemory / memoryProviders same as python
• TS Strands template:
  • New capabilities/memory/memory.ts — wires up MemoryManager with strands integrations createAgentCoreMemoryStores
• Tests: existing TS-skips-memory test flipped to assert the new behavior (previous asserted memory not included)

Tested e2e: Built locally against the SDK PR's branch, deployed a TS strands + memory project, and invoked with a memory to remember. Upon next invocation, memory was recalled as expected.

NOTE: This change is dependent on:

1. SDK PR #187. The template should be pinned to latest SDK version once this PR is merged & released. This PR should be updated with new pinned version before merge.
2. CDK PR #292. Strands SDK's dynamic await import('@aws-sdk/client-s3') was unable to resolve given the previous bundler. This CDK fix is required for TS strands memory, otherwise agentcore deploy fails on all TS strands projects.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Package Tarball

aws-agentcore-0.21.0.tgz

How to install

gh release download pr-1636-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.21.0.tgz

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-cli-automation]

Thanks for shipping this — the Strands TS memory wiring matches the Python pattern nicely. A few items need to be resolved before merge:

1. Asset snapshots are stale (will fail CI)

src/assets/__tests__/__snapshots__/assets.snapshot.test.ts.snap was not regenerated. Specifically:

• The asset-file-listing snapshot (around line 845) does not include the new typescript/http/strands/capabilities/memory/memory.ts entry.
• The snapshot for typescript/http/strands/base/main.ts (line 7376) still shows the pre-PR contents (no memory branching, no agent cache).
• The snapshot for typescript/http/strands/base/package.json (line 7567) still pins @strands-agents/sdk: 1.0.0-rc.4 and bedrock-agentcore: ^0.2.4.

Please run npm run test:update-snapshots and commit the regenerated file — the PR checklist box for snapshot regeneration is also unchecked.

2. package.json dependency versions

bedrock-agentcore: ^0.3.0 does not exist on npm yet (latest published is 0.2.4), and @strands-agents/sdk: ^1.5.0 is a caret range rather than a pin. You already called both of these out in the PR description; flagging here so it's not missed at merge time. Once the SDK ships, both should be pinned exactly (see inline comment).

3. Schema mapper guard removal creates a TS + VercelAI footgun

See inline comment on schema-mapper.ts — the CLI flag flow no longer rejects --language TypeScript --framework VercelAI --memory longAndShortTerm, and the schema mapper now lets it through.

4. getActorId can return undefined despite its string return type

See inline comment on memory.ts.

Points 1 and 2 will break CI / generated projects; 3 is a silent-cost footgun; 4 is a latent runtime bug for OAuth / CUSTOM_JWT callers. Happy to re-review once these are addressed.

[agentcore-cli-automation]

bedrock-agentcore@^0.3.0 is not on npm yet (latest published is 0.2.4), and the import bedrock-agentcore/experimental/memory/strands used in memory.ts ships in that unreleased version. Until 0.3.x is published, every newly generated TS Strands project (memory or not) will fail npm install. Per the PR description this PR shouldn't merge until the SDK is released — when it is, please also pin exact versions (drop the carets on both bedrock-agentcore and @strands-agents/sdk) per the note in the PR description.

[nborges-aws]

This will be updated in PR once new SDK version is released.

[agentcore-cli-automation]

Removing the config.language === 'TypeScript' guard here (and on line 279) is correct for TS+Strands, but it also lets TS+VercelAI propagate hasMemory=true and a populated memoryProviders. The TUI compensates by resetting memory to 'none' whenever the user picks a non-Strands SDK (useGenerateWizard.ts setSdk), but the CLI-flag flows do not — see src/cli/commands/add/validate.ts and src/cli/commands/create/validate.ts. Running agentcore add agent --language TypeScript --framework VercelAI --memory longAndShortTerm ... (or the equivalent agentcore create) would now provision a Memory resource and inject a MEMORY_*_ID env var that the VercelAI template never reads — silently costing the user money.

Options to fix:

• Tighten the guard here to e.g. (isMcp || (config.language === 'TypeScript' && config.sdk !== 'Strands')) so only the Strands TS template gets memory.
• Or, add a validation rule in validateAddAgentOptions / validateCreateOptions rejecting language=TypeScript && framework!=Strands && memory!='none'.

Either is fine — just please don't leave the CLI-flag path unguarded.

[agentcore-cli-automation]

Return type is string but this can resolve to undefined when there's no custom-actor header, no payload.userId, and context.sessionId is also missing — exactly the OAuth / CUSTOM_JWT scenario the Python session.py template explicitly handles with a synthesized session id:

# AgentCoreMemoryConfig rejects None; OAuth/CUSTOM_JWT callers can reach us
# without a runtime session header, so synthesize one when absent.
session_id = session_id or uuid.uuid4().hex

If actorId is undefined when createAgentCoreMemoryStores is called, the cache key becomes "undefined:default-session" and the SDK call will either throw or write events under a literal 'undefined' actor.

Options:

• Synthesize a fallback (e.g. crypto.randomUUID()) when all three sources are missing, matching the Python template.
• Add a final ?? 'default-actor' literal.
• Change the return type to string | undefined and handle that at the call site in main.ts.

Minor: also worth aligning the fallback chain with Python — Python uses payload.user_id (snake_case) and context.user_id; this template uses payload.userId (camelCase) and context.sessionId. If that divergence is intentional, a comment explaining why would help.

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	37.16%	13593 / 36577
🔵	Statements	36.43%	14452 / 39667
🔵	Functions	31.8%	2333 / 7336
🔵	Branches	31.1%	8996 / 28925

Generated in workflow #3829 for commit ab5be2c by the Vitest Coverage Report Action