Why a CRM Needs an Agent That Can Refuse to Guess
trycompai/crm is an open-source CRM designed around an AI agent, not an AI chat box attached to a conventional database. This series examines how that change affects the system of record, the work needed to keep it useful, and the boundaries required to make automation trustworthy. The practical question is simple: how can a CRM improve its records without turning plausible guesses into facts that nobody knows to question?
The problem is not only data entry
A conventional CRM usually presents a familiar arrangement. The database stores companies, contacts, deals, and activities. Forms give people a way to add information. Lists and record pages make the information available later. The system is useful, but it assumes that a person will do the difficult work around the form: discover what is true, decide which sources deserve trust, notice what has changed, and write the result into the right field.
Adding a chat box does not remove that responsibility. It gives the human another way to ask for help, but the human still has to decide whether the answer is correct and whether it belongs on the record. A fluent answer can even make the problem worse. When a model supplies a plausible name, title, or employer, the result looks finished. The record stops displaying the uncertainty that should have prompted a check.
Comp AI CRM starts from a different premise. Its README describes the agent as the place where the CRM keeps its notes. The agent runs in its own deployment, follows its own work queue, chooses what to inspect, books follow-ups, spends a research budget, and continues after the browser closes. That is a substantial change in responsibility. The product is no longer only a surface for reading and editing data. It is a system that performs ongoing work on the data it stores.
That promise also creates a harder obligation. If the agent can keep working without a person watching every step, the record needs a reliable way to distinguish an observed fact from an attractive inference. The agent must sometimes stop with an incomplete record. In this design, “nothing about a person is guessed” is not a slogan added after the automation exists. It is the constraint that determines what the automation is allowed to do.
The agent belongs inside the record system
The most important relationship in trycompai/crm is between the CRM and its agent. The agent is not an independent assistant that happens to read CRM data. Its work is meant to improve the records that salespeople use, and the record remains the durable place where the result, its source, and its unresolved questions can be found.
That relationship does not mean every component should make decisions. The repository gives the API a narrower job. It serves HTTP requests, authentication, tRPC procedures, and mailbox synchronization. When a CRM event needs interpretation, the API writes an AgentTask row. The agent later leases that row, reads the relevant CRM context, decides what the evidence means, and uses authored tools to file the result. The API reports that something happened. The agent decides what it means.
This separation matters for two reasons. First, a task row can remain after the agent is unavailable. An HTTP request that waits for a model or a vendor has a short lifetime. A durable row carries the subject, reason, timing, budget, and lifecycle state beyond that request. Second, it gives judgment one clear owner. Enrichment, identity matching, scoring, and summarization do not appear as duplicated fallback logic in the API. They belong to the agent's evidence and tool layer.
The boundary is not absolute independence. The API, database, and agent share contracts for records, events, tasks, and validation. That shared vocabulary is useful because both sides must agree on what work exists and which record it concerns. It also creates a maintenance responsibility: a change to a shared contract can alter the meaning of work in more than one process. The design gains a clear division of judgment, not freedom from coordination.
Four questions define trustworthy automation
The product's central theme becomes easier to follow through four connected questions.
Who decides? The CRM stores business records, but the agent owns interpretation. A task can say that a contact was created or a meeting is approaching. It does not decide who the person is or what their role means. That decision stays in the agent's research flow, where the available context and evidence can be inspected together.
What counts as evidence? The system does not ask the model to attach a confidence score to its own answer. Tools report what they observed. A reply on a CRM thread, an email signature, a published email address, or a matched account identity has a different evidentiary meaning from a web page that merely states a claim or a handle that resembles a name. The ledger keeps those distinctions instead of reducing them to one feeling of plausibility.
How does work persist? A useful decision is not useful if the task disappears when a process restarts. Work needs a due time, a lease, an attempt count, a completion state, and an explanation of what happened. It also needs a visible response when it becomes slow or stuck. Persistence is therefore part of correctness, not only an infrastructure concern.
What may leave the system? The agent can inspect internal CRM context, but the product must also define which context can cross the record boundary and which actions remain outside the agent's authority. That boundary matters as much as the model's answer, because useful automation must not turn access into unrestricted disclosure or action.
These questions reinforce one another. Evidence without persistence produces a good decision that vanishes. Persistence without evidence produces a durable wrong answer. Both become unsafe if the agent can send arbitrary record content or perform actions outside its authority. The CRM needs all four relationships to hold at once.
Refusal is a product capability
Most automation systems are designed to produce an output. Comp AI CRM treats a bounded non-answer as a valid result. The evidence model assigns different weights to observations, distinguishes primary sources from supporting clues, and gives contradiction its own meaning. When two sources disagree, the system holds the claim rather than averaging the disagreement into a number that looks precise.
That design changes what success looks like. A strong, directly identifying source can support a fact on the record. A weaker result can become a proposal for a representative to review. Evidence below the keeping floor is not preserved as a polished but unsupported statement. The tool records the observation only when the evidence model says it has enough value to retain.
The important point is that the model does not get to choose the outcome by describing its own certainty. The tool contract requires evidence entries with a kind, a detail, and, when available, a source URL. The ledger computes a score and a rationale from those observations. A human can therefore ask not only “What did the agent write?” but also “What did the agent actually observe, and why did the system treat that observation as sufficient?”
This does not turn the score into truth. The weights and thresholds are design choices in the repository, not an independently validated accuracy model. The system still depends on the quality and freshness of its sources. Its contribution is narrower and more practical: it prevents the model from silently upgrading a guess into a fact, and it makes disagreement visible enough for a human to resolve.
A blank field can be honest. In a sales record, missing information is visible. A wrong value often is not. Nobody knows to verify an employer that looks ordinary on a contact page, or a name that has been copied from the wrong profile. Refusal protects the future reader from an error that has lost its warning label.
The whole system in one view
The following map shows the relationships that matter more than any individual feature.
The decisive edge is not simply “CRM to model.” It is “observed evidence to a bounded outcome.” The task row gives the work a durable identity. The agent reads relevant context and budgets vendor work. The evidence layer decides whether the result can be written, offered for review, or left unresolved. The representative sees the outcome in the same record that motivated the work.
That arrangement also explains why the system treats scheduling and health as part of the product. A task that is still queued, a session that has not linked back to its task, and a sweep marked as wedged are different conditions. If the interface collapses them into one spinner, the CRM tells a misleading story about its own knowledge. A durable agent needs to say what it knows, what it is doing, and what it could not establish.
What this design can and cannot promise
The repository gives strong evidence about design intent and implementation mechanisms. It shows how the current release separates API reporting from agent judgment, stores evidence with facts, persists tasks and sessions, and tests important failure paths. It does not prove production accuracy, adoption, uptime, or scale. It does not show that every provider returns current information, or that every ambiguous contact can be resolved.
That distinction is especially important for an agentic CRM. The product's value is not the claim that a model always knows the answer. Its value is the attempt to make the boundary between knowing and not knowing operationally meaningful. A system that can write only when its evidence rules permit it, preserve work when a process fails, and expose uncertainty to a human can be more useful than one that answers every question fluently.
The rest of this series follows that claim through the system itself. It first examines how the API, task queue, agent, and record divide responsibility. It then looks closely at the evidence and identity rules, follows work through leases and recovery, and examines the security boundary around internal data and external actions. The final question is not whether the CRM has an agent. It is whether the agent has earned the authority to change what the CRM says.