trycompai/crm

What it is

Comp AI CRM is an open-source customer relationship manager (CRM) built for AI agents. Instead of treating the AI as a chat box bolted onto a database, it makes the agent the core of the system: the CRM is where the agent keeps its notes.

The core idea

The agent runs on its own schedule, with its own work queue. It decides what to look at next, books follow-up actions, and spends a research budget until it runs out. Crucially, it never guesses about a person. Tools report what they actually observed (e.g. a signature block, a GitHub account). Strong evidence gets written to the record; weak evidence becomes a suggestion a human can confirm or reject. A confidently wrong fact is considered worse than an empty field.

How the agent works

It uses a framework called eve (filesystem-first durable agents) — each tool is a file, each skill is a markdown doc, schedules are files too.
It ships with 18 built-in tools (search CRM, identify contact, research person, enrich company, record fact, etc.) and 4 skills (evidence rules, identity matching, data boundaries, writing briefs).
The agent processes a work queue with leases: it claims rows with a FOR UPDATE SKIP LOCKED lock so two dispatchers never double‑work, and failed runs free their rows when leases expire.
It can schedule re‑checks and tells you why it will be back — a reason, not a default.
No external source is required. Without any API keys it still reads your own threads, meetings, and signature blocks — free and reliable. Each optional key (Perplexity for web search, Context for company brand data and LinkedIn) opens another place to look.
The agent runs in a sandbox with no network and no database — it can only process text, using bash, grep, and file operations. This prevents any shell command from exfiltrating customer data. The database URL is never given to the sandbox.
You can talk to it: every contact, company, and deal has an Agent tab where you see its steps, its discarded leads, and can answer its questions. Conversations survive reloads.

Connections & access

Open Settings → Connections to connect external services (Gmail, Microsoft, etc.). Only owners/admins can manage connections.
Each service can be read-only or read/write. The connection page lists every discovered tool and its access type; new or changed tools require review before the agent can use them.
Disconnecting a service blocks the agent’s next call and removes all its tools; you must reconnect and review before using it again.

The stack

Monorepo on Bun and Turborepo, deployable on Vercel.
Front end: Next.js (App Router) + shadcn/ui.
API: NestJS with tRPC for type-safe RPC from browser to database.
Data: Postgres (Neon) with Prisma ORM, optional Redis cache.
Auth: Better Auth — Google, Microsoft, or custom IdP; a single allow‑list controls who can sign in.
Files: Vercel Blob for profile pictures (so they survive the original source disappearing).

Three design rules are emphasised: intelligence never lives in the API (the agent decides what events mean), packages/ui is the only source of UI styles, and there are no organizations — it’s intentionally single‑tenant.

Quick start

You need Bun and Docker. Clone the repo, copy .env.example, set a few required values, then run:

bun install
docker compose up -d   # Postgres
bun run db:deploy
bun run db:seed        # optional demo data
bun run dev

The app runs on localhost:3000, API on localhost:3001. The default branch is release (stable); main is for unreleased work.

Required `.env` values

BETTER_AUTH_SECRET – generate with openssl rand -base64 32
ALLOWED_SIGN_IN – your email domain or individual addresses (e.g. acme.com). Unset means nobody can sign in.
At least one OAuth pair (Google and/or Microsoft). See README for detailed setup.
DATABASE_URL already matches docker compose’s Postgres, so leave it alone unless you have your own.

Everything else in .env is optional — you can run with none of it.

Configuration & deployment

One .env at the repo root is read by all three processes (app, API, agent). Real environment variables always take precedence.
Deploy as three separate services: the Next.js app, the NestJS API, and the agent. They only need to agree on DATABASE_URL and BETTER_AUTH_SECRET. Set API_URL/APP_URL to production origins, and add a callback URL for your OAuth provider. A CRON_SECRET guards the mailbox sync endpoint.

Full details are in the README — this is just the essence.