Automated qualification rarely fails at the decision. It fails at the seams between the systems the decision has to cross. A form fills in one tool, the company is resolved in another, the enrichment arrives from a third, the score is computed in a fourth, and the rep finds out in the CRM eleven minutes later, or the next morning, or never.
So the useful question is not which tool scores leads best. It is which system owns the pipeline end to end, and what happens at each handoff.
Integrating qualification with the CRM and the engagement platform #
A qualification pipeline has six steps, and each one is a place where an integration can lose the thread.
| Step | What has to happen | How it usually breaks |
|---|---|---|
| Capture | The signup, form, meeting request or product event arrives | Three capture paths write three different shapes of record |
| Resolve | The person is matched to an account | Exact-domain matching misses the subsidiary and the personal email |
| Enrich | Firmographics, technographics, usage history are attached | The provider is called after the decision, or not at all for known accounts |
| Decide | Fit and intent produce a verdict with a reason | The rule reads a field that a sync has not refreshed yet |
| Write back | CRM owner, status and the reason are recorded | The reason is lost, so nobody can audit the verdict later |
| Follow up | Sequence enrolment, meeting booking, or nurture | The engagement platform enrols a contact the CRM has already disqualified |
Read the right column as a list of integration failures rather than logic failures. Every one of them is two systems disagreeing about a record.
This is why the integration question has a structural answer rather than a feature answer. What separates platforms is whether the six steps run against one record in one system, or against six copies passed between tools. Ask a vendor to show a single trace: this lead arrived here, matched this account, was enriched by these providers, scored this way against this rubric version, was routed to this rep, and produced this write-back. A platform that can show it has the pipeline. A platform that shows six dashboards has the parts.
Cargo’s version is one run over the unified account and contact models, with the CRM and the sequencer as typed actions at the end of it rather than as separate automations. The record does not leave the engine between capture and write-back, so the seams above are function calls rather than syncs.
Where AI belongs in qualification #
The useful split is between judgement and arithmetic. Deterministic rules handle everything checkable: employee count, region, plan, whether an opportunity is already open, whether the domain is on the suppression list. Those need no model, and putting them in one wastes money and adds variance to an answer that has a correct value.
What a model earns its place on is the unstructured half. Reading a company’s site and saying whether they sell to the audience you sell to. Judging from a job posting whether the team is being built or wound down. Summarising two support threads and a call transcript into a reason this account is at risk. Those are the inputs that were previously left out of scoring because they were not fields, and they are why AI changed qualification at all. LLM-powered lead scoring goes through the scoring mechanics; conversational AI for lead qualification covers the case where the qualification happens in a chat.
Three constraints keep an agent useful in this step.
Ground it in written context. The agent needs the ICP, the disqualifiers, the personas and the boundaries as files it reads at decision time, not as a paragraph in a prompt somebody edited last quarter. Without them it invents a definition of fit that sounds reasonable and is not yours.
Make it produce a reason, not just a number. An 82 with no rationale cannot be argued with, so it gets ignored. A verdict with two sentences of justification and the fields it used can be checked by a rep in five seconds, which is the difference between a score that is read and a score that is not.
Measure it. A prompt change that makes the qualifier 8 percent more generous is invisible until the pipeline review. Evals over a labelled set are what catch it, the way a test suite catches a regression, and LLM evals for revenue agents sets out what to measure.
Building qualification as code #
The last requirement is the one that separates a GTM engineering approach from a well-configured tool: the rubric is a file.
That matters for three concrete reasons. A change to the definition of a qualified lead is reviewed before it starts rejecting real leads. The version that produced a verdict is recorded, so a disputed decision is a lookup rather than an argument. And the whole pipeline can be rebuilt in another workspace, which is what makes a staging environment possible at all.
In practice it means the qualification play, the models it reads, the agent that judges the unstructured part and the routing that follows are declared together and deployed as a unit:
cargo-ai project plan # what this change would do to production
cargo-ai project deploy # ship it
The checklist for any platform in this category follows from the above, and none of it is a feature list:
- Does capture, resolution, enrichment, decision and write-back happen against one record, or across copies?
- Can a deterministic rule and a model-judged criterion sit in the same rubric?
- Is the rubric versioned, and is the version recorded on the verdict?
- Does a verdict carry a reason a rep can read?
- Can the agent read your written ICP and disqualifiers, or only a prompt?
- Is there an eval path, so a change to the qualifier is measurable before it ships?
A team that can answer those six has an automated qualification system. A team that cannot has a scoring field and a lot of integrations.
Frequently asked questions #
The integration question is really an architecture question. Tools that qualify in their own database and then sync to the CRM and the sequencer leave you reconciling three copies of the same lead. Platforms that run capture, identity resolution, enrichment, the decision and the write-back against one record, with the CRM and the engagement platform as actions at the end, remove the reconciliation instead of automating it.
Rules handle anything checkable: headcount, region, plan, open opportunity, suppression. They are cheaper, faster and have a correct answer. Agents handle the unstructured half: what a company actually sells, what a job posting implies, what a support thread says about risk. Mixing them is the point, and a rubric that cannot express both forces one of the two into the wrong tool.
Usually because the assignment ran on data the decision did not have. Enrichment lands after routing, the account match was wrong, or the capacity and territory rules live in a different system from the qualification. The fix is sequence, not more rules: resolve and enrich before deciding, and decide before assigning, in one run.
By recording the inputs, the rubric version and the reason alongside the verdict. If the only artifact is a number in a CRM field, the decision cannot be reviewed, and the first time it is wrong in a visible way the team goes back to manual lists. This is also what makes a rubric change safe: you can compare the new version against the old on the same records.
The rubric, the models it reads, the agent that judges the unstructured criteria and the routing that follows are declared in version-controlled files, reviewed as a diff, and deployed with a plan step and a rollback. The practical gain is that the definition of a qualified lead has a history and an owner, instead of being whatever the workflow tool currently says.
MaxSept 22, 2026