Unified Property Management Search and Digital Assistant Using Amazon Bedrock

cbre · Other · 2025 · source Agentic: no · promotional bias: high · 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: Commercial real estate property management

CBRE needed a unified natural-language search and assistant layer for property managers who were forced to search fragmented structured and unstructured property data across many systems.

Constraints:

Property data was fragmented across 10 sources and four databases.
The system had to serve property management workflows inside CBRE's PULSE application.
Search needed to cover both transactional database records and more than eight million documents.
Generated SQL and search results had to respect granular building-level permissions.
Production latency, token cost, query accuracy, and database performance all mattered to adoption.

Architecture

CBRE built a Bedrock-centered assistant inside PULSE with two main paths: SQL Interact for structured property data and DocInteract for document search and chat. An orchestration layer routes requests, applies Redis-backed permissions, retrieves schema or document context from OpenSearch, calls task-specific models such as Amazon Nova Pro and Claude Haiku, executes secure SQL or RAG searches, stores conversation state in DynamoDB, and returns unified results to property managers.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  pulse-user-interface["PULSE user interface"] --> orchestration-layer["Orchestration layer"]
  orchestration-layer --> sql-interact["SQL Interact"]
  orchestration-layer --> docinteract["DocInteract"]
  orchestration-layer --> redis-permissions-cache["Redis permissions cache"]
  orchestration-layer --> dynamodb-conversation-store["DynamoDB conversation store"]
  sql-interact --> amazon-opensearch-schema-index["Amazon OpenSearch schema index"]
  sql-interact --> amazon-nova-pro["Amazon Nova Pro"]
  sql-interact --> property-databases["Property databases"]
  docinteract --> document-ingestion-pipeline["Document ingestion pipeline"]
  docinteract --> amazon-opensearch-document-index["Amazon OpenSearch document index"]
  docinteract --> claude-haiku["Claude Haiku"]
  document-ingestion-pipeline --> amazon-textract["Amazon Textract"]
  document-ingestion-pipeline --> amazon-titan-text-embeddings-v2["Amazon Titan Text Embeddings v2"]
  document-ingestion-pipeline --> amazon-opensearch-document-index

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`PULSE user interface`	Property managers submit natural-language search and assistant requests.	`Orchestration layer`
`Orchestration layer`	Routes requests, manages history, executes parallel search, and merges results.	`PULSE user interface`, `SQL Interact`, `DocInteract`, `Redis permissions cache`, `DynamoDB conversation store`
`SQL Interact`	Generates secure SQL from natural-language questions over structured property data.	`Orchestration layer`, `Amazon OpenSearch schema index`, `Amazon Nova Pro`, `Property databases`
`DocInteract`	Runs document search and conversational RAG over unstructured property files.	`Orchestration layer`, `Document ingestion pipeline`, `Amazon OpenSearch document index`, `Claude Haiku`
`Document ingestion pipeline`	Extracts text and embeddings from uploaded documents before indexing.	`DocInteract`, `Amazon Textract`, `Amazon Titan Text Embeddings v2`, `Amazon OpenSearch document index`
`Redis permissions cache`	Provides low-latency user-specific module, schema, and building permissions.	`Orchestration layer`, `SQL Interact`, `DocInteract`
`Amazon OpenSearch schema index`	Stores database schema metadata for retrieval before SQL generation.	`SQL Interact`
`Amazon OpenSearch document index`	Stores document chunks, metadata, keyword indexes, and vector embeddings for search.	`DocInteract`, `Document ingestion pipeline`
`Amazon Nova Pro`	Generates SQL for structured property queries.	`SQL Interact`
`Claude Haiku`	Handles document interaction, query interpretation, and image OCR tasks.	`DocInteract`
`Property databases`	PostgreSQL and SQL Server stores execute finalized property queries.	`SQL Interact`
`DynamoDB conversation store`	Maintains conversation history for follow-up document interactions.	`Orchestration layer`
`Amazon Textract`	Extracts text asynchronously from uploaded property documents.	`Document ingestion pipeline`
`Amazon Titan Text Embeddings v2`	Embeds document chunks for vector search.	`Document ingestion pipeline`

Data flow

A PULSE user asks a natural-language property question. The orchestration layer authenticates the user, retrieves permissions from Redis, routes to SQL Interact or DocInteract, retrieves database metadata or document chunks from OpenSearch, invokes the appropriate Bedrock model, applies security joins or document filters, executes the query/search, merges and ranks results, and returns an answer with conversation context.

3 supporting quotes

“An orchestration layer serves as the central control hub, receiving user requests from the PULSE UI and intelligently routing them to appropriate backend services.”summary, stated

“The pipeline begins with dynamic database metadata retrieval from an Amazon OpenSearch index, fetching schema details including table names, column names, data types, relationships, and constraints”summary, stated

“Before SQL execution, the system enhances generated queries with mandatory security joins that enforce building-level access controls, restricting users to their authorized buildings only.”summary, stated

Why this architecture

CBRE separated structured SQL and unstructured document workflows because the same user-facing assistant had to span databases, leases, inspections, emails, images, and other property documents while maintaining permission checks and low latency. Bedrock let the system choose specialized models for each subtask through one managed interface.

“The architecture is organized around two primary interaction pathways: SQL Interact for structured data and DocInteract for unstructured documents.”summary, stated

“The multi-model approach is a key architectural decision—the solution uses Amazon Nova Pro specifically for SQL query generation and Claude Haiku for document interactions.”summary, stated

Models used: Amazon Nova Pro · Claude Haiku · Amazon Titan Text Embeddings v2 · Amazon Bedrock Claude 3 Haiku

Scale

CBRE operates across more than 100 countries.
“integrated into CBRE's proprietary PULSE property management system, serving clients across more than 100 countries.”summary, stated
The source data spanned 10 data sources and four databases.
“property management professionals had to navigate 10 distinct data sources and four separate databases containing both structured transactional data and unstructured documents”summary, stated
DocInteract searched more than eight million documents.
“The DocInteract component handles unstructured document search across more than eight million documents.”summary, stated
Amazon Nova Pro reduced SQL generation time from 12 seconds to 4 seconds.
“CBRE achieved a 67% reduction in SQL query generation time, from an average of 12 seconds with previous models to just 4 seconds with Nova Pro.”summary, stated
Two-stage prompts reduced token usage by 60%.
“This architecture delivered a 60% reduction in token usage by loading only necessary prompts per query processing stage.”summary, stated
Database optimizations improved query performance by 80%.
“CBRE implemented several database-level optimizations that improved query performance by 80%.”summary, stated
The reported search accuracy reached 95%.
“The system achieves 95% accuracy in search results, providing high reliability for business decisions.”summary, stated

Alternatives considered (roads not taken)

Use one general model for all tasks

Rejected because: CBRE matched models to task strengths, using Nova Pro for SQL generation and Claude Haiku for documents.

“different models are deployed for different tasks based on their respective strengths.”summary, stated

Load all prompts and context for every request

Rejected because: A lightweight routing stage reduced token usage and loaded only the specialized context needed for execution.

“rather than loading all possible prompts and context for every query, the system uses a fast initial routing stage to determine intent, then loads only the relevant specialized context”summary, stated

Rely only on KNN vector search for schema retrieval

Rejected because: KNN sometimes returned irrelevant schemas, so CBRE added LLM relevancy scoring and reordering.

“CBRE discovered that vector search (KNN) for schema retrieval sometimes returned irrelevant schemas or poorly ordered results.”summary, stated

Perform synchronous document extraction during upload

Rejected because: Asynchronous Textract jobs avoided blocking high-throughput document processing.

“This asynchronous architecture is a critical LLMOps pattern for handling high-throughput document processing without blocking execution”summary, stated

Patterns

`rag-retrieval` (retrieval)

CBRE indexed document chunks with metadata and embeddings in OpenSearch, then used vector and metadata search to ground natural-language document answers.

“Each chunk is enriched with metadata and indexed into Amazon OpenSearch for fast semantic search. Image files follow a similar flow but use Amazon Bedrock Claude 3 Haiku for OCR after base64 conversion.”summary, stated

“The Chat with Document feature represents a conversational RAG implementation that allows users to engage in natural dialogue with specific documents after initial search.”summary, stated

`model-routing` (model operations)

The system routed SQL, document interaction, OCR, and embedding tasks to different Bedrock models rather than using one universal model.

“The multi-model approach is a key architectural decision—the solution uses Amazon Nova Pro specifically for SQL query generation and Claude Haiku for document interactions.”summary, stated

`context-engineering` (prompting)

CBRE dynamically selected schema fields, few-shot examples, business rules, and tool-specific prompts so each model call received only relevant context.

“Dynamic field selection uses KNN-based similarity search to filter and select only the most relevant schema fields aligned with user intent”summary, stated

“the system selects the single most pertinent example based on the specific query context.”summary, stated

`safety-policy-enforcement` (security)

Permissions were enforced both before retrieval and inside generated SQL with mandatory joins that restricted access to authorized buildings.

“All search operations are constrained by user-specific permissions retrieved from Redis, ensuring real-time granular access control without sacrificing performance.”summary, stated

“The security joins added to generated SQL queries provide defense-in-depth, ensuring that even if other security layers were somehow bypassed, the database queries themselves enforce access restrictions.”summary, stated

`retrieval-ranking` (retrieval)

CBRE combined vector retrieval with an LLM relevancy scoring layer to reorder schemas when KNN returned weak matches.

“they introduced a fourth parallel LLM call that evaluates the relevance of each schema returned by vector search, assigns relevancy scores, and reorders schemas based on actual relevance to the query.”summary, stated

`latency-optimization` (operations)

The SQL path used Nova Pro, parallel inference, Redis permissions, and database full-text search to reduce generation and query latency.

“The system implements parallel LLM inference for SQL generation, a sophisticated production optimization.”summary, stated

“chosen specifically for its low latency and high throughput characteristics—a critical LLMOps consideration for production systems where security checks must not create bottlenecks.”summary, stated

Tradeoffs

Task-specialized model selection

Chose Use Nova Pro for SQL generation and Claude Haiku for document interactions over A single general model for every assistant capability.

Rationale: Different model strengths improved latency and fit across structured and unstructured tasks.

“This represents a thoughtful model selection strategy where different models are deployed for different tasks based on their respective strengths.”summary, stated

“CBRE achieved a 67% reduction in SQL query generation time, from an average of 12 seconds with previous models to just 4 seconds with Nova Pro.”summary, stated

Two-stage prompt routing

Chose Detect the required tool first, then load focused execution prompts over Load all possible tools, prompts, and context for every query.

Rationale: Focused prompts reduced token usage and kept execution context specific to the task.

“The first stage is a lightweight tool detection phase that quickly routes queries to appropriate tools (Get_Document_data, keyword_search, Get_Favdocs_collections, upload_documents) based on concise tool descriptions.”summary, stated

“This reduces costs, improves performance, and maintains accuracy.”summary, stated

Async document processing

Chose S3/SQS/Lambda-triggered asynchronous Textract extraction over Blocking document extraction inside the user request path.

Rationale: Async processing kept large documents and images from blocking high-throughput search ingestion.

“When documents are uploaded to Amazon S3, an SQS message triggers a Lambda function that initiates an asynchronous Textract job.”summary, stated

“This asynchronous architecture is a critical LLMOps pattern for handling high-throughput document processing without blocking execution”summary, stated

Gotchas (what bit them)

Vector schema retrieval produced irrelevant or poorly ordered schemas.

Root cause: Embedding similarity alone did not reliably capture query-to-schema relevance.

Resolution: CBRE added a parallel LLM relevancy scoring mechanism to evaluate and reorder candidate schemas.

“CBRE discovered that vector search (KNN) for schema retrieval sometimes returned irrelevant schemas or poorly ordered results.”summary, stated

“This "LLM scoring mechanism" layer demonstrates the value of combining multiple AI techniques—using embeddings for initial retrieval but then applying LLM intelligence for refinement and reordering.”summary, stated

Context windows and token usage could balloon when every prompt and example was loaded.

Root cause: A single monolithic prompt would include irrelevant tools, schemas, examples, and business rules.

Resolution: The system uses a two-stage tool-selection architecture and dynamic example/field selection.

“This approach provides several LLMOps benefits: prompts can be version controlled, updated without code deployments (reducing update cycles from hours to minutes), A/B tested, and quickly rolled back if issues arise.”summary, stated

“This architecture delivered a 60% reduction in token usage by loading only necessary prompts per query processing stage.”summary, stated

Generated SQL could become a data-leak vector if authorization was handled only outside the query.

Root cause: Property managers had building-specific permissions that needed to survive natural-language SQL generation.

Resolution: The pipeline validates entitlements, retrieves authorized building lists, and injects mandatory security joins before execution.

“the system authenticates and validates user entitlements first, performs context-aware schema identification using similarity search, and only processes schemas for which the user has explicit authorization.”summary, stated

“the system enhances generated queries with mandatory security joins that enforce building-level access controls”summary, stated

Evaluation

CBRE evaluated the system with operational ACR metrics, search accuracy, SQL generation latency, database query performance, and token usage reductions, although the vendor case study does not fully disclose baselines or measurement conditions.

Metrics: Accuracy, consistency, and relevancy framework · 95% search accuracy · 67% SQL generation time reduction · 80% database query performance improvement · 60% token usage reduction

“At the API level, CBRE implemented optimizations targeting three key performance indicators they call ACR metrics: Accuracy (precision of results), Consistency (reproducible outcomes), and Relevancy”summary, stated

“The reported metrics (67% reduction in processing time, 80% improvement in query performance, 95% accuracy) should be evaluated with appropriate skepticism”summary, stated

Outcomes

SQL query generation time fell from 12 seconds to 4 seconds with Amazon Nova Pro.
Database query performance improved by 80%.
Two-stage prompt routing reduced token usage by 60%.
Search results reportedly reached 95% accuracy.

The system served CBRE's PULSE property management context across more than 100 countries, 10 data sources, four databases, and more than eight million documents.