Thrive CRM
Thrive is the Hub’s CRM, and it belongs to your account rather than to any project — so a contact entered on one study is the same contact on the next, not a second copy of them. It records nothing it cannot cite, the agent proposes and a person commits, and a deal marked lost has to say why.
Every CRM that sits inside a project has the same flaw, and you only notice it about eight months in.
A contact is entered on the retail study. The same person turns up on the insurance work and is entered again, because that is a different workspace. By the time they appear on a third, there are three records, three email addresses that are slightly different, three owners who each think they own the relationship, and no single place that knows this person has been a lead, then a customer, then a partner.
Thrive sits above the projects instead of inside one. It is reached from the left rail of the Hub rather than from any project, because a relationship is not owned by a project — and the tables underneath carry no project id at all. One record per person per account, and a link to each project they touch.
A CRM you can trace is a CRM you can act on. Thrive stores one row per claimed fact, each carrying its source, and the fields you see on a contact are a cache of whichever fact is currently winning — never the thing itself.
Checked before it is written, every time. A human edit cites the person who made it; an inference cites the passage it rests on. This is a check applied to what comes back, not an instruction the model is trusted to follow.
Every judgement call is written down with its reasoning, and shown beside the run that produced it. If that number is ever zero, the rule is not working — a research pass that discards nothing is one writing down guesses.
Open any contact and each fact shows its provenance and its source next to it, a year later, when the person who entered it has left and the question actually matters.
“AI-first” usually means the software does things to your pipeline while you are not looking. That is the opposite of what a record of relationships is for.
Thrive's agent works a queue within a budget you set, reads what it is allowed to read, and writes down what it can cite. It proposes a stage change and leaves the decision to you. It cannot send anything, set a value, mark a deal won or lost, or delete a record — and those are structural limits in the routes themselves, not warnings in a prompt.
Moving a deal is a thing a person does, and it is recorded as one: who moved it, from which stage, and when.
A pipeline with Won and Lost as columns quietly inflates itself: closed business sits in the forecast, and dead deals sit in the board making it look busy. Thrive treats them as what they are — the deal leaves the pipeline and the weighted forecast on the way out.
An empty Negotiation column still shows — and an empty column is the most useful thing a board can tell you.
Price, timing, budget, went elsewhere. Thrive asks for the reason every time, because it is the only part of a lost deal anyone reads six months later.
Move a card between columns and a timeline entry names who moved it and where from. The number at the foot of each column is the money actually in it.
You can ask a rule what it found. Try asking a 62.
A signal is one condition with a real query underneath it — a deal that has not moved in a fortnight, an open deal nobody owns, an open deal with no next step written down, a contact who has gone quiet, a contact linked to no project at all. You choose which ones you want and where the threshold sits. They are evaluated against the actual records each time you open the page, and each one names the rows it matched, so the answer to “why am I being told this” is the list itself.
Every rule names its rows, so you always know what to do next. A blended score looks tidier on a dashboard while hiding the one thing you need — which part of it is wrong.
Connecting a mailbox and a calendar, so the record keeps itself, is next. It is fully specified, and it ships when it can do so on terms we would defend in public.
A mailbox token reads correspondence written by people who have never heard of VeraGen and cannot consent to it being filed. The version of this that ships will read only threads where you are a party and the other side matches a known contact or company domain — checked before retrieval rather than asked for in a prompt — will take a calendar event's title, time and attendees but never the description body, which routinely carries dial-in credentials and personal notes, and will keep its tokens in a secrets vault rather than in a database column. It ships with its scope rules, its retention window and its erasure path, or it does not ship.
Outreach through Beacon's approval chain, and assigning an Ascend course to a contact, are the two after that.
We build alongside a small, deliberately chosen group of researchers and teams — close enough that what you ask for tends to ship. Tell us what you research, and we'll open the door.
Request your invitation