The layer the reboot was preparing for
Two articles ago, we argued that your legacy CRM is not the problem, the rigidity around it is. Last time, we walked the first three layers of the reboot: the record containerised on Kubernetes, its data streaming through open CDC into PostgreSQL and OpenSearch, modern screens on the workflows that matter.
Every one of those moves was worth making on its own. But together they were quietly preparing the ground for the layer that changes what the CRM is: intelligence, inside the system, where the work happens.
Our first series found that enterprise AI wins in exactly one place - embedded in the workflow people already have and dies in standalone portals. There is no workflow more lived-in than the CRM case screen a service agent keeps open all day. The reboot has now made that screen a place AI can work: the data is fresh, open, and query able; the screens are modern enough to host an assistant; and all of it runs on infrastructure you control.
The open retrieval stack
The pattern that delivers AI inside the CRM is retrieval-augmented generation, and the reboot lets you build it entirely on open foundations.
The replica you built in the data layer becomes the retrieval substrate. PostgreSQL with pgvector holds embeddings beside the relational records it already serves; OpenSearch adds keyword and vector search across the document corpus. On top sits a retrieval layer with one non-negotiable property: it respects the same permissions the records and documents already have. An agent asking about a case retrieves only what that agent is allowed to see.
Readers of our first series will recognise the standards that apply here. The document corpus must pass the four tests - curated, owned, current, access-controlled. The difference is that the reboot has already done much of the heavy lifting: the record data is current by construction, because it streams; and it is governed by construction, because it inherits the CRM’s own rules.
The open AI stack, end to end
Records and documents, finally linked
Here is where the assist becomes something a chatbot never was. Enterprise knowledge lives in two worlds: the structured record that says what happened - cases, orders, entitlements, dates and - the unstructured document that explains why and what to do - policies, guides, past resolutions.
Humans join these two worlds in their heads, slowly. The assist joins them in the retrieval layer, instantly. When a warranty case opens, it reads the record: this customer, this product, this entitlement, three previous cases. Then it retrieves the documents that govern the situation: the warranty policy version in force when the product shipped, the troubleshooting bulletin for that fault code. The draft answer cites both and the agent verifies either in one click.
That join is the real unlock of the reboot’s data layer. It was never just about faster reporting. It was about making the record and the knowledge around it retrievable together, so an AI system can answer the way a twenty-year veteran would, from the history and the handbook at once.
Records and documents, linked
Open models, where the data lives
Now the question every CRM owner is being asked by every vendor: which AI subscription would you like with that?
The reboot offers a different answer. Open-weight models - the current Qwen 3, DeepSeek, and Llama 4 generation and their successors have reached the quality bar that agent assist, summarisation, and drafting require. They run on infrastructure you own, beside the data they answer from. Nothing leaves. For enterprises with data-sovereignty obligations and every CRM is full of customer data that is not a nice-to-have; it is the difference between deployable and undeployable.
Then there is the economics. Per-seat AI pricing is the licence model reborn: it scales with your headcount, not your usage, and it re-creates precisely the lock-in the reboot exists to escape. A self-hosted open model inverts this: you pay for compute, the cost per query is measurable and falls as you optimise, and scaling from ten agents to a thousand changes the numerator, not the deal. Our first series said production AI must be paid for on unit economics you understand. This is what that looks like in practice.
The per-seat tax vs. owned economics
In the case screen, not beside it
The last piece is the one users see, and it is deliberately the smallest: the assist lives inside the case screen the UI layer already modernised. A summary panel when the case opens. Retrieved knowledge with sources shown. A drafted reply the agent reviews, edits, and owns.
Everything our first series learned applies without modification: the human stays in the loop; the sources are always visible; the metrics were already being tracked - handling time, first-response time, right-first-time. The AI does not replace the conversation. It replaces the digging.
And note what it does not require: no new portal, no new login, no adoption campaign. The assist appears where the work already happens, which is why it gets used and keeps being used in month three.
One layer left and the finale
Look at what the rebooted stack has become: a trusted record, open data infrastructure, modern screens, and intelligence that answers from your own knowledge at costs you control. Every layer owned. Every layer replaceable. No landlord.
One question remains, and it is the finale’s: what is this architecture, really? When the record is stable, the data flows, and the intelligence is a layer rather than a product, where does CRM go next, and where do agents fit? The last article names the destination: the composable CRM.