The DenchClaw Story: Why We Pivoted from Enterprise AI

We started building enterprise AI workflows at YC. We ended up building a local-first AI CRM. Here's the story of that pivot and why it was the right call.

Kumar Abhirup

March 25, 2026·8 min read

The story of DenchClaw starts with a problem I didn't expect to care about: why do the best AI tools for business always run somewhere else?

Let me back up.

The Enterprise AI Problem#

Before DenchClaw, I was building enterprise agentic workflow tools. The specific domain: outbound calling automation and legal intake systems for sales floors. The context: YC S24, with customers including mid-market sales operations teams.

The work was technically interesting. You're orchestrating AI models, handling real-time voice, managing complex state across multi-turn conversations. The use case was real — these companies had genuine ROI from automating intake calls and outbound qualification.

But something kept nagging at me about the architecture. We were building workflows where an AI agent had access to customer data, conversation history, deal notes, relationship context. All of this data was in cloud systems — our servers, the CRM's servers, the calling platform's servers. The AI had context; it just wasn't anyone's context in particular. It was distributed across a chain of cloud services that the customer didn't control and couldn't audit.

When I talked to the sales teams using these tools, I noticed something. They were productive with the AI tools, but they didn't trust them at a deep level. They used the tools for specific, bounded tasks. They wouldn't delegate anything sensitive or strategic. There was a ceiling on how useful the AI could be because there was a ceiling on how much context they'd give it.

The ceiling was the trust problem.

The Insight#

The insight came from a conversation with a VP of Sales at a healthcare software company. She was explaining why they couldn't use our outbound calling tool for their enterprise accounts — accounts where the relationship involved multiple years of history, specific ongoing commitments, sensitive pricing arrangements.

"I can't let an AI that I don't control have access to those relationships," she said. "It's not that I don't trust your tool. It's that the data would be in your system, and I'd have to trust you forever, and your investors, and whoever acquires you."

She was right. And the implication was broader than I'd recognized: for AI to be genuinely useful for high-stakes relationship work, the AI has to run somewhere you trust completely. Ideally, somewhere you control.

That was the first version of the insight. Local AI is more trustworthy because it runs on your hardware, not a vendor's.

The Original Name: Ironclaw#

We started building what we initially called Ironclaw — an AI-powered CRM built on top of OpenClaw, running locally on your Mac. The name felt right: claws are local, physical, yours.

Then Garry Tan (president of YC) tweeted about it. The tweet drove significant GitHub traffic and HN attention. The Show HN post — "Show HN: DenchClaw – AI CRM that runs entirely on your Mac" — went to 147 points and 124 comments. The interest was real.

Then we discovered that NearAI had a project also called Ironclaw. Not the same product, not competing directly, but the shared name caused enough confusion that we decided to change ours.

The rename happened fast. We chose DenchClaw: Dench (our company) plus Claw (from OpenClaw, the underlying framework). It's distinctive, it tells you where we came from, and it doesn't conflict with anything.

What YC Taught Us About the Pivot#

The hardest part of pivoting from enterprise AI workflows to local-first CRM wasn't the technical work. It was recalibrating our mental model of what problem we were solving.

Enterprise AI workflows is a Services business with some software components. You get a customer, you build their specific automation, you maintain it as their needs change. The revenue is real; the growth is capped by your ability to deliver.

Local-first CRM is a software platform business. You build one thing, you distribute it broadly, the value compounds with the community and ecosystem rather than with your services headcount. The ceiling is higher; the initial growth is slower.

YC is excellent at helping you see which of these you actually want to build. The batch structure, Demo Day, the investor network — all of it is calibrated for platform businesses, not services businesses. Being in that environment made the right direction clear.

The other thing YC clarified: the correct test for a software platform is whether it builds something you yourself want to use. Mark and I both needed a CRM. We were both frustrated with cloud CRMs for the same reasons our prospective customers were. We were building for ourselves, which is the best position to build from.

What DenchClaw Actually Is#

There's an elevator pitch version and a real version.

Elevator pitch: "A local-first, open-source AI CRM that runs on your Mac. Install with npx denchclaw. Your data stays on your machine. The AI knows your relationships. Works via Telegram, WhatsApp, or the web UI."

Real version: "DenchClaw is an operating system for your business relationships. It stores everything about your professional network, deals, and interactions in a DuckDB database on your laptop. An AI agent — accessible via any messaging channel — has full context on your data and can answer questions, log interactions, draft communications, and proactively surface what you need to know. The whole thing is open source under MIT license. The skill ecosystem extends it in ways we couldn't anticipate and couldn't build ourselves."

The real version is harder to say quickly but better describes what we're actually building.

What We Got Right#

The local-first architecture was right. The performance difference between DuckDB on localhost and any cloud CRM is categorical — not incremental. Users who've switched consistently describe the experience as "like going from dial-up to broadband." Not a quantitative improvement; a qualitative shift.

The skill system was right. Having capabilities defined as SKILL.md files rather than compiled code means the community can extend DenchClaw without needing to be TypeScript developers. Skills for Apollo, for LinkedIn, for specific industry workflows — these are being written by domain experts, not just engineers.

The messaging channel interface was right. People's relationships with their CRM change when they can access it from their phone via Telegram. "Let me quickly check my notes on this person" while standing outside a meeting is a real use case that voice and messaging enable better than any mobile app.

What We're Still Figuring Out#

Team sync. This is the hardest technical problem in local-first software. Each person has their own copy of the data; keeping those copies consistent without a central server requires CRDTs and careful operational design. We're building it; it's not shipped yet.

Non-technical user experience. The install is npx denchclaw in a terminal. For a lot of people, that's a barrier. A one-click installer for macOS is in progress.

Enterprise features. SSO, RBAC, audit logs, compliance exports — these matter for larger organizations. They're on the roadmap for Dench Cloud (the managed hosting product).

Where We're Going#

The vision that drives us: an AI assistant that knows you, knows your relationships, knows your context, and acts on your behalf — running on your own hardware, fully private, infinitely extensible.

Not an AI feature in someone else's product. Not an AI assistant that's owned by a company with interests that aren't yours. Your AI, on your machine, serving only you.

DenchClaw is the early version of this. It works. It's in use by founders, consultants, investors, and technical sales professionals who've moved their CRM workflows to it. The community is building on it. The ecosystem is growing.

The pivot from enterprise AI to local-first CRM was the right call. The validation is in the usage patterns and the GitHub stars and the Telegram conversations with users who've made it their primary tool.

We're not done. Not close to done. But the direction is clear.

Frequently Asked Questions#

Why did you choose to open source DenchClaw instead of keeping it proprietary?#

The trust argument for local AI requires transparency. If we claim your data is private and local, you should be able to verify that by reading the code. Open source is the only way to make that verifiable. Also, the skill ecosystem is far more valuable with community contribution than without it.