The end of the CRM era starts with the people who stop logging in.

Last week a founder I respect sent a one-line message into a Slack channel of his peers: hi! anyone using Monaco for their CRM? can share experiences with it? (And/or recommendations on AI-native CRMs to use.)

The replies arrived within an hour. One operator named the tool he'd picked. Another said they'd sat through a demo and the rep ghosted. A third — the one I found most interesting — said the quiet part out loud: their sales rep ghosted me after we did the demo call, and I asked some questions about what they do. My sense is they are more focused on the CRM aspect, we cared a lot more about the prospecting and outbound functionality.

Read that again. He was shopping for a CRM. When he sat in the demo, what he actually wanted was something else. The CRM, the thing the category is named after, was the part he didn't care about.

This is the pattern under the question everyone is asking.

The question used to be Salesforce or HubSpot. The answer was always the same: whichever one your team will actually update.

For the last eighteen months, the conversation in every founder Slack, every YC batch group, every operator forum has narrowed to a single sentence: which AI-native CRM should we use?Clarify. Attio. Day.ai. Monaco. The list keeps growing, and every quarter a new name lands on it. The cadence of the conversation is identical to the conversation thirty years ago, when the question was Siebel or Onyx. It's identical to the conversation fifteen years ago, when the question was Salesforce or HubSpot. The vendors change, the marketing changes, the underlying interface changes. The conversation stays the same.

And the data, the whole time, has stayed the same too: most CRMs are 60 to 80 percent empty by week 12 of any sales team rolling them out. The fields exist. The records exist. The reps don't fill them in. Pipeline reviews happen anyway, run on the manager's memory and a Google Doc. The CRM becomes what it always becomes: a museum of intent. A record of what someone meant to log, not what actually happened.

Every wave of CRM software has been an attempt to fix this. None of them have worked. Each one has compressed the gap a little — better forms, faster automation, smarter inference — but the gap has never closed. The empty fields are not a feature deficit. They're a structural property of how the category is shaped.

It's worth walking through the waves, because each one tells you something different about why the next one will fail too — and what it would actually take to escape the loop.

Look at those four rows together and the shape becomes obvious. Every wave fixed a different surface symptom — the interface, the cloud distribution, the workflow automation, the model in the loop. None of them fixed the underlying architecture, which is this: the CRM is a separate place from where the work happens.

Reps don't live in the CRM. They live in their inbox, in LinkedIn DMs, in Zoom calls, in Slack with their internal team. The CRM is the place they're supposed to walk back to after the work and record what happened. That walk is unpaid labor. It competes against the next call, the next email, the next prospect. So the walk doesn't happen. The record doesn't get made. The data is missing. The pipeline forecast is a story.

The AI-native wave is trying to remove the walk by having the model do the recording. This is real progress, and the AI CRMs are better than the prior generation in the same way HubSpot was better than Salesforce was better than Siebel. But there's a ceiling on how far you can take it. The model can summarize an email that was sent through the CRM's inbox-integration. It can't summarize a sidebar conversation in the buyer's Slack, a phone call that wasn't recorded, a hallway commitment at a conference, an off-platform DM. The model is sitting downstream of the surface area that's actually integrated, and the surface area that's actually integrated is still the minority of where the work happens.

The CRM was never the place the work happened. It was the place the work was supposed to be recorded after. That assumption is the bug.

If the bug is that recording the work is separate from doing the work, the fix has to collapse that separation. The system that captures the data has to be the same system that does the work. There are exactly two ways to get there.

Option one is to make the work happen inside the CRM. This is what every “all-in-one” CRM since Pipedrive has tried. Bring email into the CRM. Bring calling into the CRM. Bring LinkedIn into the CRM. The bet is that if the surface where the work happens isthe CRM, the recording is automatic. The bet has not worked, because the buyer's side of the work — the inboxes you're writing into, the LinkedIn accounts you're messaging, the Zoom rooms you're in — is on the other side of an internet boundary the CRM doesn't own. The seller can move into the CRM. The buyer never will.

Option two is to make the recording happen as a byproduct of the work, without the worker having to do it. This is the path the AI CRMs are betting on, but as we said above, they're betting on it from downstream — they need the work to flow through a surface they can observe. The cleaner version of option two is to put the worker themselves inside the system: a human who runs the work, in the seam where the work happens, and whose tools capture the artifacts as a side effect.

That second version is what we've been doing for two years, and we didn't set out to build a CRM replacement. We set out to run outbound infrastructure for B2B founders. The CRM-shaped artifact came out the other end on its own.

Allston Labs is a service. The pitch is plain: we put an engineer in your Slack who runs your outbound system end-to-end. Domains. Deliverability. Sequencing. LinkedIn architecture. Reply triage. List hygiene. The engineer is on the work itself — not the management layer of the work. They're the person sending the emails, watching the deliverability dashboards, picking up the replies, writing the next-best-action notes.

Two years in, we realized something we hadn't fully appreciated at kickoff: by running the work this way, every artifact the work produces lands in our system as a structured, queryable record. Not because someone logged it. Because the system that did the work is the log. The email we sent was sent from our infrastructure. We have the body, the timestamp, the deliverability outcome. The reply we received landed in our reply triage. We have the classification, the sentiment, the next-best-action. The meeting we set up went on our calendar. We have the attendees, the prep doc, the recording, the transcript, the takeaways.

None of that requires a rep to remember to log it. There's no rep separate from the system; the system is doing it. The recording is, by construction, the work.

We built a query layer on top of all of this, and we use it the same way you'd use Slack search, except the answers are sourced from every conversation, every credential, every commitment, every follow-up promise. We call it Skylarq internally. We describe it to customers as a knowledge OS. The way you interact with it is the way you interact with a smart teammate:

What's relevant here isn't the interface — natural-language query layers are everywhere now. What's relevant is the coverage. The answers above are sourced from everyinteraction, because every interaction passed through the system that ran the work. There is no “the rep forgot to log it.” There is no “the model couldn't see that meeting because it wasn't in the calendar integration.” The data is complete because the work was complete.

A reasonable person reads the above and asks: why hasn't a SaaS vendor built this? The answer is structural, and it tells you something important about which categories get disrupted by services and which categories get disrupted by software.

A SaaS company's distribution is the dashboard. Their business model assumes you log in. They charge per seat per month, and a seat that doesn't log in churns. So every product decision a SaaS company makes — what to put on the home tab, what to surface in the email digest, what to make the obvious next action — is optimized to bring you back into the surface. The dashboard is the product, because the dashboard is the distribution.

That model is fundamentally incompatible with the operating principle we're describing here, which is that the fewer surfaces you have to touch, the better the system is working. A CRM that succeeds in our model is one you stop logging into. A SaaS company that succeeded in our model would have to actively want you to use them less. No SaaS board will fund that pitch.

A CRM that succeeds in our model is one you stop logging into. A SaaS company that succeeded in our model would have to actively want you to use them less. No SaaS board will fund that pitch.

Our distribution is the engagement, not the dashboard. We charge a flat-rate retainer to run the outbound system. If you stop logging into our query layer because you've already gotten what you needed from the Slack reply we sent you that morning, the engagement is more valuable, not less. The economic incentive of the operating model is aligned with the operating principle. That alignment is what makes the shape possible.

The closest analogy is Palantir. Forty years ago, the assumption in enterprise software was that you'd buy a license, your IT team would deploy it, and your business users would fill in the data. The Cognos and the BusinessObjects of the world were built on that assumption. Palantir came in with a different operating model: forward-deployed engineers, sitting inside the customer's organization, ingesting and shaping the data themselves. The product was a piece of software, but the moat was the operating model — the engineers were the thing that made the data show up. The dashboards Palantir customers actually used worked because a person made them work, not because the customer was disciplined enough to maintain the schema.

The next iteration of “the system your sales team uses to know what's happening with customers” is going to look much more like Palantir than like Salesforce. It's going to be a service-shaped category, not a software-shaped category. The moat is the operating model, not the dashboard.

We want to be careful here because the “CRM replacement” claim is exactly the kind of thing buyers should be skeptical of. The honest scope of what we're saying is narrower than the marketing version would be.

If you're a 40-person sales team, multi-segment, multi-region, with a real rev-ops org, this isn't a one-for-one CRM replacement. Salesforce does forecasting, permissions, territory management, integrations with 200 other systems, audit logging for compliance, custom objects for industry-specific workflows. We don't build any of that. We shouldn't. If your CFO needs a board-ready pipeline report that ties out to revenue recognition, the AI-CRM category will eventually serve you, and a Salesforce instance running quietly in the background probably has to stay there.

What we replace is the part of the CRM that nobody actually updates. The conversation memory. The deal state nobody types in. The credentials the SDR knows but never wrote down. The follow-up promise the AE made on a call last Tuesday. The thing the rev-ops person is trying to coerce out of the team every week with reminders and Slack pokes and pipeline-hygiene threats. That part of the CRM — the part that's actually a museum — we replace cleanly, because we have it as a side effect of doing the work.

For most of the companies we work with — founder-led, post-PMF, $0 to $5M ARR, the team is fewer than ten people — the part we replace is the part that matters. The forecasting view in HubSpot is a story the board wants to hear; the actual decisions get made off conversation memory and a spreadsheet anyway. So the honest framing isn't “we replace your CRM.” The honest framing is: we replace the part of your CRM that's actually doing work, and you'll discover that the rest of it was already optional.

The pattern is consistent enough across customers running this way that we can describe it as a timeline. It doesn't happen because anyone announces “we're replacing our CRM.” It happens because the CRM stops being where the question gets answered, and once that's true for a few weeks, the muscle memory of opening it dies on its own.

1. Month 1

   They still open HubSpot out of habit.

   Update a few fields. Check pipeline. Nothing has obviously changed. The dashboard is the muscle memory; the system is running behind it.

2. Month 3

   They stop opening HubSpot in the morning.

   They ask the system the questions they would've asked the dashboard, because the answers are faster and more specific. The CRM tab in the browser stays closed for days at a time.

3. Month 6

   Onboarding stops mentioning the CRM.

   When someone new joins the team, nobody sets them up in HubSpot. They get Slack access. That's the onboarding. By that point the CRM hasn't been replaced. It's just been outlived.

The CRM doesn't get replaced. It gets outlived.

This timeline is not aspirational. It's the median pattern of the customers running this operating model with us today. The ones who don't fit the pattern are the ones who never had a working CRM to begin with — pre-PMF founders who skipped the HubSpot install and started fresh with us, where there's no “Month 1 habit” to peel off because the habit never formed. For them, the “CRM replacement” framing is meaningless. They just have a system. The system is the work.

We're not telling you to cancel your CRM today. Especially not if your board reads pipeline reports out of it, or if you have a rev-ops hire whose job is to maintain it, or if there's a compliance regime that depends on the audit log. Those are real costs of switching and we're not pretending they don't exist.

We're also not telling you Allston Labs is the only operating model that'll work. Other people will figure this out — and to be honest, we hope they do, because the category needs more than one good example before this stops being a thesis and starts being conventional wisdom. There will be other services-shaped sales infrastructure plays. There will be other companies whose engineers run the work and whose query layer captures it. The shape will become familiar, and at some point a buyer who's evaluating it will not have to argue from first principles the way you might have to today.

What we are telling you is that the question you've been asking — which AI-native CRM should we use?— is the same question your predecessors were asking thirty years ago about Siebel. The form of the question is the part that's broken. If you find yourself in a demo for the fourth AI CRM this quarter, and the rep is showing you how the model will guess the deal stage, ask yourself why the model has to guess. The answer is that the work isn't flowing through the system. And no amount of guessing fixes that.

The category that does fix it doesn't look like a CRM. It looks like a service that runs the work, and a query layer that sits underneath the work as a byproduct. The CRMs you'll buy in the meantime will be useful for what they've always been useful for: a place to put the deal stages your board wants to see, and a system of record for the parts of the work that happen to flow through the system. That's fine. It's just not the thing we mean when we use the phrase “the next CRM.”

Regardless of whether you ever talk to us, here are the questions worth sitting with the next time someone on your team says “we should evaluate a new CRM.”

• Question 01

  What does your CRM actually do for you that nothing else does?

  If the honest answer is 'pipeline reports for the board,' you have one job to solve, not five. And most of the cost — license, admin, the rev-ops layer — isn't being paid for that one job.

• Question 02

  Who maintains the CRM today, and what would they do with that time back?

  The cost isn't the license. It's human attention — the SDR coercing fields, the AE updating stages, the rev-ops engineer building views nobody opens. Add up those hours. That's the true price.

• Question 03

  If your operating model included someone running the work, what would the CRM be for?

  This is the question most companies don't ask, because no vendor is incentivized to ask it for them. But it's the question that determines whether you're buying software or buying an operating model.

Most companies don't ask question three, because no vendor is incentivized to ask it for them. A CRM vendor cannot ask “what would your CRM be for if someone else ran the work?” without indicting their own product. So the question stays unasked, and the demo cycle continues, and the next AI-native CRM gets a sales call from your team.

We're asking it because we've seen the answer.

We're a small team. The thesis above isn't going to be load-bearing for the industry on its own. We're writing it because we've spent two years inside this operating model and we'd rather make our case in long form than in a pitch deck. If you're thinking about CRM selection this quarter and any of this resonated, we'd rather have the conversation than have you read another page about it. Thirty minutes, no slides, we'll tell you straight whether what we do replaces what you have today — and when it doesn't.

If you're a vendor and you want to argue with us, also welcome. The category is going to be more interesting if we argue it out in public.