trycompai/crm: an agentic-first CRM where the agent runs on its own schedule

The problem: a CRM where nobody writes anything down

The README makes its target explicit. Most CRMs are, in its words, a database with a form in front of it, and the AI ones bolt a chat box onto the side of that form. Either way the finding and the recording stay with a human. Comp AI CRM inverts that: the README states that the agent is not a feature of the CRM, but that the CRM is where the agent keeps its notes. The intended user is therefore not a sales rep looking for a nicer pipeline view. It is a small team or a self-hoster who wants contact, company and deal records to fill themselves in from evidence already sitting in their own inbox, calendar and signature blocks, without hiring someone to transcribe it. If your problem is pipeline reporting or forecasting, this repository does not address it.

The evidence ledger is the actual product decision

The rule the README says the agent never breaks is that nothing about a person is guessed. No tool accepts a confidence score, on the stated reasoning that a model asked to grade its own certainty will produce a number, and will err toward looking useful. Instead, tools report what they observed, with names like crm.signature-block and github.account-identity, and a ledger prices that evidence. Strong evidence writes directly to the record. Weak evidence becomes a suggestion that a human settles. The README's justification is worth quoting because it is the whole argument: a confidently wrong fact about a customer is worse than a blank field, because nobody can tell it is wrong. This is a deliberate trade. You get blanks where a conventional enrichment tool would give you a plausible guess, and the blanks are the point. Teams that measure enrichment by field-fill percentage will read this as a defect.

How the agent runs: a leased queue, not a cron expression

apps/agent is a separate deployment built on eve, described in the README as a filesystem-first framework for durable agents. A tool is a file, a skill is a markdown file, a schedule is a file, and the runtime handles sessions that survive a redeploy. The repository lists 18 authored tools including read_crm_history, search_crm, identify_contact, research_person, enrich_company, record_fact and schedule_recheck, plus four skills (evidence.md, identity-matching.md, data-boundaries.md, writing-a-brief.md) that are prose the agent reads and that are versioned like code. The scheduling mechanism is the part worth understanding. lib/tasks.ts is the work queue, and claimDue leases rows using FOR UPDATE SKIP LOCKED, so two dispatchers take disjoint work and a run that dies frees its row when the lease expires. The single schedule file, dispatch.ts, decides nothing; it leases what is due and starts a session per row. The README is direct that anything resembling 'every N minutes, the oldest ten contacts' belongs in a task's dueAt field rather than a cron expression. When the agent wants another look at someone it calls schedule_recheck and states why, and that reason is shown to the rep, on the argument that an agent which cannot say why it will return in fourteen days does not have a reason, it has a default.

The sandbox with neither network nor database credentials

Turning on the sandbox gives the model a shell with bash, grep, glob and a /workspace, under deny-all egress. The README frames this as the difference between a tool-caller and something that can keep a dossier, diff this month's profile against last month's, and grep a thread for a signature block. The egress restriction is stated to cost nothing functionally, because web_fetch runs in the app runtime and web_search runs at the model provider. What it removes is the path by which a customer's email body could leave through a shell command. The second half of the rule is an absence: the sandbox is never given DATABASE_URL. The README's reasoning is that a shell with credentials and egress is exfiltration-shaped even in an internal tool, while a shell with neither is a text processor. That is a coherent threat model for a tool that reads other people's email. It also means you cannot use the shell to query your own database directly, which is a real constraint on what the agent can do inside a session.

Getting it running, and what the configuration actually gates

The README documents a quick start, a configuration section and a deploying section, but the extracted text does not include the literal install commands, so I cannot reproduce them here without inventing them. What the material does establish is the shape: a Bun runtime, a Postgres database, and a separate agent deployment under apps/agent. Configuration is a mix of environment variables and database rows, and the split matters. The README states that every outside source is optional and that the system is designed to run with none of them. With no API keys at all, read_crm_history still reads your own threads, meetings and signature blocks, which the README calls the best evidence available on the grounds that no data vendor can sell you a reply from the person's own address. Each additional key opens one more place to look, and the agent is told at the start of every session which ones this install has, so it plans around what exists rather than discovering gaps through failed calls. It prints that list at startup, for example a line reporting Web research as off because PERPLEXITY_API_KEY is absent, alongside Company brand data and LinkedIn reported as on. Those last two both come from a single Context key. Company brand data supplies the logo, colours, industry and the real name behind a domain. LinkedIn enrichment reads a person back from a LinkedIn URL already on their record, returning real name, current title, employer and earlier roles. The README notes this key is asked for during onboarding and stored in a row rather than set as an environment variable, because, as it puts it, a self-hoster's admin cannot redeploy to set an environment variable. Settings then General changes it afterwards.

Where this is the wrong tool

The first limitation is stated by the project itself and is not a bug: the agent will leave fields blank rather than guess. If your workflow assumes enriched records arrive complete, you will spend human time settling suggestions instead. The second is architectural. The agent is a separate deployment with its own runtime and its own work queue, so you are operating at least two systems plus Postgres, not one application. The third is the dependency split. The README is careful to say the system runs with no keys, but the features most people associate with enrichment, brand data and LinkedIn identity resolution, both route through one Context key. Without it you are relying on your own correspondence as the evidence base, which is a narrower view than a paid data source. Fourth, the README describes an Agent tab on every contact, company and deal showing steps, discarded leads and questions answered in place, and says conversations are durable. The extracted text cuts off mid-sentence at that point, so the full behaviour of that interface is not something I can confirm. Finally, the repository's default branch is release, not main, and the most recent push is dated 2026-09-02 with releases v1.15.1 through v1.15.3 landing within roughly a day of each other in late August 2026. That release cadence is worth noting before you pin a version for production.

The alternative, and the difference in approach

The obvious comparison is a conventional open source CRM with an enrichment integration, or a hosted enrichment API wired into your own database. The difference is not the feature list, it is where the decision to write lives. In the conventional setup, an enrichment call returns a payload and your code writes it, which means the write path has no notion of evidence strength. Here, tools emit observations, a ledger prices them, and only strong evidence reaches the record while weak evidence waits for a human. That inverts who absorbs the uncertainty: the conventional stack absorbs it silently into the record, and this one surfaces it as a suggestion. The second difference is scheduling. A conventional integration runs when you call it. This agent runs on its own deployment against its own queue, leases work with FOR UPDATE SKIP LOCKED, and books its own follow-ups through schedule_recheck, so closing the browser does not stop it. If you want a CRM that behaves like a database with an API, this is more machinery than you need. If you want one that behaves like a background worker with a UI attached, the model fits.

Maintenance cost and the licence question

The licence is MIT, per the repository metadata and the badge in the README, which permits commercial use and modification. I am not a lawyer and this is not legal advice, but the practical implication for a self-hoster is that the core code carries few obligations. The thing to check separately is Context. The README links to link.context.dev/crm for both company brand data and LinkedIn enrichment, and the README's own header carries a Powered by Context badge. Those two capabilities share one key and are not part of the MIT-licensed code path, so the terms that apply to that service are whatever its own agreement says, and the README does not state them. On upgrade cost, the version history shows patch releases arriving in close succession, which suggests you should read the release notes between versions rather than assuming patches are inert. The agent deployment adds a second upgrade surface: because tools, skills and the schedule are files, a change to evidence.md or identity-matching.md alters agent behaviour without touching application code, so your review process needs to cover markdown diffs and not only TypeScript.

Editorial conclusion

Adopt this if you want a CRM whose record-writing is done by a scheduled agent and you are willing to run Postgres, a Bun runtime and a separate agent deployment. Do not adopt it if you need a mature UI for a human sales team, or if you cannot tolerate an agent that returns blank fields instead of guesses. Before you commit, verify the migration path for the release branch, the licence terms of the Context key that brand data and LinkedIn enrichment both depend on, and whether your existing email and calendar data is reachable by read_crm_history without those keys.

Official sources

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