Multi-Tenant AI Chatbot Platform for Industrial Conglomerate Operating Companies

capgemini · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise multi-tenant chatbot platform

Fortive needed a centralized AI chatbot platform that could serve independently operated subsidiaries without duplicating siloed chatbot work or manually remapping changing schemas.

Constraints:

Architecture

Capgemini and AWS built Fort Brain using AWS Bedrock, Fargate, API Gateway, Lambda, Bedrock Knowledge Bases, OpenSearch, MCP servers, CDK, and Terraform to provide a secure multi-tenant chatbot over live databases, documents, and repositories.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  fort-brain-web-app["Fort Brain Web App"]
  cloudfront-and-waf["CloudFront and WAF"]
  api-gateway-and-lambda["API Gateway and Lambda"]
  bedrock-agent-layer["Bedrock Agent Layer"]
  mcp-servers["MCP Servers"]
  bedrock-knowledge-bases["Bedrock Knowledge Bases"]
  structured-data-sources["Structured Data Sources"]
  unstructured-document-sources["Unstructured Document Sources"]
  software-repositories["Software Repositories"]
  fort-brain-web-app --> api-gateway-and-lambda
  fort-brain-web-app --> cloudfront-and-waf
  cloudfront-and-waf --> fort-brain-web-app
  api-gateway-and-lambda --> fort-brain-web-app
  api-gateway-and-lambda --> bedrock-agent-layer
  bedrock-agent-layer --> mcp-servers
  bedrock-agent-layer --> bedrock-knowledge-bases
  mcp-servers --> structured-data-sources
  mcp-servers --> software-repositories
  bedrock-knowledge-bases --> unstructured-document-sources
  structured-data-sources --> mcp-servers
  unstructured-document-sources --> bedrock-knowledge-bases
  software-repositories --> mcp-servers
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
Fort Brain Web App Provides the unified user interface for operating-company users. API Gateway and Lambda, CloudFront and WAF
CloudFront and WAF Provides content delivery and web security. Fort Brain Web App
API Gateway and Lambda Routes requests and injects context into Bedrock agents. Fort Brain Web App, Bedrock Agent Layer
Bedrock Agent Layer Coordinates SQL query agent and action group agents. MCP Servers, Bedrock Knowledge Bases
MCP Servers Connect Bedrock agents to live PostgreSQL and repository tools. Structured Data Sources, Software Repositories
Bedrock Knowledge Bases Provide retrieval over SharePoint and document collections using OpenSearch. Unstructured Document Sources
Structured Data Sources RDS, Snowflake, SQL, PostgreSQL, and Oracle systems. MCP Servers
Unstructured Document Sources SharePoint, Jira, Confluence, and S3 document collections. Bedrock Knowledge Bases
Software Repositories GitLab, Bitbucket, GitHub, and code systems exposed to agents. MCP Servers

Data flow

Users access a CloudFront/WAF-protected web app on Fargate. API Gateway and Lambda route requests to Bedrock agents. A SQL query agent classifies the data source, action group agents call MCP servers or knowledge bases, and answers draw from live structured or unstructured sources.

“The backend orchestration layer relies on API Gateway and Lambda functions to handle request routing and context injection.”summary, stated
“The first agent, referred to as the SQL query agent, performs prompt preprocessing and determines which data source needs to be queried based on the user's natural language input.”summary, stated

Why this architecture

Fort Brain uses serverless multi-tenancy and MCP because subsidiaries need a shared governed platform that can query live changing data instead of static knowledge snapshots.

“MCP servers were implemented to connect to GitHub repositories and PostgreSQL databases, allowing the system to query live data without requiring knowledge base updates or reindexing.”summary, stated
“Each OpCo's data remains isolated, with governance and security controls enforced centrally by the platform”summary, stated

Models used: AWS Bedrock foundation models · Bedrock Agents

Scale

Alternatives considered (roads not taken)

Static chatbot knowledge bases

Rejected because: They required remapping and retraining whenever data structures changed.

“replace a previous static chatbot implementation with a dynamic, scalable, and secure platform”summary, stated

Separate OpCo chatbot development

Rejected because: Siloed development would duplicate work and fail to enforce shared governance.

“the challenge of disparate data sources and siloed chatbot development across operating companies”summary, stated

Patterns

tool-use-orchestration (architecture)

Bedrock agents use MCP servers to query databases and repositories and potentially perform actions.

“MCP approach also supports actions beyond querying, including starting workflows, committing code to Git repositories, and adding rows to databases.”summary, stated

rag-retrieval (retrieval)

Bedrock Knowledge Bases and OpenSearch provide retrieval over unstructured document sources.

“using OpenSearch as the vector database for efficient retrieval.”summary, stated

safety-policy-enforcement (governance)

Multi-tenant data segregation and central governance controls protect operating-company data boundaries.

“A fundamental requirement was maintaining strict data segregation across operating companies.”summary, stated

Tradeoffs

Use serverless managed AWS components

Chose Fargate, API Gateway, Lambda, Bedrock, and Knowledge Bases over Self-managed orchestration stack.

Rationale: The POC needed rapid deployment, multi-tenant governance, and minimal operational overhead.

“This containerization approach offers deployment flexibility without the operational overhead of managing container orchestration infrastructure.”summary, stated

Mandate infrastructure as code

Chose AWS CDK and Terraform with no manual console access over Manual AWS changes during the POC.

Rationale: Reproducibility and deployment across operating companies required code-defined infrastructure.

“no manual AWS console access should be used, requiring all infrastructure changes to flow through code in deployment pipelines.”summary, stated

Gotchas (what bit them)

Static knowledge snapshots stale quickly against live business data.

Root cause: Database schemas and operational data change without knowledge-base refreshes.

Resolution: Use MCP servers to query live databases and repositories.

“receive current data immediately, rather than waiting for a weekly batch update cycle.”summary, stated

Connector choice can compromise access-control fidelity.

Root cause: The POC used Bedrock's web crawler connector for SharePoint due to time constraints.

Resolution: Plan migration to the native SharePoint connector for proper security requirements.

“they plan to migrate to the native connector in future iterations to properly handle security requirements and organizational access controls.”summary, stated

Evaluation

The case describes POC delivery and architectural capabilities but does not publish accuracy or production-usage benchmarks.

Metrics: POC delivery time · query latency goal · data-source coverage

“providing a familiar and fast user experience that could deliver answers in seconds rather than minutes.”summary, stated

Outcomes

The platform targets Fortive's 18,000 employees, 50 countries, and multiple operating companies.

“providing real-time access to operational data across all operating companies.”summary, stated