Multi-Surface Agentic Analysis for Commercial Real Estate

The Problem

Commercial real estate valuation and analyst work is a repeatable workstream, but it lived in whichever app someone had open. A catalog UI, Slack, and Claude Desktop each needed the same capabilities. Duplicating that logic per surface would drift immediately.

The Architecture

flowchart TB
  subgraph surfaces [Client Surfaces]
      UI[Catalog UI]
      Slack[Slack]
      Claude[Claude Desktop]
      Other[Other MCP Clients]
  end

  subgraph mcp [Governed MCP Hub]
      Registry[Capability Registry]
      Policy[Policy and Audit]
      Tools[Valuation Tools]
  end

  subgraph resources [CRE Resources]
      Comps[(Comps and Market Data)]
      Financials[(Asset Financials)]
      Models[Valuation Models]
  end

  UI --> mcp
  Slack --> mcp
  Claude --> mcp
  Other --> mcp

  Registry --> Tools
  Policy --> Tools
  Tools --> Comps
  Tools --> Financials
  Tools --> Models

One Hub, Many Surfaces

The MCP hub is the product. Clients do not own the valuation logic; they call it.

1. Catalog UI — browse and try entitled capabilities
2. Slack — kick off or continue a workstream from the thread where the deal is already being discussed
3. Claude Desktop — same tools, in a desktop agent that already has the analyst’s local context
4. Anything else that speaks MCP — new surfaces attach without rewriting the workstreams

Tech Stack

• MCP — governed hub and capability registry
• Claude — model layer
• Catalog UI, Slack, Claude Desktop — call surfaces

The Impact

Analysts run the same CRE valuation and analyst workflows from whichever surface they are already in. The hub is the contract: add a client, keep the analysis.