AWS designs an AgentCore memory lifecycle with expiration, scoring, consolidation, and audit
Long-running agents need deliberate forgetting, plus traceable records for pruning, consolidation, and failures.
Key takeaways
AWS published an AgentCore memory lifecycle design on September 4 for long-running agents that accumulate stale context, reduce answer quality, and increase compliance risk. The post separates memory into episodic, semantic, and procedural types, then applies three policies: time-based expiration, relevance scoring, and model-assisted consolidation. Its deployable example runs nightly with EventBridge and Step Functions, invokes a sequence of Lambda functions, emits CloudWatch metrics, writes run results to Amazon S3, and routes failures to Amazon SNS. The numerical retention periods are examples rather than universal rules. Teams should define retention by purpose, legal basis, sensitivity, retrieval value, and rollback needs, then test that pruning improves freshness without deleting evidence or procedures that remain necessary.
Direct answer
AWS published an AgentCore memory lifecycle design on September 4 for long-running agents that accumulate stale context, reduce answer quality, and increase compliance risk. The post separates memory into episodic, semantic, and procedural types, then applies three policies: time-based expiration, relevance scoring, and model-assisted consolidation. Its deployable example runs nightly with EventBridge and Step Functions, invokes a sequence of Lambda functions, emits CloudWatch metrics, writes run results to Amazon S3, and routes failures to Amazon SNS. The numerical retention periods are examples rather than universal rules. Teams should define retention by purpose, legal basis, sensitivity, retrieval value, and rollback needs, then test that pruning improves freshness without deleting evidence or procedures that remain necessary.
Verified facts
AWS divides agent memory into episodic, semantic, and procedural categories. Conversation records are high-volume and usually decay quickly; distilled facts can remain useful longer; procedures are lower-volume but may carry the highest operational value.
The design combines time-based expiration, access and relevance scoring, and consolidation of lower-value records into compact semantic memory. Values such as a 90-day default are configurable starting points, not universal retention standards.
The reference architecture uses EventBridge to trigger Step Functions for pruning, scoring, consolidation, metrics, and result persistence. CloudWatch, S3, and SNS provide monitoring, audit output, and failure notification.
What changed
- Set retention by memory type
- Expire before scoring and consolidation
- Test quality and compliance before deletion
- Keep metrics and audit output for every run
Impact for AI users
Long-running agents can carry old preferences, resolved issues, or obsolete procedures into new tasks. Users should be able to inspect, correct, and delete memories about them. Operators need to know why a record was retained, when it was consolidated, who removed it, and whether required business or compliance evidence survives. More memory does not automatically make an agent more capable.
Operating checklist
- Inventory episodic, semantic, and procedural memory with purpose, sensitivity, owner, and deletion basis.
- Start with a time limit for low-risk episodic memory before adding scoring and consolidation.
- Use a golden question set to compare accuracy, stale references, recall, and complaints before and after cleanup.
- Record the input scope, policy version, deletion count, consolidation result, failures, and rollback point for every run.
AI frontier news and analysis, AI software and model tools, AI skill tutorials and validation methods, and AI account and permission guidance
FAQ
Is 90 days a standard retention period for agent memory?
No. It is a default in the example. Actual retention depends on purpose, regulation, sensitivity, and evidence requirements.
Why not delete every old memory?
Procedural knowledge and some semantic facts can remain valid. Unclassified deletion may reduce quality or remove audit evidence, so test and retain rollback.
How can a team prove that cleanup did not degrade the agent?
Compare accuracy, stale references, recall, and anomalies on a fixed question set, and retain the policy version and run result.
Summary
Agent memory should be governed as a data asset with retention limits, quality measures, and audit ownership; deliberate forgetting matters as much as recall.
This AI-assisted article is checked by ENHE AI automation for official sources, bilingual fields, media rights, page safety, and historical duplication before publication.
What this means for everyday users
Long-running agents can carry old preferences, resolved issues, or obsolete procedures into new tasks. Users should be able to inspect, correct, and delete memories about them. Operators need to know why a record was retained, when it was consolidated, who removed it, and whether required business or compliance evidence survives. More memory does not automatically make an agent more capable.
Tools you may use
Related tutorials
[[zh]][[/zh]][[en]]Review a public website[[/en]]
SearchScope SEO/GEO
[[zh]][[/zh]][[en]]Access and usage guide[[/en]]
AI Prompt Management System | 418 Bilingual Prompts for Writing, SEO and AI Creation
High-Frequency AI Prompts for Work, Learning, and Teaching guide
High-Frequency AI Prompts for Work, Learning, and Teaching
Related Tools And Tutorials
Use the following ENHE AI sections to continue from the news signal into tool selection, account-service guidance, or practical learning.
Related reading
Bayer Shares Production Lessons From 22 Specialist Agents: HTTP Success Is Not Task Success
AWS published Bayer Crop Science’s Agentic Decision Engine case study on October 23, 2026. The production system runs 22 specialist agents over governed analytics workflows, models, logs, and visualization tools. This article turns the architecture into five reusable acceptance checks for enterprise agent teams: persist the state needed to resume work, define identity and authorization at every boundary, scope each agent’s tool catalog, distinguish transport success from task success, and release to a gated group before broader access. It also explains why Bayer’s adoption and resolution figures are evidence about one implementation, not promises for another organization. The focus is operational proof, least privilege, rollback, and observable outcomes rather than prompt polish.
Nine-Stage AI Agent Evaluation Checklist: From First Commit to Production Drift
AWS published a nine-stage production AI-agent evaluation framework built around Amazon Bedrock AgentCore on October 16, 2026. It follows an agent from defining quality and comparing experiments through merge checks, deployment gates, canary scoring, adversarial testing, drift detection, live pulse monitoring, and feedback-driven improvement. The framework evaluates five dimensions—safety, quality, performance, cost, and operational control—at tool, individual-agent, and multi-agent levels. This durable guide converts the public framework into a vendor-neutral checklist for ordinary teams, with minimum evidence, ownership, and stop conditions designed to catch soft failures where latency and uptime remain normal while answer quality quietly declines over time.
AWS Jam adds three hands-on agent challenges, from specs to production governance
AWS announced three new AWS Jam experiences on September 30 for agentic AI development: spec-driven development with Kiro, building agents with Bedrock AgentCore, and advanced agentic systems. The company lists eight to twelve hands-on challenges covering MCP servers, subagents, content safety, IAM isolation, monitoring, and policy controls. Each is a one-day, team-based exercise in a live AWS console sandbox and can be offered alone or alongside instructor-led training. Participants solve operational tasks with AWS services rather than answer multiple-choice questions. The exercises can reveal gaps in deployment, permissions, and troubleshooting, but completion is not proof that a team is production-ready. Confirm access requirements, delivery format, and possible sandbox resource charges before scheduling a session.
Three agents produce a track together on persistent AgentCore runtimes
On September 30, AWS published a hands-on example in which three specialized agents collaborate to render, generate, and clear a music track on Amazon Bedrock AgentCore Runtime Instances. The sample colocates agents on one GPU-backed instance, gives them persistent shared storage, and uses a shared session ID for handoffs and resumable work. AWS says Runtime Instances can host agents built with different frameworks; the walkthrough uses Strands and a file-backed session manager. It is an implementation example, not evidence of unattended production readiness. Deploying it provisions cloud resources such as runtimes, storage, and container repositories, so teams should estimate ongoing charges, narrow IAM permissions, and test cleanup and failure isolation before adapting the pattern.
A durable Nova Act checklist for monitoring real user journeys before customers find failures
AWS published an agent-driven synthetic-monitoring pattern with Amazon Nova Act and Bedrock AgentCore on September 28. EventBridge can trigger isolated browser sessions from every five minutes to hourly, Nova Act executes natural-language steps from page screenshots, and assertions verify outcomes such as login, search, cart, or form completion before SNS sends failures. AWS says a typical six-step journey takes two to four minutes and recommends ephemeral browser sessions for independent monitoring, with credentials stored in Secrets Manager. A durable monitor still needs fixed test data, deterministic success conditions, timeouts, bounded retries, false-positive review, spending limits, and a clear distinction between application failure, model uncertainty, and external dependency failure.
A durable multi-account agent checklist that keeps data with its owning team
AWS published a multi-account AI-agent architecture on September 24. A central platform account runs the agent and model, while line-of-business accounts keep their data and expose only approved tools through MCP servers. AgentCore Gateway provides one endpoint for tool discovery, authentication, fine-grained authorization, and observability. This should become a durable governance task rather than a one-time deployment. Whenever an account, tool, model, or identity provider changes, recheck machine identity, user authorization, returned fields, tenant isolation, rate limits, cost ownership, and log completeness, then drill privilege escalation, expired credentials, tool-contract changes, and cross-account failures. Teams should reproduce the vendor's result with their own data, controls, workload, and operating limits before production adoption.