AI Agent Memory on AWS: How We Apply the Knowledge Store Pattern
The memory behind your AI agents, built in your own cloud account: current, traceable and affordable.
About this page. Aitina Tech’s R&D wing applies the research of Imtiaz Hassan, published as The Software Lens, in client work and in our own product. This page is the applied view: what the pattern is, how we build it, and what an engagement looks like. The full research is on The Software Lens.
When an AI assistant gives a wrong or out-of-date answer, the cause is usually what it remembers, not the model. We build the memory behind agents so that answers are current, every answer can be traced to what the agent read, and the running cost stays in proportion.
From the research
“Three kinds of memory, one source of truth, and a store that can correct itself, on whichever cloud you already use.”
What we take from it. Memory is a design decision, not a database purchase. We start every agent engagement by asking which of the three questions your agents will ask, and build only the tiers that answer them.
How we apply it
Most first attempts at agent memory are a single vector database with everything embedded into it. It finds text that looks right and cannot tell which version is current, who approved it or whether this agent is allowed to see it. The Knowledge Store pattern separates the three jobs: a vector index for similarity, a graph for relationships and supersession, and a structured record store that is the single source of truth. Writes land in the records first; the other two tiers are derived from them and can be rebuilt.
On AWS we build it from managed services in your own account: Amazon DynamoDB or Aurora PostgreSQL for the records, Amazon S3 Vectors or OpenSearch Serverless for similarity, Amazon Neptune for relationships, and Amazon Bedrock Knowledge Bases as the retrieval layer the agents call. S3 Vectors is available in the Ireland region, which matters for data residency. The same design runs on Azure (Cosmos DB, Azure AI Search, Cosmos DB for Gremlin) and on Google Cloud (Spanner, AlloyDB AI, Spanner Graph). This is the work behind our LLM platform on AWS Bedrock and data and knowledge platform services.
The part most teams skip is the operating discipline: rebuild drills for the derived tiers, a written plan for changing the embedding model, customer-managed encryption keys, read logging and scope checks on every query. We set those up as part of the build, not as a later phase.
What an engagement looks like
A first engagement is usually a short design study: which tiers you actually need, which services fit your account and your data-residency obligations, what it will cost to run at your volumes, and a migration path from whatever retrieval you have today. The build that follows is delivered in your own cloud account, with the operating runbook handed over.
The research behind it
This page is Aitina Tech’s applied account of The Knowledge Store Pattern: How to Build AI Agent Memory on AWS, Azure or Google Cloud, by Imtiaz Hassan, published on The Software Lens. The full argument, the diagrams and the worked examples are there; this page is what we do with it for clients.
Watch the episodeAdopt AI Wisely In Your OrganizationThe Software Lens on YouTube →