THE AGENT THAT
ALREADY KNOWS YOU.
Your qualification flow is polite, fast and competent. It also asks a customer of three years what their company does. The channel has no memory, because nothing gave it one.
EVERY CONVERSATION STARTS AT ZERO.
Qualification got automated first, because it is the most repetitive thing in sales: a form, a chatflow, sometimes an agent — company size, budget, timeline, what brings you here today.
It works, until the person on the other side is not a stranger. A customer who renewed twice, a prospect who had a call in spring, someone whose colleague is already in a deal. They get the script for a first-time visitor, and the message it sends is unmistakable: we have no idea who you are.
The flow is not at fault. It reads the conversation, and the conversation began ninety seconds ago. What it would need is the account — the history, the open deal, the last note — and that lives in a system the channel was never connected to in a way an agent can read.
READ FIRST. THEN ASK.
The account before the first question
Before the flow asks anything, an agent can read the Context graph: is this person known, which company do they belong to, what was agreed last time, is there an open deal.
Typed edges make that a lookup, not a guess — and the agent can name the objects it read.
The channel stays yours
CMP42 is headless. It ships no chat widget, no inbox and no bot. Whatever you qualify in today — a form, a messenger, a call, your own agent — keeps working.
What changes is what that channel can read before it speaks, through MCP tools or the API.
What was learned becomes context
Answers worth keeping are written back as objects, attributed to the agent that captured them, and can be held for review by a Process before they count.
The second conversation starts from more than the first did. That is the whole compounding effect, and it only works if writes are structured.
NOT A TRANSCRIPT. AN ACCOUNT.
The sketch on the right illustrates the idea: a qualification object that records what was asked and answered, linked to the person, the company and the conversation it came from.
The point is the edges. A returning contact resolves to a company, a company to its open deals and past notes — so "have we spoken before" is a traversal, not a question put to the customer.
Models are validated at write-time, so an answer that does not fit your ontology gets a clear error instead of a free-text field nobody reads again. How Models work →
# illustrative - the idea, not the final syntax
qualification:
fields:
asked: string[] # what the flow actually asked
answered: string[] # and what came back
outcome: enum[qualified, nurture, declined]
captured_by: enum[human, agent]
edges:
about: contact
at: company
from: conversation
informs: deal? # when one already exists
# the agent reads contact -> company -> deals
# before it asks anythingA CUSTOMER, NOT A LEAD.
The question that never gets asked twice
A fictional B2B team qualifying inbound through its own agent. The steps show how the concepts fit together — it is not a customer story, and details of the interface will change during Alpha.
- Someone starts a conversation on the website. The address matches a contact that already exists in the graph.
- Before the agent writes its first line, it reads the account through MCP: the company, an open deal, a note from a call in spring, and the colleague who owns it.
- It skips the four questions that already have answers and asks the one that does not — whether the timeline from spring still holds.
- The answer is written back as a qualification object, attributed to the agent, linked to the contact, the company and the existing deal.
- A Process routes it to the deal owner, who corrects one detail and approves. The next conversation, in whatever channel, starts from that.
WHAT THE ALPHA DOES — AND DOES NOT.
CMP42 is the layer an agent reads before it asks. It is not the thing that does the asking. The line matters, so here it is.
What works today
- Agents read the account before they speak, through MCP tools, with REST and GraphQL parity.
- Answers are written back as typed objects, shaped by your Models and validated at write-time.
- Every write says who produced it, and a Process can hold it for human approval.
- Your channel is untouched. Whatever you qualify in today keeps working; CMP42 adds what it can read.
What is not there yet
- CMP42 ships no chatflow, widget or bot. There is no qualification UI to configure — the flow stays in your tool.
- There are no messaging or telephony connectors. No WhatsApp, no phone system, no shared inbox. Your channel reaches CMP42 through the API or an MCP client.
- Identity resolution is your ontology’s job. How an address or a phone number resolves to a contact is something you declare, not something CMP42 guesses.
- No numbers on this page. Alpha begins in October 2026; anything measured will come from Design Partner case studies or not at all.
THE FASTEST ANSWER IS THE ONE NOT ASKED.
Qualification gets shorter, not smarter. The agent asks fewer questions because fewer are open, and the person on the other side notices the difference immediately. Why we built it this way →
Bring your qualification flow to the call
If your flow already works and only lacks memory, that is a precise thing for us to build against during Alpha. Strong applications describe the flow they run and the question it should stop asking.
→ Apply to be a Design Partner- Customers stop being treated as strangers, which is the cheapest respect a system can show.
- Fewer questions, better answers. The one question left is the one that actually moves the deal.
- What was learned survives the conversation as objects, not as a transcript nobody opens.
- Keep your channel. No new interface for your team, no migration before value.
- Managed in the EU or self-hosted. On the managed tier CMP42 does not train on your data. DPA on request.