Inside the CRM That Treats the Database as a Side Effect

The Inversion

Most customer relationship management systems begin as a database and accrete intelligence later. The conventional architecture—compiling data from websites, telephone, email, live chat, and social media into a single source of truth—is fundamentally a ledger with a user interface bolted to the front. Salesforce notes that the average organization juggles close to 900 different applications, yet only 29 percent are integrated, which leaves humans acting as the glue between silos. Even the newer wave of AI-enhanced platforms, which Gartner predicts will embed task-specific agents in forty percent of enterprise applications by the end of 2026, typically treats the agent as a chat window sitting beside the same old forms. The human still does the actual work of deciding what is true and typing it in.

trycompai/crm rejects this sequence entirely. Its README opens with a provocation: the durable research agent is the product, and the database is merely where it writes things down. This is not a CRM with an assistant; it is an assistant that happens to keep a CRM. The agent runs on its own deployment, consumes its own work queue, and operates on its own schedule. Close the browser, and it continues researching, booking follow-ups, and spending a configured research budget until that budget runs out. Nothing about its behavior is request-response, which means the system is designed for continuity rather than conversation.

An Epistemology of Customer Data

Where conventional platforms might use an enrichment API to guess at a contact’s employer or infer a lead score, this project enforces a stricter epistemology. The authors state bluntly that nothing about a person is ever guessed. No tool is permitted to return a confidence score, because a model asked to grade its own certainty will tend to answer in the direction that makes it look useful. Instead, tools report only what they observed—an email signature block, a GitHub account identity—and a ledger prices the evidence. Strong evidence writes to the record; weak evidence becomes a suggestion that a human must settle.

This discipline addresses one of the persistent failures of AI-assisted CRM: confidently wrong data. A blank field is at least honest; a fabricated detail about a customer is worse because it erodes trust silently. The approach mirrors a broader industry anxiety. Infosys research notes that untrustworthy or incomplete data remains one of the most stubborn challenges in CRM adoption, and that initiatives like personalized customer service or cross-selling often fail to generate value precisely because the underlying data cannot be trusted. AgileCRM cites administrative tasks as accounting for up to forty-eight percent of sales team frustrations, much of it rooted in bad data entry. By refusing to let the model hallucinate facts into the database, trycompai/crm treats data integrity as a first-class architectural constraint rather than a training problem.

The Security Model of a Paranoid Clerk

The project’s security posture is equally uncompromising, though it arrives at minimalism through a different route. The agent operates inside a sandbox with deny-all network egress and no access to the database credentials. The shell can run grep and diff against a local workspace, turning the model into a text processor rather than a privileged user. Any web fetching happens outside the sandbox, in the application runtime or at the model provider, which removes the only path by which a customer’s email body could exit through a shell command.

At the application layer, the system is single-tenant and internal by design. Authentication is Google-only, authorization is a single environment variable containing an allow-list, and everyone who gets in can see everything. There are no organizations, no role-based access controls, and no pretense of multi-tenancy. The authors argue that an organizationId column that always holds the same value is just a permissions check that buys nothing and reads like a real one at review time. This honesty is refreshing, even if it limits the project to teams comfortable with a flat trust model.

Architecture as Argument

The API layer, built in NestJS, is deliberately brainless. It reports that something happened—a thread was ingested, a company was created, an attendee is unknown—by writing a row to a queue. The agent leases that row and decides what it means. The documentation even notes that calling an enrichment API from a Nest service is treated as a bug, with an outage story in the API docs to explain why. Intelligence lives only in the agent.

That agent is built on Vercel’s eve framework, which treats tools as files, skills as markdown, and schedules as code. The runtime handles durability: sessions survive redeploys, and work resumes where it stopped. The work queue uses database-level leasing so multiple dispatchers take disjoint tasks, and a crashed run frees its row when the lease expires. When the agent wants to revisit a contact in fourteen days, it schedules a recheck and records the reason, which is then shown to the human rep. An agent that cannot explain why it will be back does not have a reason; it has a default.

Every external data source is optional. With no API keys at all, the agent still functions by reading the team’s own email threads, meeting notes, and signature blocks—sources that no third-party vendor can sell and that often constitute the best evidence available. At the start of each session, the agent prints which keys are present and plans around the gaps rather than discovering them one failed call at a time. If a rep wants to talk to it, an Agent tab on every contact and company page exposes its reasoning: the leads it discarded, the steps it took, and the questions it could not resolve. These conversations are durable and survive a reload, because the record travels in a signed token rather than being bolted onto the front of a message.

The Limits of Going Solo

For all its architectural clarity, the project is tightly bound to its own opinions. It assumes the Vercel ecosystem—eve for agents, AI Gateway for models, Vercel Sandbox for isolation—and runs on Bun. The frontend is Next.js, the database is Postgres, and the entire stack is optimized for a Vercel-shaped deployment. This is not a criticism, but it is a constraint: migrating the agent to a different runtime would require rethinking its durability guarantees.

The single-tenant design also means it will not become the next Salesforce. It is explicitly not a platform for selling to multiple customers; it is an internal tool for a single team that trusts its members. In a market that HubSpot estimates will exceed $145 billion by 2029, dominated by vendors chasing scale through multi-tenancy and broad integrations, trycompai/crm occupies a deliberately narrow niche. It is the anti-platform: open source, opinionated, and hostile to the idea that a CRM must be everything to everyone.

The Agentic Turn

That niche may be more interesting than it first appears. The CRM industry is currently racing to embed agents, with Salesforce’s Agentforce and Creatio’s native AI agents promising orchestration across customer-facing workflows. Infosys research identifies orchestration between systems as the most popular AI use case and one of the most likely to deliver value, extending beyond simple automation to richer end-to-end processes. Yet most of these initiatives still treat the agent as a layer on top of a conventional database. trycompai/crm asks what happens if you start from the opposite assumption: that the agent is the kernel, and the CRM is a read-only projection of its research.

It is an open-source bet that the future of customer relationship management is not a smarter form, but a clerk that never sleeps, never guesses, and keeps its own notes. Whether that clerk can scale beyond small, technical teams remains an open question. For now, it is one of the few CRM projects honest enough to admit that its database is just a filing cabinet.