Loading today’s stories
Build1 distinct publisher3 min readPublished
The AgentCore lifecycle stack defaults episodic memory to 90 days, while the same post recommends 30 to 60 days for summaries and 6 to 12 months for semantic facts. The default is a placeholder to fork before production.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Two instructions in this design sit on top of the same rows. Expire episodic memories first, with a 90-day default [14][9]. Consider no TTL at all for procedural memories [16]. AgentCore stores procedural knowledge as reflections tied to episodic memory [13], and both the Summary and Episodic strategies store entries bound to a specific agent-user session [10]. So before `memoryTtlDays` goes near production, run the small experiment: write a reflection, expire its parent session, read the memory back, and see what survived. The post does not state whether deletion propagates.
AWS ships one knob for retention [17] against per-type windows it recommends in the same breath, which are 30 to 60 days for summaries, 6 to 12 months for semantic memories, and nothing for procedural [16]. Measured against that advice, the shipped default holds summaries between 1.5 and 3 times longer than recommended [1], and the recommended semantic window runs 3 to 12 times the summary window [2]. One parameter cannot express a 12x spread. AWS calls the default a starting point [17], which is the honest description of it.
The ordering is the best-engineered part. TTL expiration runs before scoring or consolidation, so nothing gets ranked that was already due for deletion [18]. That falls out of where the money is: Bedrock sits in the nightly path [6], scoring is inference, and inference is metered while a delete is not.
What the material does not carry is measurement. The named failure modes are two observed agents, one of them repeating deployment advice because its memory still held a superseded runbook [4]. AWS's claim is that unmanaged memory degrades response quality and creates compliance risk [2]. The compliance half of that stands on the retention rule alone; the quality half needs evidence, and for the effect to transfer to your agent, stale entries have to be retrieved into the prompt at answer time by a retriever with no recency weighting of its own. If yours already ranks by recency, the superseded runbook loses without help from a nightly job, and lifecycle management buys you storage discipline and a retention posture rather than better answers. Worth knowing which one you are paying for.
The compliance framing is the part I would build first, because it is the part the source states without hedging: TTL ignores whether a memory is still useful, but it gives a hard ceiling on accumulation and is essential for compliance [15], and for a low-volume agent the advice stops at TTL plus GDPR [8]. That makes a defensible retention clock the deliverable, and it is one number an auditor can read. Scoring and consolidation can wait until someone measures the answers.
Ranked by verification strength, evidence, and original report placement.
AWS published a post titled 'Designing lifecycle policies for AgentCore memory' describing memory lifecycle management for long-running agents on Amazon Bedrock AgentCore.
AWS states that if agent memories are not actively managed, agents accumulate outdated context, which can degrade response quality and create compliance risks for the deployment.
AWS says it observed a customer support agent reference a billing dispute that had been resolved four months earlier, treating it as active.
AWS says another agent repeated outdated deployment advice because its memory still contained a superseded runbook.
AWS defines memory lifecycle management for AI agents as the practice of systematically scoring, consolidating and pruning agent memories over time.
The described architecture uses AgentCore memory, AWS Step Functions and Amazon Bedrock to run a nightly lifecycle workflow, delivered as an AWS CDK stack with the complete code in a GitHub repository.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 4, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
AWS's phone-ordering host is really an MCP wiring diagram with no retry button1 distinct publisher
invest
AWS delivers 77% of Amazon's profit growth on 34% of its revenue growth1 distinct publisher
build
Bedrock routing without the router Lambda: one state machine, two model calls per question1 distinct publisher
build
AWS wants data governance to ship as a pull request, not a sign-off1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One vendor post, but checkable in code
Every fact traces to a single AWS post that nobody outside AWS has tested. Specificity is what keeps it honest: named parameters, a BEFORE filter on the system createdAt field of ListMemoryRecords, a decay rate near 0.02676 at the shipped defaults, and a public repository a reader can hold against the prose. The weak link is the pair of production failure stories, which arrive with no customer, no product and no date.
Published, with no usage disclosed
AWS shipped a stack and described an architecture; who runs it is absent. The failures cited are anonymous, and there are no deployment counts, named customers or repository signals anywhere in this reporting. Uptake is unmeasured here, which is not the same as low.
Modest claims, one default that oversells readiness
AWS frames this as a starting point rather than a finished retention policy, which is fair. The overreach is narrower and more concrete: a stack described as deployable ships a single memoryTtlDays knob at 90 days, which holds summary memories 1.5 to 3 times longer than the production window printed a paragraph earlier, and applies none of the semantic or procedural distinctions the taxonomy section just established.
The vendor documenting billable consumption
The remedy runs nightly on Step Functions with Bedrock scoring inside it, all metered by the author, and the memories it manages sit in an AWS service. There is also a quiet pull toward generosity in the default, since a 90-day episodic window stores more than a 30-day one. None of that makes the guidance wrong; it does mean the retention advice worth following is in the production paragraph rather than in the parameter that ships.
Firm on what shipped, blind past it
The configuration facts and the arithmetic between them are solid, printed in one document and self-checking. Consequence is where this thins out: the decay formula has been tried nowhere outside AWS, the two anecdotes carry no verifiable detail, and nothing measures whether nightly pruning holds response quality. Read this as confident about the mismatch between what AWS ships and what AWS advises, and quiet about whether the approach works.