{
  "id": 3199373,
  "title": "Why I'm Building an AI Layer on Top of Your CRM (Not a New One)",
  "url": "https://urgent.news/2026/08/25/why-im-building-an-ai-layer-on-top-of-your-crm-not-a-new-one",
  "topic": "ai",
  "section": "AI",
  "published": "2026-08-25T05:26:39.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/rakno/why-im-building-an-ai-layer-on-top-of-your-crm-not-a-new-one-5c91"
  },
  "original_language": "en",
  "account": "The author of this piece reflects on their journey to build an artificial intelligence layer on top of existing customer relationship management (CRM) systems, rather than replacing them entirely. Working for a PropTech platform with numerous users and agents across various departments, each relying on a separate CRM filled with leads, bookings, payments, inventory, and documents, the author observed a critical issue: the lack of a quick and efficient path from a question to an answer.\n\nWhile the CRM might contain the necessary data, accessing it can be cumbersome. Agents often have to open filter panels, set conditions, wait for tables to load, export data to CSV, and share it in Slack. This process can easily take a minimum of three minutes per query. When multiplied across 40 agents performing 20 queries daily, the inefficiency becomes evident.\n\nRather than replacing the CRM, the proposed solution is to create an AI layer that integrates with any existing CRM, enabling each department to access their own data through a natural language interface. This approach is referred to as Company/OS—a plug-and-play AI operating layer designed to embed into any CRM and provide departments with instant access to their data using everyday language.\n\nThe system employs three main components:\n\n1. Business Knowledge Graph: This system gathers information from the company's codebase, product requirements documents (PRDs), database schema, Slack conversations, and Jira tickets. It then builds a property graph in Neo4j, connecting entities, relationships, and business rules. This graph allows for traversable context, enabling agents to move from one data point to another, such as from a lead node to its assigned agent, communication history, booking status, and property preferences.\n\n2. Multi-Layer Memory Context: This component stacks five layers of memory on top of each other. The Global layer holds information that is true across all tenants, while the Company layer contains specific terminology such as \"BSU,\" \"qualified lead,\" and booking state machines. The Department layer defines what each department, such as Sales, Finance, or Audit, can see and query. The User layer tracks individual patterns, and the Conversation layer represents the ephemeral session state of interactions.\n\n3. Department Packs: These are pre-built vertical bundles that include workflows, query templates, and reasoning skills tailored for specific teams. For instance, the Sales Pack knows about lead scoring, follow-up cadences, and conversion funnels, while the Finance Pack handles invoice reconciliation, commission calculation, and multi-currency settlements. The Audit Pack focuses on compliance checks, document verification, and anomaly flagging. These packs function much like Salesforce AppExchange, offering already trained assistant modules for specific teams that can be installed in just ten minutes.\n\nThe author emphasizes that the distribution strategy—whether to build a layer or replace the CRM—must drive the architecture decisions rather than the other way around. Building a new CRM would involve significant migration, training, and change management, leading to long sales cycles and high risk of churn. Instead, an API key and widget embed provide immediate access, preserving the existing CRM and only changing the query interface.\n\nThe author also notes that the TAM (Total Addressable Market) of every CRM combined is larger than the TAM of a new CRM, underscoring the potential reach of this AI layer approach. Additionally, the schema ingestion process for the knowledge graph was found to be underspecified due to messy real database schemas, requiring a cleaning and annotation layer. Moreover, the Department Pack structure necessitated user research before final implementation.\n\nRegarding LLM (Large Language Model) routing, the author initially spent time optimizing the routing logic, only to realize that the real question was which reasoning mode should be the default. Advisor, which handles 70% of queries, emerged as the most effective default mode. This insight suggests that further user research and iteration are essential before expanding the Department Packs to include more workflows based on insights from agents at different companies.",
  "summary": "Every AI startup in B2B SaaS is pitching the same thing: replace your CRM with our AI-native one. I spent six months thinking that was the right answer. Then I watched what actually happens inside a sales floor. The Problem I work at a PropTech platform with millions of users and several hundred agents across sales, supply, finance, and audit. Each team has a CRM. Each CRM is full of data —…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}