Comp AI Open-Sourced an Agentic CRM — Agent First, Database Second

Comp AI open-sourced the CRM they built for their own sales team — and the pitch is literal, not marketing fluff: a durable research agent is the product; the database is where it writes things down.

Co-founder Lewis Carhart announced the MIT release on X in early August 2026. Within a few days trycompai/crm sat near ~2,000 stars and ~237 forks. The thread that followed mixed “HUGE,” fork-and-star energy, vibe-coding skepticism, and one useful engineering critique of the dispatch loop. This explainx.ai read covers what the repo actually ships, how to stand it up, where the architecture is sharp, and where “durable” is still aspirational.

Comp AI CRM overview: closed-won vs new pipeline, open pipeline by stage, deals in progress, overdue tasks.

TL;DR — questions people ask after the launch post

What Comp AI means by “agentic-first”

Most CRM AI products still look like a database with a form, plus a chat panel that drafts emails. Comp AI’s README rejects that layout:

The agent is not a feature of the CRM; the CRM is where the agent keeps its notes.

The agent runs on its own deployment, on its own schedule, against its own work queue. It decides what to look at next, books follow-ups, spends a research budget, and stops when the budget runs out. Close the browser and it keeps going — that is the product claim.

Three codebase rules reinforce the inversion:

1. Intelligence never lives in the API. NestJS writes queue rows when a thread is ingested or a company is created. The agent leases the row and decides what it means. A Nest service that calls enrichment directly is treated as a bug (documented after an outage that made the rule stick).
2. Nothing about a person is guessed. Tools report observations (crm.signature-block, github.account-identity); a ledger prices evidence. Strong evidence writes; weak evidence becomes a human suggestion. No confidence scores for the model to inflate.
3. No organizations column theater. Single-tenant on purpose. An always-constant organizationId would buy nothing and read like real multi-tenancy in review.

That last point matters for anyone comparing this to HubSpot clones: this is an internal team CRM, not a white-label SaaS starter.

What it does in practice (from the launch thread)

Carhart’s follow-up list maps cleanly onto the README:

1. Gmail and Calendar connect so records fill themselves in — contacts often arrive from mailbox sync, not typing.
2. 18 tools, 4 skills, everything queue-based — powered by Eve, Vercel, Context (company brand data), and RapidAPI for LinkedIn research.
3. Books its own follow-ups and must say when it will return to update research — schedule_recheck reasons are shown to the rep.
4. Fully sandboxed — bash/grep/glob in a workspace with deny-all egress; the sandbox never receives DATABASE_URL.

The four skills are prose versioned like code: evidence.md, identity-matching.md, data-boundaries.md, writing-a-brief.md. If you already think in agent skills and skills-lock.json, this is the same idea applied to CRM research policy instead of coding workflows.

Stack map (monorepo layout)

Layout:

Deploy is three processes plus Postgres. They must share DATABASE_URL and BETTER_AUTH_SECRET or you get a redirect loop, not a clear error.

Quick start (copy-paste)

You need Bun and Docker.

git clone https://github.com/trycompai/crm.git && cd crm
bun install
docker compose up -d          # Postgres on :5432
cp .env.example .env          # fill the four required values
bun run db:deploy
bun run db:seed               # optional demo pipeline
bun run dev

App: http://localhost:3000 · API: http://localhost:3001.

The four required .env values

Redirect URI for local: http://localhost:3001/api/auth/callback/google. Enable Gmail and Calendar APIs. Unset ALLOWED_SIGN_IN means nobody can sign in — fail closed.

Optional keys (agent prints on/off at startup): RAPIDAPI_KEY (LinkedIn), PERPLEXITY_API_KEY (web research), CONTEXT_DEV_API_KEY (company brand), AGENT_BRIDGE_SECRET (Agent tab chat), CRON_SECRET (mailbox sync route), REDIS_URL.

How the work queue is supposed to work

lib/tasks.ts is the heart of the “keep going with the browser closed” story:

• claimDue leases rows with FOR UPDATE SKIP LOCKED so two dispatchers take disjoint work.
• A dead run frees its row when the lease expires.
• Recurring “every N minutes, oldest ten contacts” belongs in a task’s dueAt, not a cron soup of business logic.
• dispatch.ts “decides nothing” — it leases what is due and starts a session per row.

That is classic loop / harness thinking: the schedule is a clock; policy lives in skills and tools. It also rhymes with holaOS-style environment design — reliability from structure, not a larger chat box.

Sandbox threat model (worth stealing)

Two absences do the heavy lifting:

1. Deny-all egress from the sandbox shell — web_fetch / web_search run outside the shell.
2. No DATABASE_URL in the sandbox — a shell with credentials and egress is exfiltration-shaped; a shell with neither is a text processor for dossiers and greps.

For teams shipping agent shells, that pairs with the same instincts as Destructive Command Guard and the cautionary notes around long-horizon sandbox escapes: bound the tool surface before you trust “it works on my laptop.”

Honest take: “durable” still needs hardening

Social launch threads always attract two bad modes — pure hype and pure dismissiveness. One reply accused the team of shipping a half-day vibe-code flex. That is not a technical review.

A sharper one (widely quoted under the launch) said: decent architecture, but the dispatch loop has real durability gaps — retireExhausted() wrapped in an empty catch {}, settle failures swallowed, tasks can limbo. Comp AI’s reply: they will keep improving.

We pulled current apps/agent/agent/schedules/dispatch.ts from main. The critique holds:

try {
  for (const abandoned of await retireExhausted()) {
    await settle(
      abandoned,
      EnrichmentStatus.FAILED,
      "Research was attempted several times and never completed.",
    );
  }
} catch {}

And on per-task failure:

await settle(task, EnrichmentStatus.FAILED, reason).catch(() => {});

Empty catches hide lease/settle bugs. If settle fails after markRunning, enrichment status and task lease can disagree — the classic limbo. Framework-level Eve sessions can still be “durable” while your queue semantics are not. That is the harness layer failing even when the model layer looks fine — the same stack split we use in loop engineering.

Before production customer data: read SECURITY.md, keep it allow-listed, add observability around retire/settle, and treat empty catches as P0. Forking is the point of MIT.

Who this is for (and who should wait)

Good fit

• Small GTM teams who already live in Google Workspace and hate empty CRM fields.
• Engineers building software for one / situated tools who want a reference monorepo with agent + API + app split.
• Teams studying evidence-led enrichment (observations vs confidence theater).

Wait or fork first

• Multi-tenant SaaS needs — you would redesign auth entirely.
• Compliance-sensitive customer PII without a security review — single-tenant does not mean safe by default.
• Anyone who heard “durable agents” and expected battle-tested queue semantics out of the box.

Comp AI also builds an open-source compliance platform (SOC 2 / ISO-style automation). The CRM is a separate product surface; do not confuse the two repos when evaluating license and architecture.

What to steal even if you never run the CRM

1. Queue-as-truth — APIs emit facts; agents interpret them.
2. Evidence ledger — no self-graded confidence on people.
3. Skills as policy — identity matching and data boundaries in versioned markdown.
4. Sandbox without DB credentials — text processing without exfiltration shape.
5. Rep-visible recheck reasons — agents that cannot explain a 14-day return do not have a reason.

Those patterns transfer to any long-running research agent — sales, support, or internal ops — and they connect directly to how explainx.ai talks about skills, MCP servers, and loops.

Related on explainx.ai

• Genspark GenOffice — open-source AI office
• What are agent skills?
• skills-lock.json for reproducible agent skills
• Context vs prompt vs loop vs harness engineering
• Loop engineering with Claude Code
• Software for one: personal apps and AI coding agents
• holaOS: agent environments and long-running state
• Fable-OS: self-evolving agentic OS research
• Destructive Command Guard for AI coding agents

Primary sources

• trycompai/crm on GitHub — README, docs/agent.md, SECURITY.md, CONTRIBUTING.md
• Lewis Carhart’s August 2026 X announcement thread (features list, fork/star call)
• Current apps/agent/agent/schedules/dispatch.ts on main (retire/settle error handling)

Star counts, file paths, and stack details reflect the public GitHub repository and launch discussion as of August 3, 2026. Eve, Vercel, Google OAuth, and enrichment APIs change quickly — verify the README and SECURITY.md before deploying against real customer mail.