Building an Agentic-First CRM: Redefining Customer Interaction

Beyond Forms and Chatbots: The Agentic-First CRM Paradigm

For too long, Customer Relationship Management (CRM) systems have largely remained static databases with a graphical interface bolted on. Even the latest wave of "AI CRMs" often fall into the trap of merely adding a chat window to the existing form-based data entry model. This approach fundamentally misunderstands the core problem: the actual work of discovering what's true about a customer, and then recording it accurately, is still offloaded to humans who have more strategic tasks to accomplish.

This open-source CRM flips that script entirely. Here, the durable research agent is the product, and the CRM itself is simply where this agent meticulously records its findings. It's a fundamental shift from human-centric data entry to autonomous, intelligent research.

How the Agent Takes the Lead

This system is built from the ground up to be agentic. The agent isn't an add-on feature; it's the core intelligence, running independently on its own deployment and schedule. It operates against its own work queue, making autonomous decisions about what to investigate next, scheduling follow-ups, and managing a research budget, halting only when that budget is depleted. Crucially, its operation is not request-response based; it continues its work even after your browser is closed.

One of the foundational design principles is that intelligence never lives in the API. The NestJS API's role is strictly to report events: a thread was ingested, a company created, an attendee is unknown. It writes these events to a queue, and it's the agent's responsibility to lease those rows and interpret their meaning. Calling an enrichment API directly from a Nest service is considered a bug, a rule born from past outages where two identity matchers diverged, leading to incorrect data.

The agent also adheres to a strict rule: nothing about a person is guessed. Tools do not accept confidence scores because models tend to overstate their certainty, often incorrectly. Instead, tools report raw observations (e.g., crm.signature-block, github.account-identity), and an internal ledger prices the evidence. Strong evidence directly updates the record, while weaker evidence becomes a suggestion for human review. This prevents confidently wrong facts about a customer, which are far more detrimental than a blank field, as they can be difficult to detect.

Designed for internal, single-tenant use, the CRM employs Google for sign-in, with an allow-list controlled by a single environment variable. This straightforward authorization model means anyone granted access can view all data, emphasizing its internal utility and requiring careful consideration for security.

The Agent Under the Hood

At the heart of the system is apps/agent, a self-contained deployment leveraging eve, Vercel's filesystem-first framework for durable agents. eve provides a robust runtime where tools are defined as files, skills as markdown documents, and schedules as code, ensuring sessions survive redeployments and work resumes seamlessly.

The agent comes equipped with 18 authored tools, such as read_crm_history, search_crm, identify_contact, and enrich_company. It also utilizes 4 skills (e.g., evidence.md, identity-matching.md) written in prose, allowing the agent to read and understand complex instructions, versioned just like code. The dispatch.ts schedule is minimalist, simply leasing due tasks and initiating a session for each, ensuring efficient, parallelized processing. The work queue, lib/tasks.ts, uses FOR UPDATE SKIP LOCKED to allow multiple dispatchers to process distinct tasks, and ensures that abandoned runs free their rows when leases expire. This setup allows the agent to intelligently schedule future actions, explaining its reasoning (e.g., why it's rechecking a contact in 14 days) to the representative.

Remarkably, the agent is designed to function even without any external API keys. Its ability to read_crm_history to analyze internal threads, meetings, and signature blocks provides invaluable, free-of-cost evidence—often superior to what any data vendor can offer. Each API key simply expands its research capabilities, and the agent intelligently plans its operations based on the available integrations, listing them at startup:

[agent] on LinkedIn (RAPIDAPI_KEY) [agent] off Web research (PERPLEXITY_API_KEY) [agent] off Company brand data (CONTEXT_DEV_API_KEY)

A Secure Sandbox Environment

The agent's environment includes a highly restricted sandbox with bash, grep, glob, and a /workspace, operating under a deny-all egress policy. This sandbox has no direct network or database access. Enabling it provides the model with a powerful shell, transforming it from a mere tool-caller into a system capable of maintaining dossiers, diffing profiles, and extracting data from threads—all without the risk of exfiltration. By preventing shell commands from making network requests or accessing DATABASE_URL, the design ensures that sensitive customer data, such as email bodies, cannot leak through the sandbox; it remains a text processor, nothing more.

Users can interact with and observe the agent's progress through an "Agent tab" on every contact, company, and deal record. This tab displays the agent's steps, its reasoning for discarding leads, and allows reps to answer its clarifying questions directly. Conversations are durable, surviving reloads, with records transferred via signed tokens. Enabling this bridge between the agent and the UI requires setting the AGENT_BRIDGE_SECRET to the same value in both processes.

Technical Architecture: A Modern Stack for Durability and Speed

The CRM is built as a Turborepo monorepo, leveraging Bun, and designed for deployment on Vercel. Its robust stack includes:

• Agent: eve for durable sessions, tools, skills, schedules, and sandboxes.
• Model: Vercel AI Gateway, abstracting model providers and managing OIDC-based authentication without direct API keys.
• Sandbox: Vercel Sandbox in production, with Docker or microsandbox for local development.
• Front end: Next.js App Router, shadcn/ui for components, and nuqs for managing URL-driven state.
• API: NestJS with nestjs-trpc, providing HTTP, authentication, tRPC endpoints, and Google synchronization.
• Data: Prisma ORM, Postgres (Neon), with optional Redis (Upstash) for caching.
• Auth: Better Auth, configured for Google-only sign-in with a single allow-list.
• Files: Vercel Blob for mirroring profile pictures, ensuring data persistence.
• Tooling: Biome for linting and formatting, with TypeScript enforced across the entire codebase.

The app communicates with the API via tRPC, generating a router type directly from NestJS, ensuring end-to-end type safety from the Prisma database row to the UI table cell. List state, including filters, sorting, and pagination, is embedded in the URL, making views easily shareable and reproducible by simply copying the address bar.

Core Codebase Principles

Three guiding principles underpin the codebase:

1. Intelligence never lives in the API: Reinforces the agent's role as the sole decision-maker based on API events, preventing inconsistencies seen when logic duplicates.
2. packages/ui is the only source of UI: Enforces design consistency by prohibiting overriding styles at the call site.
3. There are no organizations: Deliberately single-tenant, avoiding unnecessary complexity and security overhead of multi-tenancy for an internal tool.

Getting Started: A Quick Setup

To begin, you'll need Bun and Docker. The setup is straightforward:

bash git clone https://github.com/trycompai/crm.git && cd crm bun install docker compose up -d # Postgres on :5432 cp .env.example .env # then fill in the four values below bun run db:deploy # apply migrations bun run db:seed # optional: a believable pipeline to look at bun run dev

The app will be accessible at localhost:3000 and the API at localhost:3001. The essential .env variables include BETTER_AUTH_SECRET, ALLOWED_SIGN_IN, GOOGLE_CLIENT_ID, and GOOGLE_CLIENT_SECRET. Setting up the Google OAuth client is a quick process in the Google Cloud console, requiring the addition of http://localhost:3001/api/auth/callback/google to authorized redirect URIs and enabling the Gmail and Calendar APIs.

A New Frontier for CRM

This agentic-first CRM represents a significant evolution in how businesses manage customer relationships. By offloading the tedious, time-consuming research and data synthesis to intelligent agents, it frees up human talent to focus on strategic engagement and relationship building. It’s a powerful testament to what's possible when AI is truly integrated as an autonomous partner, rather than a bolted-on feature, paving the way for more efficient, accurate, and proactive customer interactions.

FAQ

Q: Why did the creators choose an "agentic-first" approach instead of integrating AI into a traditional CRM structure?

A: The agentic-first approach addresses a fundamental limitation of traditional CRMs: they leave the intensive work of research and data entry to humans. By making the agent the core product, the system automates discovery, fact-finding, and record-keeping autonomously. Integrating AI into a traditional CRM often just adds a chatbot, leaving the core process unchanged. This design ensures the agent performs the actual work, with the CRM serving as its intelligent notebook, reducing human effort and improving data quality by design.

Q: How does the system ensure data accuracy and avoid common AI issues like "hallucinations" or incorrect assumptions?

A: Data accuracy is paramount, enforced by a strict rule: "nothing about a person is guessed." Tools report only observed facts, not confidence scores. This verifiable evidence is then evaluated by a ledger. Strong evidence is recorded, while weaker or uncertain evidence is flagged as a suggestion for human review. This prevents the system from confidently recording incorrect information, which is considered worse than a blank field, as it's harder to detect and correct than a missing fact.

Q: What are the key security considerations for developers looking to deploy and use this CRM?

A: The CRM is explicitly designed as single-tenant and internal. Authentication is Google-only, controlled by an ALLOWED_SIGN_IN allow-list, which is the entire authorization model. Developers must be aware that all users on the allow-list can see all data. The agent's sandbox is also designed for security with deny-all egress and no DATABASE_URL access, preventing data exfiltration through shell commands. It's crucial to consult SECURITY.md before deploying with real customer data and understand that it's built for internal use cases.