Comp AI: Open-Source CRM Where an AI Agent Sells (2026)

Comp AI runs a SOC 2 / ISO 27001 / HIPAA compliance platform with 1,000+ enterprise customers. Last week they open-sourced the CRM their own sales team was using. One thing caught me before anything else: it’s not a CRM with a chatbot. It’s a CRM where the product is a research agent that runs around the clock and refuses to guess about your customers.

Three days in, it’s sitting at 1,821 stars — roughly 607 a day. That’s the fastest-growing AI/agent project on GitHub right now after the one I covered yesterday. The momentum made me look twice. But the design made me stay.

TL;DR: The agent is the product, not a feature

Quick verdict up front. Most “AI CRM” tools are a database with a chat box bolted onto the form. You still decide who to chase, what to log, what’s real. But Comp CRM flips that. A durable research agent lives on your server, plans its own next steps, queues its own follow-ups, spends its own research budget, and stops when that budget runs dry. So close the browser and it keeps working — it’s not a request/response thing. The database is just where it writes its notes down.

The part that actually sold me is the anti-hallucination ledger. The system won’t let the model grade its own confidence, because a model that scores itself will bias toward “looks useful.” It only reports facts it can observe — a verified signature block, a confirmed GitHub account identity. Strong evidence gets written into the record. Weak evidence becomes a suggestion that waits for a human to confirm. One confident wrong answer about a customer is worse than a blank field, and this is the first CRM I’ve seen that treats that as a design rule instead of a marketing line.

Why “agent is the product” changes the workflow

Traditional CRM treats data entry as the job and people as the workers. Comp CRM hands the scut work to the agent. Feed it your inbox, and it triages threads, figures out what each contact actually is, and books the follow-up. The pitch in their README is blunt: “nothing about a person is guessed.” The tools it exposes are observational — crm.signature-block, github.account-identity. It reads, it confirms, it writes down what it found, and it flags what it couldn’t confirm for a human.

That split between recorded fact and “please confirm this” is the heart of the design, and it’s measurable. Here’s the workflow in practice: your Gmail syncs in via POST /internal/sync/google behind a cron, threads land in a queue, the agent leases a row, decides what it means, and schedules a touch. Weak evidence — say an unverified email domain scraped from a footer — gets demoted to a human-confirmation suggestion instead of being burned straight into the customer profile.

The ledger is where the “never guess” promise gets teeth. Now, in most agent stacks, the model decides how confident it is and that self-score gets written straight into the database — which, if you’ve run agents long enough, you know is how “looks plausible” becomes “recorded fact.” But Comp CRM removes that path entirely. The agent can’t assign a confidence number because the confidence number is exactly where hallucination hides. Instead, it leans on tools that report what they actually observe. A signature block that checks out becomes an entry. An email domain that came from an unstructured footer becomes a yellow-flag suggestion. That’s the honest core of the whole thing, and it’s the first time I’ve seen a CRM encode it as a structural rule rather than a slogan.

Deploying it: three services and a Postgres on your own VPS

This is a self-hosted tool, which means a VPS is basically mandatory — three separate services plus Postgres (same VPS setup philosophy I ran through in my LFG review). Here’s the environment prep, and I’m flagging the boundary up front: this is a README-driven walkthrough with a setup environment, not a benchmarked production run, so treat the resource figures as expected specs rather than measured numbers.

git clone https://github.com/trycompai/crm && cd crm
curl -fsSL https://bun.sh/install | bash
# Postgres — you need one. Easiest path is a container or a managed instance.
docker run -d --name crm-pg \
  -e POSTGRES_PASSWORD=change-me -p 5432:5432 postgres:16

# The two config values both sides of the app must agree on.
export DATABASE_URL=postgresql://postgres:***@localhost:5432/crm
export BETTER_AUTH_SECRET=$(openssl rand -hex 32)

The runtime is Bun (TypeScript throughout: NestJS API + Next.js app + the agent). The contract between the pieces is deliberately small — DATABASE_URL and BETTER_AUTH_SECRET for the cookie-signing handshake, then API_URL / APP_URL / AUTH_COOKIE_DOMAIN to wire them together. Google OAuth with an allow-list is the whole auth model, and it’s single-tenant by design.

# The agent runs in the background and keeps working on its own.
bun run agent
# The NestJS API — the agent's control plane.
bun run api
# The Next.js app you actually click around in.
bun run app

Three separate processes, one Postgres. On a $12–24/month DigitalOcean Droplet-sized box with 2GB of RAM, that’s a snug but workable footprint for a small sales pipeline (affiliate link) — the whole point of self-hosting is keeping customer data on your own hardware rather than inside a SaaS vendor’s warehouse.

What it actually costs to run

The honest cost math is what sold the self-host angle for me. A per-seat SaaS CRM for a five-person sales team adds up fast, and you’re still sending customer data to a vendor’s cloud. So Comp CRM flips that: your recurring cost is the VPS, and the software is MIT-licensed. For a small team or a solo founder, a 2GB Droplet in the $12–24/month band is the comfortable middle; a budget Hostinger instance keeps the entry point lower if you’re just testing (affiliate link). Either way, the cost is flat and predictable instead of scaling per seat, and the data stays on a box you control. Still, don’t kid yourself about the operational side — you’re now on the hook for Postgres backups and uptime, which is a fair trade for data sovereignty but a real one.

Where this beats (and loses to) the alternatives

Let me be honest about the trade-offs. Salesforce and HubSpot have decades of ecosystem, integrations, and enterprise workflows behind them. If you need multi-tenant, SSO, role-based permissions, and a sales ops team managing it, Comp CRM is not the tool — the SECURITY.md is explicit that this is single-tenant internal software, and you should think hard before pointing real customer data at a project this young. That said, different architecture, not a flat-out replacement. If what you want is for an agent to own the research-and-entry work on a modest pipeline, that’s exactly the lane this is built for. For the agent-infra layer underneath it, my qm write-up from yesterday covers that angle — Comp CRM is a specific sales agent running on top of that kind of foundation.

The honest bottom line

I like this one more than I expected to. The anti-hallucination ledger is a genuinely different idea in a market where every AI sales pitch is confidence scores and “we’re basically magic.” It won’t close deals for you — nobody should promise that — but it frees up the manual hours spent on data entry and cuts down on confidently-wrong customer records. It is young, it is moving fast (that 600+ stars-a-day clip is real), and single-tenant self-hosting means you own the trade-off of running it.

If you want an agent that actually does the selling research instead of a chat box that parrots your forms, this is one of the most interesting open-source options on the table right now. So spin up a VPS, point it at a test inbox, and watch what the ledger demotes to “please confirm.” Your mileage may vary — but the honesty-by-design part is worth stealing even if you never run it.