trycompai/crm: an agentic-first CRM where the agent keeps its own notes

The problem Comp AI CRM is aimed at

Most CRMs are a database with a form in front of them. The README says as much, and then makes the sharper claim that AI-flavoured CRMs usually bolt a chat box onto the side of that same form. In both cases the work of finding out what is true about a person and writing it down stays with a human. Comp AI CRM inverts the arrangement: the README describes the agent as the thing the CRM exists for, with the CRM acting as where the agent keeps its notes.

The intended user is a small sales or revenue team that already accepts an autonomous process touching customer records, and that has someone who can run Postgres and a second service. It is not aimed at a team that wants to click a hosted signup and start typing. The repository is a Bun workspace monorepo with apps/ and packages/, a docker-compose.yml for Postgres, and a .env.example that expects you to fill in a database URL, an auth secret and a sign-in allowlist before anything works.

How the agent actually decides what to write

The design rule the README states most clearly is that nothing about a person is guessed. No tool accepts a confidence score, on the argument that a model asked to grade its own certainty will produce a number, and will err in the direction that flatters it. Instead tools report observations, with crm.signature-block and github.account-identity given as examples, and a ledger prices the evidence. Strong evidence writes to the record directly. Weak evidence becomes a suggestion a human settles.

That is a real architectural commitment, not a slogan, because it pushes ambiguity out of the write path and into a review queue. The cost is latency: a fact that a conventional enrichment tool would write in one call may sit as a suggestion until someone looks at it.

The agent lives in apps/agent and is its own deployment, built on eve, described as Vercel's filesystem-first framework for durable agents. Tools are files, skills are markdown, schedules are files. The README lists 18 authored tools including read_crm_history, search_crm, identify_contact, research_person, enrich_company, record_fact and schedule_recheck, plus 4 skills (evidence.md, identity-matching.md, data-boundaries.md, writing-a-brief.md) and a single schedule file, dispatch.ts, which the README says decides nothing and only leases due rows and starts a session per row.

The work queue is lib/tasks.ts. Rows are leased with FOR UPDATE SKIP LOCKED, so two dispatchers pick up disjoint work, and a run that dies releases its row when the lease expires. Recurring logic is expressed as a task's dueAt rather than a cron expression. When the agent wants another look at a contact it calls schedule_recheck and states a reason, and that reason is shown to the rep.

The sandbox, the egress rule and the missing DATABASE_URL

The agent gets a sandbox with bash, grep, glob and a /workspace, and the README states it has deny-all egress. The justification given is that web_fetch runs in the app runtime and web_search at the model provider, so the sandbox loses nothing functional by being cut off, while removing the path by which a customer's email body could leave through a shell command.

The second half of that rule is an absence rather than a setting: the sandbox is never given DATABASE_URL. The README's phrasing is that a shell with credentials and egress is exfiltration-shaped, while a shell with neither is a text processor.

This is the part of the design most worth copying, and also the part that constrains what you can ask the agent to do. Anything that needs a network call from inside a shell script will not work. The agent has to route through the tools instead. If your team's instinct is to hand the model a container with credentials and let it improvise, this project is pointed the other way.

Installing it and getting the first agent run

The repository is a Bun workspace. The package.json declares packageManager [email protected] and engines.node >=22, so Bun is the expected runtime rather than npm or pnpm. Start by bringing up the database the compose file defines. It runs postgres:17-alpine, publishes 5432, and healthchecks with pg_isready against the crm database.

docker compose up -d postgres

After that, copy .env.example to .env and fill in the values it demands. DATABASE_URL is the connection string, BETTER_AUTH_SECRET is generated with openssl rand -base64 32, and ALLOWED_SIGN_IN is a comma-separated list of whole email domains or single addresses. The .env.example is explicit that this list is the entire authorisation model and has no default, so an empty value means nobody signs in.

cp .env.example .env
openssl rand -base64 32

Google is the sign-in method a fresh clone starts with, and the same OAuth client is what reads Gmail and Calendar. The .env.example warns that GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET must be set together or not at all, because half a pair produces a sign-in button that fails at Google. Microsoft sign-in and a custom identity provider on Settings to SSO are the alternatives.

Once the environment is populated, the root scripts drive everything through Turborepo. db:push, db:migrate, db:seed and db:studio are all available, and dev runs the workspace in watch mode.

bun install
bun run db:push
bun run dev

Tests need their own database. TEST_DATABASE_URL must point at a database whose name ends in _test, and the .env.example states the suite refuses to run without it because these are real integration tests that write and delete rows. bun run db:test creates that database and applies the migrations.

bun run db:test
bun run test

There is no documented single-command production bootstrap in the repository's README, so treat the above as the development path. The README points at a Deploying section and a homepage at trycrm.ai for the hosted route.

Where the design costs you something

The agent is a second deployment. The README is unambiguous that apps/agent runs on its own, on its own schedule, against its own work queue. That is what makes it survive a browser tab closing, but it also means a self-hoster is operating two services and a Postgres instance, not one web app. Nothing in the repository suggests a single-binary mode.

The evidence ledger is the second cost. Because weak evidence becomes a suggestion rather than a write, someone has to settle those suggestions. The README frames this as a feature, and for a fact about a customer it is, but it does shift work from data entry to review. A team expecting the CRM to fill itself in with zero human attention has misread the pitch.

The third constraint is optionality that is genuinely optional. The README states the agent is designed to run with no API keys at all, using read_crm_history against your own threads, meetings and signature blocks. That is the strongest evidence source in its own argument, since no vendor can sell you a reply from the person's own address. But each key opens one more place to look, and the agent is told at the start of every session which ones this install has, so its plan is shaped by what you configured. Fewer keys means a narrower agent, not a broken one.

Company brand data and LinkedIn both come from a single Context key, according to the README. It is stored in a row rather than an environment variable, requested during onboarding, and changed afterwards at Settings to General, on the stated grounds that a self-hoster's admin cannot redeploy to set an environment variable.

Comp AI CRM against Twenty and the other open source CRMs

The obvious comparison is Twenty, which shows up in the same searches as this project. Twenty is a general-purpose open source CRM: the record model is the product, and automation is configured around it. Comp AI CRM makes the opposite bet. The agent is the product and the record model is where its observations land.

The practical difference shows up in what you configure. With a conventional open source CRM you spend your time defining fields, pipelines and workflow rules. Here you spend it on tools, skills and schedules, which the README describes as files in apps/agent, versioned like code. A team without TypeScript fluency will find the second model harder to extend, even though the tool surface is smaller.

The second difference is the evidence policy. Conventional CRMs and enrichment add-ons write what a vendor returns. Comp AI CRM prices it and routes weak evidence to a human. If your team's problem is stale fields, the second model is slower but more defensible. If your problem is that nobody enters data at all, either model depends on someone doing the reviewing.

Maintenance, licence and what you are signing up for

The repository is not archived, and the last push was on 2026-09-02, which is recent enough that the project is being worked on. Releases are frequent and small: v1.15.3 on 2026-08-21, v1.15.2 on 2026-08-20, v1.15.1 on 2026-08-20. The package.json version matches v1.15.3, so the root manifest tracks releases.

The default branch is release rather than main, which is worth knowing before you open a pull request. CONTRIBUTING.md and AGENTS.md are both at the repository root, and there is an adrs/ directory for architecture decision records, so design changes are expected to be argued in writing.

The licence is MIT, declared in both the README badge and the package.json license field. That is permissive and imposes no source disclosure on your own code. It says nothing about the third-party services the agent can call: the Context key, Perplexity, or Google's APIs each carry their own terms, and the README treats them as separate optional sources rather than bundled components. The README does not describe what happens to records if a key is removed, only that the agent is told at session start which sources exist.

Tooling is opinionated. Biome handles formatting, oxlint handles linting, knip checks for dead code, and Turborepo coordinates the workspace. A pre-push hook runs the integration suite, and the prepare script sets core.hooksPath to .githooks. Expect your first push to be gated on a working TEST_DATABASE_URL.

Editorial conclusion

Adopt it if you want an agent that maintains the CRM on its own schedule and you are willing to run Postgres, Bun and a second deployment for apps/agent. Skip it if you need a mature, plugin-heavy CRM with a long history of third-party integrations, or if you cannot operate Postgres yourself. Verify three things before committing: that your Google OAuth client has both Gmail and Calendar scopes, that TEST_DATABASE_URL points at a database whose name ends in _test, and that you are comfortable with ALLOWED_SIGN_IN being the entire authorisation model, since the .env.example states it has no default and is the only gate on who can sign in.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. trycompai/crm on GitHub