fix(harness): populate retrievalConfig from memory strategy namespaces

[padmak30]

Description

Without retrievalConfig in the CreateHarness payload, the harness runtime had no instruction to retrieve from any namespace at inference time — so long-term memory was written correctly but never read back.

mapMemory now accepts the resolved Memory spec and derives retrievalConfig by collecting namespaces from all strategies.

computeHarnessHash now includes the Memory spec so that changes to strategy namespaces in agentcore.json trigger a redeploy even when harness.json is unchanged.

Related Issue

Closes # #1097

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.

[agentcore-devx-automation]

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

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43.6%	10129 / 23229
🔵	Statements	42.89%	10773 / 25117
🔵	Functions	40.45%	1708 / 4222
🔵	Branches	40.5%	6638 / 16388

Generated in workflow #3277 for commit ee91cc9 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Thanks for tackling this! The core fix — populating retrievalConfig from the memory's strategy namespaces and including the memory spec in the harness config hash — is on the right track and matches what the runtime needs.

A couple of things to consider before merging:

1. EPISODIC reflectionNamespaces are excluded from retrievalConfig. This may leave the issue partially unresolved for users with EPISODIC strategies (see inline comment).
2. No test coverage for the redeploy-on-namespace-change behavior that the PR description calls out as a primary fix (see inline comment on harness-deployer.ts).

Minor: the memorySpec lookup in harness-deployer.ts only matches by memory.name, so harnesses that reference memory by arn won't get a retrievalConfig derived. This is probably acceptable as a known limitation (we can't introspect external memories), but worth confirming the intent.

[agentcore-devx-automation]

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

addressed comments

[tejaskash]

Minor / low priority — flagging for awareness rather than as a blocker.

The spec lookup keys solely on harnessSpec.memory?.name. HarnessMemoryRefSchema (src/schema/schemas/primitives/harness.ts:188) makes both name and arn optional, and mapMemory already has an if (memory.arn) branch (harness-mapper.ts:280). For an arn-only ref, find(m => m.name === undefined) returns undefined and the harness ships without retrievalConfig.

That said, no CLI surface produces this shape — agentcore add harness always writes { name: ... }, and there's no --memory-arn flag. The only way to land here is hand-editing harness.json. So this is theoretical for any first-party flow.

Two reasonable resolutions:

1. Tighten HarnessMemoryRefSchema to require name (drop the arn branch in mapMemory along with it), so the schema reflects what the tooling actually supports.
2. Leave as-is and add a test asserting that the arn-only branch intentionally omits retrievalConfig, so a future contributor doesn't read it as a regression.

Either is fine — feel free to defer or close as out-of-scope.

[agentcore-devx-automation]

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