I tried creating a custom memory store with DevOps Agent to give a custom agent memory
This page has been translated by machine translation. View original
Hello. This is Takayama.
Previously, I wrote an article checking the memory functionality of DevOps Agent.
At that time, the memory stores consisted of only two types of managed stores: monitors, which is automatically learned, and directives, which users input manually.
It was possible to add memories from the chat, but the destination was always the existing stores, and there was no way to create entirely new stores.
In that context, the August 27, 2026 update brought the ability for users to freely create custom memory stores, along with 4 other updates.
| Update | Content |
|---|---|
| Creating custom memory stores | You can now create your own memory stores to organize operational knowledge by team, service, or recurring issue. Create them from the console or via chat with DevOps Agent, and set a clear description so the agent can determine whether it should reference that store |
| Organizing memories into folders | A memory's name is treated as a path within the store, and grouping them with a common prefix (e.g., alarms/) creates a folder structure. The agent uses progressive disclosure to open only the memories relevant to the task, and the Operator App displays the same structure |
| Learned Skills becoming memories | Learned skills such as topology, code dependencies, pipeline structure, and tool usage patterns are now maintained as memories. Changes happen automatically with no action required from users. You can view them from the Memories tab on the Knowledge page |
| Attaching memory stores to custom agents | You can now attach memory stores to custom agents to give them a focused information context. Custom agents read from and write to only the stores they have attached |
| What's new - AWS DevOps Agent |
This time, I'll try actually creating a custom memory store and having the agent retain memories, while also checking the other updates.
Summary first
- Creating custom memory stores
- You can now create them from the console (Knowledge page → Memories tab → Create memory store) or via a chat request
- The agent uses only the name and description to determine relevance before reading the store's contents
- The official recommended pattern for descriptions is to cover two points: "what it holds" + "when it should be used"
- Memory stores are designed as a place to save reusable conclusions, not as a scratchpad for one-off investigations or a cache for tool output
- Organizing memories into folders
- Separating a memory's name with
/allows nesting like folders, and the agent reads an index first and opens only the few relevant files (progressive disclosure)
- Separating a memory's name with
- Learned Skills becoming memories
- The knowledge previously called Learned Skills — topology, dependencies, pipeline structure, and tool usage patterns — has been integrated as managed stores
- The migration happens automatically with no action required from users
- Attaching memory stores to custom agents
- Memory stores can now be attached to custom agents
- They read from and write to only the attached stores, and new custom agents start with no stores attached
- Custom memory stores are read/write; managed memory stores are read-only
What are memories in the first place
Before getting into the details of the 4 updates, let me cover just what memories do.
In a word, it's a mechanism for carrying over knowledge to the agent that would otherwise be lost between sessions.
It's easiest to think of it as a place to save what you've learned so you don't have to re-examine the same environment or trace back to the same root cause from scratch every time.
The official documentation lists 4 benefits of using memories.
| Benefit | Content |
|---|---|
| Faster investigations | When the same issue recurs, the agent can recall the most recent root cause and skip redundant diagnostic steps |
| Environmental awareness | Retains information that's hard to re-examine every time, such as noisy alarms, infrastructure quirks, and relationships between components |
| Gets smarter over time | With each incident resolved, patterns and root causes specific to your infrastructure accumulate |
| Remembers preferences | Records communication preferences and instructions so the agent behaves as expected |
There are similar features called Skills and Agent instructions, but they serve different roles.
While Skills teach "procedures" and expand capabilities themselves, memories pass "facts" to help the speed and accuracy of judgment.
| Item | Skill | Agent instructions | Memory |
|---|---|---|---|
| Type of knowledge | Procedural (instructional steps) | Procedural (always-applied instructions) | Informational (synthesized context) |
| Format | Markdown or ZIP | Markdown only | Markdown only |
| How it's loaded | On demand (agent decides based on description) | Always (every session) | On demand (agent decides based on description) |
| Created by | User or DevOps Agent | User | User or DevOps Agent |
The actual entity is a single Markdown file, and the concept of a memory store is the container that manages it.
The agent isn't handed the full contents of stores at the start of a session — it first receives only a list of store names and descriptions.
From there, it determines relevance to the task and opens only the stores that seem related.
The same thing happens within a store: it reads the descriptions and then reads only the relevant memories.
This behavior of "reading the description and deciding whether to open it" is the foundation of this update.
Let's now look at each update.
Checking the updates
Update 1: You can now create custom memory stores
First, the first update.
Users can now create their own custom memory stores.
What's New states: "You can now create your own memory stores to group operational knowledge about teams, services, or recurring issues."
How to create a custom memory store
You can create one from either the console or chat. The steps for creating from the console are as follows:
- Open the "Knowledge" page in the Agent Space Operator Web App
- Select the "Memories" tab
- Select "Add store"
- Enter a name and description, then select "Create store"
When creating from chat, you simply make a request to DevOps Agent in natural language. The official documentation provides the following example request:
"Create a memory store named operational-procedures that holds the standard runbooks for our routine maintenance tasks." - Creates a store for standard operating procedures.
The custom stores you create are used in the same way as the managed stores automatically generated by DevOps Agent.
What's important to be aware of with this update is how to write the description.
The agent doesn't preload memory stores — it uses only the name and description to decide whether to use a memory.
A store's description is the most important thing you write, because it's how the agent decides whether the store is relevant—before it reads anything inside. ... A precise description gets the store opened at the right moment; a vague label such as
notesormiscgives the agent nothing to match against, so it skips the store even when the answer is inside.
As explicitly stated — "the store is skipped even when the answer is inside" — the accuracy of the description is directly tied to practical usefulness.
The official recommended approach for writing descriptions is to clearly state two things: "what the store holds" and "when the agent should use it."
Write a description that states two things: what the store holds, and when the agent should use it. A reliable pattern is to end with the situations it applies to—for example, "Read when investigating checkout or billing latency."
- Too vague: "Payments notes."
- Effective: "Standing runbooks, known issues, and escalation contacts for the payments service. Read when investigating checkout, billing, or refund incidents."
Another easy-to-miss point is that the description should be written as a declarative statement about the store's subject, not as an instruction directed at a person. Think of it as "information about ~" rather than "please do ~."
What to put in / not put in a store
After the description, the next thing to be careful about is what to save in a memory store.
The official documentation explicitly states that you should save only "conclusions worth recalling later" — it is not a place for notes taken during an investigation or for temporarily holding tool execution results.
A memory store holds durable, synthesized knowledge—facts about your environment, recurring root causes, standing conventions and directives, and the findings and summaries you distill from past work. Store the conclusion worth recalling later, not raw data.
A memory store is not a scratchpad for a single investigation, and it isn't a key-value cache for a tool's output.
The concrete example given in the official documentation is saving a conclusion uncovered during an investigation, such as "the checkout service calls the payments API synchronously."
Saving raw tool call results to retrieve later is not an intended use case. Raw data from an investigation is something the agent holds in its working context, so that's where it stays.
It's also recommended to keep each memory focused on a single fact or lesson rather than making one large sprawling entry.
The division is to save only information that's useful across investigations in memories, and leave one-time working data in the investigation itself.
Update 2: You can now organize memories with folders
A folder feature has been added for organizing memories.
What's New states: "Grouping with a common prefix (e.g., alarms/) creates a browsable folder structure."
Since a memory's name is treated as a path within the store, you can organize memories like folders by nesting them with / separators.
A memory's name is its path within the store, so you can group related memories into folders instead of keeping a single flat list. Use
/in a name to nest memories—for example,alarms/checkout-latencyorservices/checkout/overview.
Let me try requesting the creation of memories with the alarms/ prefix in a custom memory store called "ops-investigation-knowledge."
This time I'll send a prompt requesting the creation of memories to speed up investigation of sample-automated-aws-devops-agent-network-incident-response.
This Agent Space's connected AWS account has a sample environment deployed for practicing network failure investigations.
A Node.js app running on EC2 behind an ALB periodically checks connectivity to RDS, the internet via NAT Gateway, an S3 gateway endpoint, and a Bedrock Interface endpoint, and sends failures to CloudWatch as custom metrics.
Please investigate the CloudWatch Alarms in this environment and create memories to help speed up future investigations when an alarm fires.
## What I want you to do
1. Get an overview of the custom metrics in the `DevOpsAgentSample` namespace and the CloudWatch Alarms monitoring them
2. For each alarm, check what resource connectivity it monitors and what might be happening when it fires, based on the actual templates and resource configuration
3. Save the information you find as a memory for each alarm
## How to create memories
Please create a new store named `ops-investigation-knowledge` as the destination.
Set the store's description so it's clear what it holds and when it should be referenced.
Memories related to CloudWatch Alarms must have names with the `alarms/` prefix.
For example, use the format `alarms/database-connection-failures`.
Create one memory per alarm, for a total of 4 memories.
Information that is not specific to a single alarm (overall network configuration of this environment, settings common to all 4 alarms, etc.) should be saved without the `alarms/` prefix.
## Content to include in each memory
- The metric being monitored by that alarm and the target resource
- Candidate causes to suspect when the alarm fires (things that are actually possible given this environment's configuration, such as security groups, route tables, VPC endpoint policies, IAM, NAT Gateway, etc.)
- The first items to check and how to check them
- Any notes about confusing points during investigation
## Notes on what to save
Save only conclusions worth recalling later.
Do not save the metric values or raw API responses obtained during this investigation — instead, preserve the facts and investigation insights derived from them.
When done, show me a list of the stores and memories you created, with their names and descriptions visible.
Once creation was complete, I could confirm that an alarms folder was created with memories under it.
Even with folder organization, the agent's behavior is as described at the beginning.
The behavior of reading descriptions to decide whether to open something also applies here — it reads an index file first and opens only the few files relevant to the task.
The official documentation calls this progressive-disclosure.
Because a memory's location signals what it holds, the agent reads an index first and opens only the few files relevant to the task, the same progressive-disclosure pattern described above.
Update 3: Learned Skills have been migrated to Memories
The third update is straightforward.
As DevOps Agent conducts more investigations, it learns the topology and code dependencies of the infrastructure it manages, accumulating this as "Learned Skills" in the Skills tab.
With this update, these learned insights will be migrated to Memories. The four types in scope are as follows.
| Learned Skill | Store name | Content held |
|---|---|---|
| Agent Space Understanding | understanding-agent-space |
A map of resources and relationships within the Agent Space |
| Understanding Code Dependencies | understanding-dependencies |
Dependency maps between services and packages |
| Understanding Pipeline Topology | understanding-pipeline-topology |
The flow from pipeline start to release |
| Tool Use Best Practices | tool-use-best-practices |
Tool usage patterns and failure modes extracted from past investigations |
The migration is automatic and requires no action from users.
During the move, the console keeps showing a learned skill on the Skills tab until its memory is ready, and then points you to its new home on the Memories tab. After the move, you view and manage your learned skills on the Memories tab of the Knowledge page.
https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-learned-skills.html
When checking "Skills" as shown below, a message is displayed indicating that tool-use-best-practices / chat-tool-use-best-practices / understanding-agent-space / understanding-pipeline-topology have been migrated.
Checking the "Memories" side, you can confirm that tool-use-best-practices / chat-tool-use-best-practices / understanding-agent-space / understanding-pipeline-topology have been migrated.
All migration destinations are managed stores, so users cannot delete them.
Update 4: You can now attach memory stores to custom agents
The fourth update. DevOps Agent custom agents were previously composed of three elements: System prompt, Tools, and Skills.
Previously, for Memory, the built-in agent could access all memory stores within the Agent Space, while custom agents had no involvement with memory.
With this update, you can now configure Memory stores for custom agents.
Custom agent components
Checking the custom agent documentation, Memory stores have been added as a component.
Memory stores – Collections of memory that you attach to give the agent focused, informational context, such as your topology, past root causes, standing directives, or a store you created. A custom agent reads the memory stores you attach to it, and can write to the custom stores among them (managed stores such as
monitorsanddirectivesstay read-only), so you give it the knowledge its job needs and leave the rest out. A new custom agent starts with no memory stores attached, so it has no memory access until you attach one.
There are two key points.
One is that the attached stores are not simply read-only references. Managed stores (monitors, directives) remain read-only, but custom stores can also be written to.
The other is that new custom agents start with zero memory access. Unlike the built-in agent that can access something by default, memory is only referenced after you explicitly attach a store.
How memory is handled in the execution flow
Looking at the overall execution flow of a custom agent, it also describes at which steps memory reading and writing occur.
When a custom agent executes, it:
- Loads its system prompt, tools, skills, and attached memory stores from the configuration you defined.
- Connects to the Agent Space MCP toolbox and accesses only the tools you assigned to it.
- Loads its assigned skill documents, making their instructions and domain knowledge available during invocation.
- Reads the memory stores you attached, using their descriptions to open only the memories relevant to the task, and records what it learns back to any attached custom stores.
Rather than loading all attached memory stores in their entirety, it's designed to use the store names and descriptions to open only what seems relevant to the task.
And at the end of execution, it writes back what it learned to the attached custom stores.
The idea is that the more you run a custom agent repeatedly, the more knowledge specific to that agent accumulates.
Comparison with the built-in agent
A comparison table shows how the scope of memory access differs between the built-in agent (for incident response, etc.) and custom agents.
| Item | Built-in agent | Custom agent |
|---|---|---|
| Memory | All memory stores within the Agent Space | Only attached memory stores |
Custom agents compared to built-in capabilities - AWS DevOps Agent
While the built-in agent, given its nature for incident response, is designed to unconditionally access any knowledge within the Agent Space, custom agents are designed to explicitly narrow the scope of references, since users define their purpose.
Steps to attach a memory store
When creating from a form, there is a Memory stores field within the creation form.
Custom memory stores can be written to, but managed memory stores are referenced as ReadOnly.
Memory stores (optional) – Select the memory stores the agent can access. Use the search field to find stores by name. The agent reads the stores you attach and can write to attached custom stores; managed stores are read-only.
https://docs.aws.amazon.com/devopsagent/latest/userguide/custom-agents-creating-a-custom-agent.html
When creating or editing via Chat, you make attach/remove requests in natural language.
You can attach memory stores when you create an agent, using either the form or Chat, and change them later by editing the agent. To attach or remove stores in Chat, ask the agent.
https://docs.aws.amazon.com/devopsagent/latest/userguide/custom-agents-creating-a-custom-agent.html
Running a Custom Agent with Memory Store
Now, let's run a custom agent with a memory store attached by executing a custom agent that has the following prompt registered.
The prompt is configured to write back conclusions with future value from the investigation to the memory store.
You are an agent that reports monthly on the security status of an AWS environment.
## Goal
Create a monthly report that consolidates findings across Security Hub, GuardDuty, and Inspector. The purpose is to convey to the reader what has changed since last month and what needs to be addressed this month.
## Approach
1. Collect Security Hub findings for the target period. Aggregate by severity (CRITICAL, HIGH, MEDIUM, LOW) and by security standard (AWS Foundational Security Best Practices, CIS, PCI DSS). Also record the compliance score for each enabled standard.
2. Collect GuardDuty findings for the target period. Aggregate by severity and by finding type category (Backdoor, CryptoCurrency, Recon, UnauthorizedAccess, etc.). Also identify which resources were involved.
3. Collect Inspector findings for the target period. Aggregate separately by scan type (EC2, ECR container images, Lambda). List high-severity CVEs and indicate which ones have fixes available.
4. Perform the same aggregation for the previous month and compare with this month's figures. Retrieve both periods from each service's API for count comparisons, without relying on figures stored in the memory store.
5. Read the security-monthly-report-context memory store to retrieve report format conventions, findings determined not to be addressed as accepted risks, findings known to recur repeatedly, and environment-specific circumstances. If the store is empty or there are no relevant memories for the task, note this at the end of the report and continue processing.
6. Distinguish between findings newly identified this month, findings resolved this month, and findings that remain unresolved across multiple months. Those unresolved for extended periods should be reported with the highest priority. Those qualifying as accepted risks should be separated as already-decided items.
7. For each unresolved CRITICAL and HIGH finding, describe the affected resources, when it was first detected, and the remediation approach recommended by the service.
8. Write back to the security-monthly-report-context store any "conclusions worth referencing repeatedly in the future" identified during this analysis. This is limited to: findings that have recurred over multiple months and their structural causes, items that continue to be detected due to environment-specific circumstances, and newly determined items not to be addressed along with their rationale. Do not write back numerical values such as this month's finding counts or compliance scores, as these can be re-retrieved from the API.
## Constraints
- Operate in read-only mode. Do not perform any state-changing operations such as suppressing, archiving, or marking as resolved findings in Security Hub, GuardDuty, or Inspector.
- Do not include credentials, access keys, tokens, or personally identifiable information in the report. If such values appear in findings, describe only the finding content without transcribing the values themselves.
- Refer to AWS accounts by account alias or short label; do not include 12-digit account IDs directly.
- Only cover the scope of the target period. If no period is specified, target the previous one month.
- If a service is not enabled for that account or region, do not write "zero findings" but explicitly state "not enabled." The absence of data and the absence of findings have different meanings.
- Do not make your own severity determinations. Use the severity assigned by the service as-is.
- If the same content is detected by multiple services (e.g., an Inspector CVE also appears in Security Hub), do not count it twice; report it as one finding and note that it was detected by both.
- Write back to the memory store only conclusions worth recalling later. Do not write back API responses themselves, this month's finding counts, or compliance score values. These can be re-retrieved from the API when needed.
- Limit each memory to a single fact or lesson. Do not bundle multiple topics into a single entry.
- When writing back memories, do not create duplicate entries with the same content as existing memories. If a memory on the same topic already exists, update that memory rather than creating a new one.
## Output
Create a single artifact with the title "Security Monthly Report - <YYYY-MM>". Include the following sections.
- Summary. Show finding counts by severity for each service, with differences from last month.
- A table of Security Hub compliance scores by standard, with changes from last month.
- A list of newly identified CRITICAL and HIGH findings this month, including affected resources, detection date, and recommended remediation.
- A list of findings that remain unresolved for more than one month, sorted by longest unresolved period first.
- A list of findings resolved during the target period.
- Items requiring a decision this month. List separately from items already treated as accepted risks.
Write the report in Japanese. Stick to fact-based descriptions. For any figures that have changed, not only describe the direction of the change in words but also explicitly state the before and after values.
If the memory store could not be referenced, or was referenced but contained no relevant memories, note this at the end of the report. Make it clear to the reader that this report was created without accepted risk information.
A memory named "security-monthly-report-context" has been prepared and attached as the memory store.
Now let's run this custom agent.
When executed, you can confirm that it is referencing the attached memory.
You can also confirm in the generated artifact that the memory is being referenced as instructed by the prompt.
It was also confirmed that the custom agent is writing back memories to the memory store.
Overall Memory Limits and Store Management
Across all four items, memories share common limits regardless of whether the store is managed or custom.
| Resource | Limit |
|---|---|
| Number of memory stores per Agent Space | 50 |
| Number of memories per memory store | 200 |
| Content size of individual memory | 100 KB |
| Memory limits - AWS DevOps Agent |
Since neither the number of stores nor the number of memories is unlimited, it seems better to design stores in reasonably consolidated units rather than proliferating them across overly granular topic units.
After creation, memory stores can be viewed and managed from the Knowledge page of the Operator Web App.
The memory detail page has a version selector that allows you to scroll back through past versions to review their contents.
Additionally, both stores and individual memories can be toggled enabled/disabled without deletion.
When disabled, the agent will no longer access any memories in that store at all, which seems useful when you want to stop referencing a store without deleting it.
Closing
This time, I reviewed four memory-related items from the August 27, 2026 update to DevOps Agent.
Until now, only managed stores were available for Memories, but this update allows users to create custom stores.
The contents of created stores can be organized with folders, and what was previously called Learned Skills—automatically learned knowledge—is now handled as the same type of memory.
Furthermore, custom agents can have only the necessary stores selectively attached.
The most important factor when using memory stores is the description.
Before reading the store's contents, agents decide whether to open it based solely on the name and description, so if this is vague, the agent may skip the store even if the answer is inside it.
The official documentation also recommends writing two things in the description: "what it holds" and "when it should be used."
Folder organization works on the same mechanism as descriptions, and separating memories with prefixes like alarms/ allows the agent to open only relevant memories from the index.
It's also worth being mindful about what to retain in memory.
Memory stores are designed not as a place for notes taken during investigation or tool execution results, but as a place to retain conclusions worth recalling later.
It is also recommended to limit each memory to a single fact or lesson, and given the limit of 200 memories per store, this kind of design consideration is something to keep in mind.
Since it is now possible to design what the agent remembers and how much to pass to which agent, I think the range of approaches for using custom agents has expanded.
How to write descriptions and the granularity of information to retain in memory are points I want to keep in mind as I operate custom stores going forward.
I hope this article is helpful to someone.
That's all from Takayama (@nyan_kotaroo).
