AWS DevOps Agent Feature Launch Announcement: New Custom & Managed Memories and the Claims Behind Them
We walk you through some of the changes we're releasing to how memory and your knowledge shows up for you in the AWS DevOps Agent and expand on some of the why behind how and where some of your Knowledge shows up.
Series: AWS DevOps Agent Memory & Learning (2 articles)
- 1AWS DevOps Agent Feature Launch Announcement: New Custom & Managed Memories and the Claims Behind Them This article
AI agents need to remember which services you run, which pipelines deploy them, when something last broke, and why it matters for the task at hand. Without structured memory, agents either lose critical context between sessions or spend time rediscovering information they have already learned. Memory Stores give agents a persistent, organized knowledge base they can search and update. Each managed store groups memories about your environment, such as pipeline topologies, team practices, past incidents, and cost-optimization opportunities. Managed Memory Stores capture knowledge learned by AWS DevOps Agent, while Custom Memory Stores let you and your Custom Agents build and maintain reusable knowledge for your specific needs.
Today, we're releasing changes that make this knowledge easier to create, organize, inspect, and provide to your agents. As part of these changes, we're moving learned knowledge previously represented as Managed Skills into Managed Memory Stores. We're also expanding support for Memory Stores, making them directly attachable to Custom Agents, adding folder-style organization, and introducing claims with provenance on new memories. No migration action is required for active Agent Spaces or existing Custom Agents, we actively generated your learned knowledge as Managed Memory Stores and attached your existing Memory Stores to your Custom Agents. You can review or change those attachments at any time.
TL;DR: the biggest changes
- Managed Skills → Managed Memory Stores: learned skills (
understanding-agent-space,understanding-pipeline-topology,understanding-dependencies,[chat-]tool-use-best-practices) are now maintained as memory stores. if your agent space is active, there's nothing for you to do here. it's been regenerated. check out Knowledge -> Skills and you'll be pointed to Memories. trigger a refresh of the knowledge to see its latest state. - Bring your own Memory Stores: the AWS Dev Ops Agent better supports creating, managing, and deleting your custom memory stores from chat or through forms, alongside the learning agent-managed ones
- Custom Agent Memory: attach memory stores to a custom agent so it reads a folder of memories searchable in its filesystem, rather than attaching and using MCP tools across your entire agent space. you can edit the list of memory stores any time.
- Memory file/directories: your memory
namesupportspath/naming-styleand the UI gets a better folder directory view. Agents use this folder structure for organization & for memories are shown using progressive disclosure patterns (this enables better agentic search of memories) - Claims: Your custom agents' custom memories & your migrated memory stores now get claims, containing provenance, so you can see why the agent believes something, with a trace
Managed skills → Managed Memory Stores
If you're familiar with the Skills tab you'll recognize the knowledge that the AWS DevOps Agent learning agent generates for you, the learned skills . This knowledge, the understanding of your agent space topology, your pipelines, and tool use best practices learned by the DevOps Agent, is moving to your Memory tab. Keep reading to find out why.
Bring your own Memory Stores
Custom Memory Stores let you turn knowledge from your team and environment
into a reusable synthesis for agents. Each store groups related facts, conclusions, and guidance around a purpose, such as cost optimization, weekly operational review findings, or team practices. Its name and description tell agents what it contains and when to use it, reducing the need to rediscover or rederive the same context during future tasks.
into a reusable synthesis for agents. Each store groups related facts, conclusions, and guidance around a purpose, such as cost optimization, weekly operational review findings, or team practices. Its name and description tell agents what it contains and when to use it, reducing the need to rediscover or rederive the same context during future tasks.
On the Memory tab, you'll notice a new Custom Memory Stores section. Create
a Custom Memory Store by choosing a name and description in the form.
a Custom Memory Store by choosing a name and description in the form.
AWS DevOps Agent Chat also has an improved workflow for creating and managing Memory Stores. Select Create with Chat, and you'll be guided through turning the information you describe into an agent-ready set of relevant memories. For example, here is a cost-optimization Memory Store.
We recommend using a
description that describes what your memory store contains and when to refer to it for more information. You can read more about description best practices here .Why should I write my information this way?
Let's use an example with another feature we're launching today - your Custom Agents are getting a makeover too.
Custom Agent Memory
If you've been using Custom Agents, you may have used memory MCP tools such as
upload_memory or list_memories to give them access to your Agent Space's memory. To preserve their current access, we have attached all your existing Memory Stores to them. Going forward, you manage memory access by attaching Memory Stores directly to each Custom Agent instead of attaching memory MCP tools. You can review or change the attached stores at any time.You may be familiar with the pattern of attaching Skills to your custom agent. This gives your custom agent access to skills relevant to its purpose. Previously hidden behind tool attachment, we're making memory store attachment explicit and making your agents' memory store access work the same way as Skills. You can now attach specific Memory Stores to each of your Custom Agents, giving them read and write access to the information relevant to its purpose. All of your Memory Stores have been attached to your custom agents, and you can edit them any time.
How does this work?
Your agents use progressive disclosure. This pattern in agentic architecture is a search optimization mechanism, showing your agent lightweight metadata about the context it has and giving the agent the ability to search over this knowledge. You can read more about How Memories Work in the docs. You may have seen this pattern show up in different places, like Karpathy's
llm-wiki - an index of one-line summaries the agent can choose to drill into. Anthropic describes this as progressive disclosure for agents , and its the same way Agent Skills load a skills name and description.Memory File Directories
To lean into this idea of organization and context management, as well as maintain parity with how you manage information in your Skill folder (a
SKILL.md with references/), we've added path/as/name support for your memory name. Your memory page has also gotten an improved folder structure look. Learn more here .
To dive into more about the features above and the documentation, you can check out the AWS DevOps Agent "What's New?" . Keep reading this article for a bit of a deeper dive behind the migration decision.
Why were my skills moved to memory?
If you're a DevOps Agent power user like myself, you may be curious why we've actually made these changes. I confidently answer no to a common question which comes up around the changing of abstractions in an agentic systems, "isn't this just semantics?".
Stepping back a little bit, we can discuss the concept of knowledge, information, or memory itself. I generally like to lean on definitions from cognitive science or psychology to understand how to design and build memory systems. Memory is a search problem but it is also an epistemic problem.
Cognitive science provides a useful vocabulary for thinking about memory in agentic systems. Frameworks such as CoALA explicitly model agents using “modular memory components” inspired
by “the rich history of cognitive science.” Similar memory structures appear throughout the field, from the memory stream in Generative Agents to taxonomies proposed in recent surveys.
by “the rich history of cognitive science.” Similar memory structures appear throughout the field, from the memory stream in Generative Agents to taxonomies proposed in recent surveys.
As a design lens and how you as a customer can think about organizing your knowledge in your agent space, three forms of memory are especially useful. Semantic memory is the general knowledge accumulated over a lifetime. You may know a country’s capital without remembering the day you learned it. Episodic memory records specific events and experiences. Procedural memory is the implicit knowledge used to perform tasks without conscious narration, such as riding a bicycle.
| Type | In cognitive science | In the AWS DevOps Agent |
|---|---|---|
| Episodic — remembering | Episodic memory is "the memory of everyday events … that can be explicitly stated or conjured". These are specific experiences located in the past. Coined by Endel Tulving in 1972, he drew it as the line between remembering and knowing: you re-live occasions. | Past investigations. These are tied to when and where they happened. |
| Semantic — knowing | "General world knowledge that humans have accumulated throughout their lives" — facts detached from the moment you learned them. | The agent's understanding of your world — agent space topology, pipelines, dependencies and your best practices. These are general facts about your agent space distilled. This distillation of episodic → semantic is a real memory process. |
| Procedural — how | "A type of implicit memory … which aids the performance of particular types of tasks without conscious awareness of these previous experiences". Like riding a bike. | The procedures the agent runs. A remediation SOP or investigation workflow, for example: for a failed deploy, check the alarm, pull the logs, diff the last change, roll back if needed. These runbooks and procedural instructions are represented as skills. |
This distinction clarifies how to think about the new Memory Stores. Much of the learned knowledge previously called “skills” was never procedural. Knowledge of your agent
environment, pipelines, and dependencies is semantic knowledge about your world. This information is better understood as descriptive, semantic knowledge than as a procedure the agent executes.
environment, pipelines, and dependencies is semantic knowledge about your world. This information is better understood as descriptive, semantic knowledge than as a procedure the agent executes.
Representing this knowledge as memory lets us ask questions that matter for descriptive knowledge but rarely arise for procedures. Why should we believe this information? When was it learned? What exactly does it assert? How do we keep it accurate as the underlying world changes? Those epistemic questions determine the metadata a memory should carry and that metadata helps to answer those questions.
Claims and Provenance
This leads to claims, a concept with a useful parallel in fact-verification research. Rather than evaluating a passage as a single unit, researchers decompose it into individual facts that can be checked independently. FEVER and Claimify are public examples of this general pattern: identify a claim, then relate it to supporting or contradicting evidence.
The difficult part is choosing the right level of detail. A claim that is too broad may contain several assertions, making it unclear which part the evidence supports. A claim that is too narrow can lose the context needed to interpret it. As the Molecular Facts research notes, “more atomic facts like propositions may lack context to interpret correctly.”
In the AWS DevOps Agent, a claim is a fact stated clearly enough to understand and inspect on its own. A claim captures a fact that a memory asks the agent to rely on, together with provenance tracing that fact back to its source. Memories are not static notes. Without claims, a memory may tell you what the agent believes but not why it believes it. When that knowledge becomes outdated or conflicts with another source, it can be difficult to identify which part needs to be reconsidered. Claims expose the factual foundation of a memory. They let you inspect the agent’s knowledge, understand the evidence behind it, and trace it back to where it was learned. They also provide a more precise unit for inspecting and reviewing that knowledge as your agent space changes.
You might recognize
claim from some of the Managed Memories the AWS DevOps Agent already gives you, for example your Monitor memories . Head to your Memories tab to check out the monitors and you'll see something like the following when you render the memory as Code1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
- text: intro - Checkout health alarm monitoring end-to-end order-flow
via a synthetic checkout transaction
evidence:
- note: Alarm description and behavior confirmed across multiple investigations
— fires when the synthetic checkout transaction cannot complete within its ~10-min timeout
source:
- type: devopsagent:task
id: 7f3c1a90-2b4e-4d61-9c8a-1e5f0b6d2a34
created_at: '2026-06-12T01:06:22.038000Z'
- type: devopsagent:task
id: b2d84e17-9f30-42aa-8c19-6a7d3e4f0c58
created_at: '2026-06-18T03:48:55.828000Z'
- text: R1 - 1 incident, prod us-east-1, order-processing queue
evidence:
- note: Investigation found a spike of catalog-update events (~130x ba
that triggered a fan-out generating millions of downstream messages, overwhelming
the order-processing queue so the synthetic checkout transaction m
source:
- type: devopsagent:task
id: 3a9c7d52-1e08-4b6f-a4d1-8c2b5f9e0a76
created_at: '2026-07-02T15:40:39.049000Z'Your
understanding-agent-space and other new managed stores have been given a set of claims too. Memories you create and manage with your custom agents receive claims too.1
2
3
4
5
6
7
8
9
10
11
12
13
14
name: idle-rds-reporting-db
description: Records that the RDS instance reporting-db was found idle and is
a cost savings candidate at ~$200/mo. Read when reviewing RDS spend, idle database
waste, or planning right-sizing and teardown actions.
claim:
- id: C1
text: The RDS instance reporting-db is idle and costs approximately $200/month.
evidence:
- note: Reported directly by the user in this session as an idle instance with a
~$200/mo cost.
source:
- type: devopsagent:execution
id: 4d9f0a7c62b84e15a9c3f1027de6b8a1
created_at: '2026-08-20T14:01:23Z'Moving learned Skills into Memory Stores is therefore more than a change in terminology. It gives each kind of knowledge the structure it needs: Skills remain procedures an agent can follow, while Memory Stores hold the facts and context it uses to understand your environment. Descriptions and directories make that knowledge easier to discover through progressive disclosure; explicit store attachments ensure each Custom Agent receives the context relevant to its purpose; and claims with provenance make the agent’s knowledge inspectable, traceable, easier for you to organize and control. This makes it clear what the agent believes, why it believes it, and where that belief came from.
Further Reading
I won't dive too deep here, but there is a growing body of research on agentic memory, fact verification, and knowledge representation. The following resources are useful starting points, and myself and the team are always interested in continuing the discussion in the comments or elsewhere to help you understand how to better use and manage your knowledge effectively.
AWS DevOps Agent User Guide
Memory in AI agents
- Cognitive Architectures for Language Agents (CoALA) — Sumers et al., 2023. A language agent's memory as modular components grounded in cognitive science.
- Generative Agents: Interactive Simulacra of Human Behavior — Park et al., 2023. The "memory stream": store experiences, reflect on them, retrieve as needed.
- A Survey on the Memory Mechanism of LLM-based Agents — Zhang et al., 2024. A broad map of what agent memory is and why agents need it.
- MemGPT: Towards LLMs as Operating Systems — Packer et al., 2023. Tiered memory, borrowing an operating-system analogy for context.
The forms of memory (cognitive science)
Progressive disclosure & context management
- Effective context engineering for AI agents — Anthropic, 2025.
- Equipping agents for the real world with Agent Skills — Anthropic, 2025.
- LLM Wiki — Andrej Karpathy, 2026.
- Progressive Disclosure — Jakob Nielsen (NN/g), 2006. The origin of the term in interaction design.
Claims & fact verification
- FEVER: Fact Extraction and VERification — Thorne et al., 2018. Claims labeled against the evidence that supports or refutes them.
- Molecular Facts: Desiderata for Decontextualization in LLM Fact Verification — Gunjal & Durrett, 2024. How atomic a checkable fact should be — decontextualized, but minimal.
- Towards Effective Extraction and Evaluation of Factual Claims (the Claimify method) — Metropolitansky & Larson, 2025. Extracting verifiable, standalone claims from long text.
- Citations on the Anthropic API (available in Amazon Bedrock) — Anthropic, 2025. Grounding an AI's statements in their sources.
Series: AWS DevOps Agent Memory & Learning (2 articles)
- 1AWS DevOps Agent Feature Launch Announcement: New Custom & Managed Memories and the Claims Behind Them This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article