Memory for Workflow Agents
Builders adding cross-invocation context to a workflow agent that processes recurring entities (incidents, tickets, devices). If you haven't wired up event sources yet, see Event Processing first.
Workflow agents use memory differently than conversational agents. Instead of multi-turn conversation history, they remember facts about entities (tickets, incidents, devices) across invocations.
Memory Strategies
See the AgentCore memory strategies documentation for full configuration details on each strategy.
| Strategy | Use Case | Example |
|---|---|---|
| SEMANTIC | Remember facts about entities that accumulate over time | "INC-001 has been escalated twice before" |
| SUMMARIZATION | Condense prior actions into context for the current invocation | "Last time this device alerted, we restarted nginx" |
| None (stateless) | Simple event processing where each invocation is independent | "Route this support email to the right queue" |
When to Use Memory vs. External State
| Question | If Yes → Use... |
|---|---|
| Does the agent need context from prior events? | AgentCore Memory (SEMANTIC) |
| Does the agent track entity state across events? | DynamoDB + Memory |
| Is each event fully self-contained? | No memory needed |
| Does the agent learn patterns over time? | Memory (long-term) |
Memory vs. Conversational Agents
AgentCore Memory provides two memory types: short-term (raw session events) and long-term (extracted facts via strategies). Workflow agents typically use long-term memory scoped to entities rather than short-term conversation replay.
| Dimension | Conversational Memory | Workflow Memory |
|---|---|---|
| Scope | Per-user conversation history | Per-entity facts (ticket, incident, device) |
| Duration | Session (minutes) + long-term (days/weeks) | Cross-invocation (hours/days/weeks) |
| Access pattern | "What did the user say earlier?" | "What happened to this entity last time?" |
| Namespace | User ID | Entity ID (e.g., incident ID, device ID) |
| Typical strategy | Session + SEMANTIC | SEMANTIC or SUMMARIZATION |
Example: Entity-Scoped Memory
When an incident recurs, the agent should know what happened last time. Note the namespace semantics: the session_id scopes memory to the specific entity (incident), while the actor_id identifies the service. For long-term isolation purposes, memory is actor-scoped — different actor IDs produce independent memory stores even for the same session ID.
from bedrock_agentcore.memory.integrations.strands import (
AgentCoreMemorySessionManager,
)
# Use the entity ID (incident ID) as the session scope.
# actor_id identifies the service; memory is actor-scoped for long-term isolation
# — see: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory-organization.html
session_manager = AgentCoreMemorySessionManager(
memory_id=os.environ["BEDROCK_AGENTCORE_MEMORY_ID"],
region=os.environ.get("AWS_REGION", "us-east-1"),
session_id=f"incident-{incident_id}", # entity-scoped
actor_id="incident-agent", # service identity — consistent across invocations
)
agent = Agent(
model="global.anthropic.claude-sonnet-4-5-20250929-v1:0",
system_prompt=SYSTEM_PROMPT,
tools=[get_service_health, restart_service],
session_manager=session_manager,
)
With this configuration, when INC-001 fires again next week, the agent retrieves context like "Last time this incident occurred, we restarted the service and it resolved in 3 minutes."
Further Reading
- AgentCore Memory overview
- Memory types (short-term and long-term)
- Memory strategies (SEMANTIC, SUMMARIZATION, USER_PREFERENCE, EPISODIC)
- Memory organization: actor and session namespaces
- Memory-augmented agents (AWS Prescriptive Guidance)