Agent Retrieval Needs More Than One Table
AWS combines operational records and vector search in DynamoDB, but the architecture trades duplicated stores for stricter schema and event-pipeline discipline.
Source: AWS Architecture Blog: Build a unified AI agent architecture with DynamoDB and Bedrock
TL;DR
AWS proposes a unified AI-agent design in which one DynamoDB table supports operational lookups and vector search, while DynamoDB Streams trigger Lambda jobs that generate Titan Text Embeddings V2. The design can remove duplicated stores and cross-system synchronization, but it does not remove complexity. Schema evolution, embedding freshness, stream semantics, hot partitions, permissions, and failure recovery become part of the same operating boundary. Netics’ decision rule: consolidate when the data lifecycle is truly shared, not merely because fewer services look cleaner on a diagram. The article covers the duplication AWS is solving, where the architecture earns its keep, and the failure modes hidden by consolidation.
The duplication problem AWS is solving
Teams often store business records in one system and embeddings in another. That separation can be reasonable, but it creates a synchronization path. A document changes in the operational store, an event must trigger an embedding update, and retrieval must know whether both copies are current.
AWS frames its design around a single DynamoDB table that supports both structured access and semantic similarity search. A Bedrock agent can retrieve a document by identifier, answer a semantic question, or update an existing record through different action-group paths.
That is a useful architectural target: one record lifecycle, one primary ownership model, and fewer opportunities for a vector copy to drift away from the source record.
What the unified design actually changes
The solution uses an Amazon Bedrock agent to interpret a request and invoke an action-group Lambda. For semantic retrieval, the function generates a query embedding and calls DynamoDB’s SearchVectors API. For operational lookups, it uses standard CRUD operations against the same table.
When content changes, DynamoDB Streams captures the event. An embedding pipeline Lambda calls Amazon Titan Text Embeddings V2, then writes the vector back to the same DynamoDB item. The vector index can then index that representation without a second system owning a competing copy of the document.
The important detail is not the number of boxes. It is the ownership of freshness. The table holds the content and its embedding, while the stream provides the trigger that keeps the derived field updated.
Where the architecture earns its keep
This approach is attractive when four conditions are true:
- The records are naturally modeled as DynamoDB items.
- Semantic retrieval and operational lookup use the same content lifecycle.
- The team can accept DynamoDB as the operational and retrieval boundary.
- The embedding pipeline can tolerate asynchronous freshness.
A single table can reduce the operational overhead of maintaining a separate vector store or OpenSearch cluster. It can also simplify permissions and backups because the organization has one main data boundary to protect.
But those benefits depend on the workload. If the vector index has a very different scale, latency profile, retention policy, or tenancy model, forcing it into the same system may turn consolidation into coupling.
The failure modes hidden by consolidation
A unified design still has several failure paths.
Embedding freshness can lag. A successful write does not necessarily mean that the new content is already represented by the vector. Applications need a clear behavior for a record that is operationally current but semantically stale.
The stream can loop. AWS calls out the need for NEW_AND_OLD_IMAGES. The embedding function compares old and new content and skips processing when only the embedding attribute changed. Without the old image, the guard cannot reliably distinguish a content change from its own derived-field write.
Schema changes become retrieval changes. Adding or renaming fields can affect both CRUD behavior and the text sent to the embedding model. A migration must account for index compatibility, re-embedding, and rollback rather than treating the vector as an invisible cache.
The agent boundary still matters. A Bedrock agent that can read and update the same table needs action-level permissions, validation, audit trails, and limits. Fewer stores do not mean fewer dangerous tool calls.
A decision rule for European teams
Netics would use the unified pattern when the team can answer yes to these questions:
- Is DynamoDB already the system of record for the content?
- Is semantic retrieval part of the same bounded workflow?
- Can the team define acceptable embedding staleness?
- Can every write, re-embedding action, and agent tool call be audited?
- Is the data residency and provider-governance decision already acceptable?
If the answer to the first two questions is no, a separate retrieval system may be a cleaner boundary. If the answer to the last two is no, the problem is governance, not database selection.
This is consistent with the broader Netics principle that platform choice follows the operating boundary. A working AI model is not production-ready because the model works: the same applies to a tidy architecture diagram.
FAQ
Does one DynamoDB table eliminate synchronization?
It removes synchronization between a primary operational store and a separate vector store, but the embedding field still has to be updated through the Streams and Lambda pipeline.
Why does AWS require NEW_AND_OLD_IMAGES?
The pipeline compares old and new content to avoid repeatedly processing its own embedding update. Without the old image, the write-loop guard cannot work as intended.
Is this architecture suitable for every RAG system?
No. It is strongest when operational records and semantic retrieval share a lifecycle, scale, and governance boundary. Different workloads may justify separate stores.
Netics’ conclusion
Book a free 30-minute audit if your retrieval architecture needs a clear data and failure boundary.
AWS’s unified pattern is a useful reduction of one kind of infrastructure duplication. It is not a promise that the system becomes simple. The store boundary disappears, while schema design, embedding freshness, event semantics, permissions, and recovery become more important. Consolidate when the lifecycle is genuinely shared. Otherwise, fewer boxes may only hide the boundary you still need to operate.
Source: AWS Architecture Blog, Build a unified AI agent architecture with DynamoDB and Bedrock — https://aws.amazon.com/blogs/architecture/build-a-unified-ai-agent-architecture-with-dynamodb-and-bedrock/
Explore Netics for practical infrastructure and AI operations guidance.