Bedrock Agents Remember the Summary. Your Scheduled Runs Need the Whole Story.

Ask whether an Amazon Bedrock agent remembers, and the honest answer starts with a switch. Memory in Bedrock Agents is a feature you turn on, not a property the agent has by default. Leave the switch off and every session is a first meeting. Turn it on and the agent carries something real across sessions, but what it carries is a summary, tied to one user, inside one agent, inside AWS. For a chatbot that greets a returning customer, that can be enough. For a scheduled automation that has to pick up yesterday's work exactly where it stopped, the shape of that memory matters more than its existence.

Inside a session, the agent remembers the conversation

While a session is alive, a Bedrock agent tracks the conversation as it goes. Each invocation can build on the turns before it, intermediate results stay available, and the agent can reason across a multi-step request without the caller restating every detail. Anyone who has tested an agent in the console has seen this work: ask a follow-up with no context in it, and the answer still lands, because the session holds the thread.

That thread belongs to the session. When the session ends, the working context goes with it. A new session, even minutes later, even for the same person, begins with whatever the platform chooses to reload, and by default it reloads nothing. Session memory and cross-session memory are separate systems in Bedrock, and confusing the first for the second is where most surprise amnesia comes from.

Turn memory on and the agent keeps a summary, on a timer

The cross-session feature works like this. When memory is enabled, Bedrock summarises a session after it ends, either when the caller closes it explicitly or when the configured idle timeout runs out. That summary is stored under a memory identifier. The next time the agent is invoked with the same memory identifier, the summaries of earlier sessions are loaded into the new session, and the agent answers with that background in mind.

Retention is configurable between 1 and 365 days, with 30 days as the common default, and after the retention window the summaries are deleted. The summarisation itself happens asynchronously after the session ends, driven by a prompt template that can be customised. All of this is genuinely useful: it is the mechanism behind an agent that remembers a traveller's seat and meal preferences from one booking conversation to the next.

Notice what the stored object is, though. It is a summary of each session, produced by a model, after the fact. The next session receives the digest, not the conversation.

A summary is a compressed past, and compression makes choices

Summaries keep the shape of what happened and drop most of the substance. Preferences, decisions, and outcomes tend to survive summarisation. Exact wording, the order arguments were made in, a number mentioned once in passing, the correction a user gave halfway through and then refined two turns later: those are exactly the details a summariser is most likely to flatten or omit, because its job is brevity.

For casual continuity, the flattening is invisible. For work, it shows. A scheduled agent reviewing vendor replies needs to know what the vendor actually quoted, not that pricing was discussed. An agent continuing a research task needs the source it rejected and the reason, not a line saying sources were evaluated. When the next run's job is to continue precisely, a digest of the past is a weaker tool than the past itself, and every run that works from a digest quietly re-derives, or quietly misses, what the digest left out.

The memory belongs to one agent and one identifier

Bedrock memory is also carefully fenced, and the fences matter for automation stacks. Summaries are stored per memory identifier so that different users never see each other's past, which is the right design for a customer-facing agent. The side effect is that continuity only exists for callers who arrive carrying the same identifier. A scheduled job that invokes the agent with a fresh identifier, or through a different agent, or from a workflow tool outside Bedrock entirely, gets none of it.

That last fence is the one automation operators hit hardest. A real stack is rarely one Bedrock agent. It is a Bedrock agent beside an n8n workflow, a Make scenario, a Lambda function, and a human chatting with a different AI tool in the afternoon. Bedrock's memory serves the first of those. The other four cannot read it, cannot write to it, and have no way to know it exists. Each one keeps its own notes, or keeps none, and the operator becomes the integration layer between five partial memories.

A newer AWS service, Bedrock AgentCore Memory, tackles the same problem as a standalone store with short-term events and extracted long-term records. It widens the options for agents built inside the AgentCore world, and it confirms the direction of travel: memory is becoming its own layer. The question for a mixed stack is whether that layer lives inside one vendor's platform, readable only by that platform's agents, or outside all of them, readable by everything.

Put the memory where every run can reach it

That is the role Vilix AI is built to fill. Vilix AI is a cloud-hosted memory layer for AI tools and agents, reached over MCP. There is no infrastructure to provision and nothing to maintain: an agent, a workflow, or a chat tool connects, reads the context it needs at the start of a run, and saves what it learned at the end.

Two properties matter most next to Bedrock's design. First, Vilix AI stores full conversation history, not just facts or summaries extracted from it, so a returning agent can revisit what was actually said and decided, in sequence, rather than working from a digest someone else's summariser chose to write. Second, the memory is one and the same everywhere it is connected. What a Bedrock agent saves on Monday is available to a scheduled workflow on Tuesday and to a different AI tool on Wednesday, because none of them owns a private copy.

The terms are deliberately low-risk: a free plan that is free forever, a 7-day Pro trial with no credit card, and data that can be exported or deleted at any time. Bedrock's memory switch is worth turning on for the agent it serves. For everything around that agent, the runs that schedule it, the tools beside it, and the people reviewing its work, memory has to live somewhere all of them can reach. That somewhere is a layer of its own.