AWS published a blog post and accompanying GitHub repository on August 31, 2026, walking through how to build multitenant agentic chat applications on Amazon Bedrock Managed Knowledge Base. The authors, George Belsian, Dani Mitchell, and Omar Elkharbotly, all AWS solutions architects, focus on a specific and common enterprise pattern: a user uploads a document and immediately expects to ask grounded questions about it, while every other user on the same platform is guaranteed never to see that document in their own results.

That second part is the actual engineering problem. Building a chat interface over a single knowledge base is a solved problem at this point. Keeping hundreds or thousands of tenants' documents cleanly separated while an agent runs multi-hop retrieval underneath a conversational interface is not, and AWS's post treats that isolation requirement as the central design constraint rather than an afterthought.

The post is technical, not a product launch. Amazon Bedrock Managed Knowledge Base itself became generally available on June 17, 2026, according to AWS's own "what's new" announcement. This new post is a reference implementation built on top of that existing service, aimed at teams who already have Bedrock access and want a working blueprint instead of building the ingestion and isolation logic from scratch.

What AWS Actually Published

The post describes an architecture with two data flows: document ingestion and conversational retrieval. A user signs in through Amazon Cognito, uploads a document, and the application extracts a verified identity from the resulting JSON Web Token. That identity, not anything the client sends, becomes the tenant boundary for every downstream step.

The stack behind it is standard AWS serverless plumbing: Amazon API Gateway and AWS Lambda handle the upload, status, and chat endpoints; Amazon SQS decouples the upload request from the actual ingestion work so the browser isn't blocked; Amazon DynamoDB tracks each document's indexing status; and Amazon S3 stages any file larger than the inline upload limit. The knowledge base itself handles parsing, embedding, storage, and ranking, which AWS frames as the "undifferentiated work" a team would otherwise have to build and operate itself.

Files up to 6 MB are sent inline in the API call. Larger files, up to 50 MB for text, are staged to S3 first and ingested by reference. A single IngestKnowledgeBaseDocuments call accepts up to 10 documents at once, which AWS says is the main lever for ingestion throughput. Their own example: 500 users uploading a document at roughly the same time turns into about 50 batched API calls rather than 500 individual ones, if a worker packs them properly.

The Indexing Lifecycle Is Asynchronous, and That Matters for UX

A document moves through five states after upload: STARTING, PENDING, IN_PROGRESS, TEXT_INDEXED, and INDEXED. Only at TEXT_INDEXED and above is the document actually queryable. AWS reports internal testing numbers for small documents against an idle knowledge base: plain text reaches queryable status in 2 to 3 seconds, while a PDF reaches TEXT_INDEXED (text-only search) in 5 to 30 seconds and full INDEXED status, which covers embedded images and tables, in about 90 seconds. AWS is explicit that these are order-of-magnitude reference numbers from their own tests, not a service-level commitment, and that real timing depends on document size, Region, and load on the knowledge base.

The practical takeaway AWS calls out directly: mark a document as "ready" in your UI once it hits TEXT_INDEXED, not STARTING. Querying a document that's still mid-ingestion just returns empty results, which is a bad user experience for something as simple as "why can't I ask about the file I just uploaded."

How Per-User Isolation Actually Works

This is the part of the post doing the real work. AWS lays out two options: a separate knowledge base per tenant, or one shared knowledge base with every query scoped by a metadata filter. For applications with many end users, they recommend the shared approach, since per-tenant knowledge bases run into account-level quotas, the fixed cost of maintaining many small indexes, and provisioning delay at signup. Per-tenant knowledge bases still make sense, in their telling, for a small number of large tenants that need strict, dedicated separation.

In the shared model, every document gets tagged with a user_id metadata attribute derived from the caller's Cognito sub, and every query carries an explicit equals filter on that same attribute, built server-side from the verified token rather than trusted from the request body. AWS also notes the knowledge base can infer a filter from the wording of a question, but is careful to say that's a relevance feature, not an access control mechanism. The actual security boundary is the explicit, server-derived filter. As a second layer, the reference implementation also discards any retrieved chunk whose user_id doesn't match the caller before it ever reaches a response.

Retrieval Runs Through a Single Streaming API Call

Questions go through the AgenticRetrieveStream API, which handles a full chat turn: it decides whether a question needs one retrieval or several, applies the per-user filter to every one of those retrieval hops, and streams back a cited, grounded response when generateResponse is enabled. AWS notes that Managed Knowledge Base does not support the older RetrieveAndGenerate API, and that teams needing more control, such as a custom prompt per tenant, should use the plain Retrieve API paired with their own Converse call.

On cost, AWS says the managed models path bills only for storage and retrieval calls, with ingestion carrying no separate charge; teams that bring their own Bedrock model instead pay for embedding tokens at ingestion plus generation tokens at query time.

Why It Matters

This isn't AWS's first attempt at solving multi-tenant isolation for Bedrock-backed applications, and that history is worth knowing. AWS published a post on multi-tenant RAG patterns using Bedrock Knowledge Bases back in December 2024, laying out silo, pool, and bridge deployment models for tenant separation. In May 2026, a separate post extended the same isolation problem to Bedrock AgentCore agents specifically. This August 31 post narrows all of that down to one concrete, deployable reference implementation with a GitHub repo attached, rather than a set of architectural options to weigh.

That progression tells me AWS keeps hearing the same request from enterprise customers and keeps trying to close the gap between "here are your isolation pattern options" and "here is working code." It also tells me the underlying problem, keeping one tenant's documents provably invisible to another tenant while an agent runs multiple retrieval hops behind the scenes, is hard enough that it's taken AWS multiple posts and roughly 20 months to get from pattern description to a repo you can actually deploy. Teams evaluating this shouldn't assume the isolation logic is fully solved for them just because a managed service is doing the retrieval; the reference implementation still adds its own defense-in-depth check by discarding mismatched chunks, which suggests AWS itself doesn't treat the metadata filter alone as sufficient.

For teams already building on Amazon Connect for agentic voice workflows or watching how Amazon OpenSearch Service is adding agentic observability tooling, this post fits a broader pattern of AWS shipping narrower, more opinionated reference architectures for agentic workloads rather than leaving teams to assemble the primitives themselves. It's a similar instinct to what showed up in AWS's recent SageMaker Feature Store updates, where batch operations replaced manual looping. The through-line across all of it is fewer raw APIs, more batteries-included patterns.

What to Watch

The accompanying GitHub repository is the thing to actually test rather than take AWS's indexing-time numbers at face value, since those figures came from AWS's own idle-knowledge-base testing and will vary under real production load. Worth watching for confirmation or contradiction: whether third-party teams deploying this pattern see similar TEXT_INDEXED timing under concurrent multi-tenant load, and whether AWS extends document-level access control lists, which it mentions as an option for regulated workloads, into a more prominent path in a future post.

Key Takeaways

  • AWS published a reference architecture and GitHub repo on August 31, 2026, for multi-tenant agentic document chat apps built on Amazon Bedrock Managed Knowledge Base, which went generally available in June 2026.
  • The isolation approach uses a server-derived user_id metadata filter built from a verified Cognito JWT, applied to every retrieval hop, with the reference implementation also discarding any mismatched chunk as a second check.
  • Documents move through five indexing states, and AWS recommends marking a document ready in the UI at TEXT_INDEXED rather than waiting for full INDEXED status.
  • This is AWS's third public post addressing multi-tenant isolation for Bedrock-backed applications since December 2024, each one narrower and more implementation-ready than the last.

FAQ

What does 'multi-tenant' mean in an AI chat application, and is that the same as a multi-tenant building?

No, they're unrelated concepts that happen to share a term. A multi-tenant building is a real estate term for a property leased to multiple separate businesses. In software, multi-tenant means one application instance and one backend, in this case a single Amazon Bedrock Knowledge Base, serving many customers or users whose data must stay isolated from each other despite sharing the same infrastructure. AWS's post is entirely about the second meaning.

What is agentic retrieval in Amazon Bedrock Knowledge Base?

It's the API-level behavior where, instead of running one fixed retrieval per question, the system decides how to answer it. For a simple lookup it issues a single retrieval; for a complex or multi-part question it decomposes the question into sub-queries and runs several retrievals before generating a response. AWS calls this multi-hop retrieval, and it's accessed through the AgenticRetrieveStream API, which streams back a cited answer.

What is a multi-agent system in agentic AI, and does this AWS guide describe one?

Not quite, and it's a common mix-up worth clearing up. A multi-agent system generally refers to multiple distinct autonomous agents, each handling a different role or task, coordinating with each other. What AWS describes in this post is a single agentic retriever performing multi-hop retrieval, meaning it breaks one question into several retrieval steps internally, which is a different pattern from multiple agents collaborating.

How do you build a multi-agent system on AWS?

This particular post doesn't cover that case directly, since it's about a single retrieval agent grounding a document chat app. For actual multi-agent orchestration, AWS's own Bedrock Knowledge Bases documentation notes that Managed Knowledge Base can be configured as a retriever inside agent frameworks such as Strands Agents, LangChain, CrewAI, and LlamaIndex, which are the tools built for coordinating multiple agents rather than running one agent's internal retrieval steps.

How do I build an agentic chat app on Bedrock, based on this guide?

At a high level, per AWS's post: authenticate users through Amazon Cognito, route uploads through a queue (Amazon SQS in AWS's example) into the IngestKnowledgeBaseDocuments API tagged with the user's verified identity, track indexing status in a database like DynamoDB, and query through AgenticRetrieveStream with a server-built filter scoped to that same identity. AWS provides a deployable version of this exact setup in its GitHub repository.