Harness with memory configured does not persist or load conversation history from AgentCore Memory
- Dominant language
- TypeScript
- Stars
- 283
- Forks
- 95
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 183
Description
### Description
When a harness is created with AgentCore Memory enabled (the default), the harness runtime never calls the Memory APIs (`CreateEvent`, `ListEvents`) during invocations. Conversation history is only maintained in the microVM's in-memory state. Once the microVM session is stopped or expires, all conversation context is permanently lost — even when re-invoking with the same session ID and actor ID. CloudTrail confirms zero memory API calls are made, and no errors are logged.
### Steps to Reproduce
1. Create a harness project with memory enabled (default):
```bash
agentcore create --name myHarnessAgent
agentcore deploy
```
2. Verify memory is deployed and attached to the harness:
```bash
agentcore status
# Output confirms:
# harnessChrekaAgentMemory: Deployed (SEMANTIC, USER_PREFERENCE, SUMMARIZATION, EPISODIC)
# harnessChrekaAgent: Deployed (READY)
```
3. Invoke the harness with a session ID and actor ID:
```bash
agentcore invoke myHarnessAgent \
--session-id "test-session-padded-to-meet-minimum-len" \
--actor-id "user1" \
--prompt "Get the current date using shell and remember it."
```
4. Stop the runtime session to force the microVM to terminate:
```bash
aws bedrock-agentcore stop-runtime-session \
--agent-runtime-arn "arn:aws:bedrock-agentcore:us-west-2:ACCOUNT:harness/HARNESS_ID" \
--runtime-session-id "test-session-padded-to-meet-minimum-len" \
--region us-west-2
```
5. Re-invoke with the same session ID and actor ID:
```bash
agentcore invoke myHarnessAgent \
--session-id "test-session-padded-to-meet-minimum-len" \
--actor-id "user1" \
--prompt "What did we do earlier in this session?"
```
### Expected Behavior
Per the [harness memory documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-memory.html):
> "Attach an AgentCore Memory instance to the harness and every invocation saves the conversation automatically, scoped by session ID. On subsequent invocations with the same session ID, the agent's history is loaded from Memory before it reasons, so it remembers what happened in previous turns, even after the underlying microVM session has expired."
The agent should recall the previous conversation after the microVM is terminated and a new one spins up, because the harness should have:
- Written conversation events to AgentCore Memory after each invocation
- Loaded conversation history from Memory before reasoning on the new invocation
### Actual Behavior
- The agent has **no memory** of prior turns. It responds: *"I don't have any memory of previous interactions."*
- Input token count drops from ~4000 (with in-memory history on the live microVM) to ~933 (fresh context, no history loaded).
- CloudTrail shows **zero** `CreateEvent` or `ListEvents` API calls to the Memory service during or after invocations — only `GetWorkloadAccessToken` and `GetHarness` calls are present.
- CloudWatch logs for the runtime show only OpenTelemetry traces (`gen_ai.*` events) with no memory-related API calls or errors.
- Conversation continuity works within a live microVM session (in-memory state only), but is completely lost once the microVM is stopped.
### CLI Version
1.0.0-preview.8
### Operating System
macOS
### Additional Context
- **Region:** us-west-2
- `harness.json` correctly references the memory: `"memory": {"name": "harnessChrekaAgentMemory"}`
- `agentcore.json` defines the memory with 4 strategies: SEMANTIC, USER_PREFERENCE, SUMMARIZATION, EPISODIC
- `agentcore status` confirms the memory resource is DEPLOYED and attached to the harness
- The harness status is READY
- **No errors appear in CloudWatch logs** — the memory APIs simply are not being called
- The issue is **silent** — there is no indication to the user that memory persistence is not functioning
- Tested with multiple invocations (4 turns) in the same session before stopping the microVM; none produced memory API calls in CloudTrail
Contributor guide
Assessment
This issue has not been assessed yet.