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.
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 — leads, bookings, payments, inventory, documents.
The problem isn't the CRM. The problem is that there's no fast path from a question to an answer.
An agent wants to know: "Which leads from this university haven't been followed up in 7 days?" To answer that, they open a filter panel, set four conditions, wait for the table to load, export to CSV, and share it in Slack. Three minutes minimum. Multiply by 40 agents, 20 queries a day.
The data exists. The access is broken.
The obvious fix is: replace the CRM. The actual fix is: make the CRM speak.
That's what I'm building — Company/OS, a plug-and-play AI operating layer that embeds into any existing CRM and gives every department a natural language interface to their own data.
Company/OS has three core components.
The system ingests your codebase, PRDs, database schema, Slack conversations, and Jira tickets — then builds a property graph in Neo4j connecting entities, relationships, and business rules.
# Simplified graph node structure
class BusinessEntity(BaseModel): id: str
type: Literal["table", "field", "workflow", "metric", "team"]
label: str
properties: dict
relationships: list[Relationship] This isn't a vector store. A vector store gives you semantically similar chunks. A graph gives you traversable context — from a lead node, follow edges to its assigned agent, its communication history, its booking state, its property preference. That's the difference between retrieval and reasoning.
Context collapses fast in LLM systems. Company/OS uses five memory scopes stacked on top of each other:
Global → Company → Department → User → Conversation
Global holds facts true across all tenants. Company holds specific terminology — what "BSU" means, what a "qualified lead" threshold is, what the booking state machine looks like. Department scopes what Sales vs Finance vs Audit can see and query. User memory tracks individual patterns. Conversation is ephemeral session state.
When an agent asks "show me this week's drop-offs," the system resolves "drop-offs" through Company memory (not a generic definition), scopes the data to their department, and personalises the output format to their previous preferences.
This is the GTM layer. A Department Pack is a one-click vertical bundle: pre-built workflows, query templates, and reasoning skills for a specific team.
Sales Pack knows about lead scoring, follow-up cadences, and conversion funnels. Finance Pack knows about invoice reconciliation, commission calculation, and multi-currency settlements. Audit Pack knows about compliance checks, document verification, and anomaly flagging.
The model here is Salesforce AppExchange — not "here's a blank AI assistant, configure it yourself," but "here's Sales Assistant, already trained on sales workflows, installable in 10 minutes."
Five reasoning modes handle different query types behind the scenes:
Mode Handles
Search Find this record
Advisor What should I do next
Executor Take this action
Analyst Aggregate and surface insights
Developer Explain this codebase or schema
The decision to build a layer, not a replacement, was primarily a distribution decision.
A new CRM requires migration — data migration, workflow migration, training, change management. Enterprise sales cycles of 6–18 months. High friction, high churn risk.
A layer requires an API key and a widget embed. You're live in a day. The CRM stays. The agents' muscle memory stays. Only the query interface changes.
It also means I can target any CRM — Salesforce, HubSpot, custom-built internal tools. The TAM of "every CRM" is larger than "our CRM."
Schema ingestion is underspecified. I underestimated how messy real database schemas are — column names like c1_fk_ref_v2, no foreign key constraints, zero documentation. The ingestion pipeline needs a cleaning and annotation layer before the graph can be useful.
The Department Pack structure needs user research before it needs code. I built Sales Pack based on what I know a sales agent needs as per my experience. That's one company. Before adding more packs, I need to interview agents at three other companies and find the 20% of workflows that cover 80% of the queries.
LLM routing is a product decision, not an engineering one. I spent two weeks optimising the LangGraph routing logic before realising the real question was: which reasoning mode should be the default? Advisor turned out to be 70% of queries. I should have instrumented that before building the other four modes.
TL;DR