How Boldare Built an AI Sales System That Runs on Its Own Pipeline, 24/7
Manual lead research doesn’t scale with pipeline volume. It scales with however much time whoever’s free that day happens to have. We ran into that limit ourselves before we built anything to fix it.
The first version of what’s now the KYC Research Agent did one job: when a new deal landed in Pipedrive, it ran basic qualification and posted a summary to Slack. Nothing else. No stakeholder mapping, no digest. We wanted to know if an agent could produce a judgment a rep would actually act on before building anything more ambitious on top of it.
Table of contents
The duplicate that taught us about trust
The first real bug showed up as a disagreement. The same company would get qualified two different ways depending on which of two parallel runs a rep happened to open. Pipedrive was firing two triggers per deal, and both were running full qualification independently.
The mechanical fix was straightforward: one run produces a result, the second gets skipped. The part that took longer to notice was what the two runs did when they disagreed on a number. Revenue estimates 30% apart, headcount off by a factor of two. The early version picked one and moved on without saying so. Nobody had told it to hide the discrepancy. It just seemed like the reasonable default until someone checked a figure against a second source and found daylight between them.
That became the fact-grounding rule now built into the agent: every numeric claim carries a citation or an explicit “unverified” tag, and a gap over 30% between sources gets reported as a flagged divergence instead of quietly resolved. Small change on paper. It’s the difference between a system a rep double-checks out of habit and one they stop double-checking, which is either the whole point of building it or a liability, depending on whether the number underneath is actually right. Our other article covers this same grounding rule from the other side, as part of the qualification logic a team can plan for before running into the disagreement themselves.
The owner who left
A separate issue surfaced later, and it had nothing to do with data quality. It was about who a lead got assigned to.
The default-owner rule pointed to a specific person by name. That held until the person’s account went inactive. New leads kept routing to them anyway, because nothing in the logic distinguished “the person this rule was written for” from “whoever currently holds the role.” A routine audit caught it, not an alert or a complaint. Routing rules built on a name instead of a role don’t break loudly. They keep running exactly as designed, against a target that no longer exists.
The fix moved ownership to role-based routing with an active-account check on top. It’s a two-line change. Finding it took someone actually reading through weeks of assignment history and noticing a pattern that no dashboard was surfacing on its own.
Adding the digest, then adding judgment to the digest
Once the KYC agent had been through both fixes, we built the pipeline digest: a weekly summary posted to Slack instead of assembled by hand on a Friday afternoon. The first version listed every open deal with the same visual weight, which meant the two or three deals that actually needed a decision got lost in a wall of routine status updates.
Later iterations gave the digest a different shape: hot deals with context on why they mattered today, at the top; deals over 90 days stale compressed into a single line instead of listed individually; a weekly scan for market signals (hiring pages, funding news) attached to active deals with a ready-made angle for follow-up. None of that was in the original spec. It came from watching which parts of the weekly message people actually read and which parts they scrolled past.
Stakeholder mapping came last, deliberately. It needs clean CRM activity data to produce anything useful, and that data was only reliable once the earlier two systems had stabilized. Mapping decision-makers off noisy inputs produces a map that looks exactly as confident as a correct one, right up until a deal stalls and nobody can explain why the wrong person got the pitch.
What actually changed
The depth of qualification no longer depends on what the week looks like. Before, thoroughness tracked who had a free morning. Now it doesn’t track anyone’s calendar at all.
Deals still stall. Fewer of them stall silently. A digest that surfaces momentum loss on a Monday gives someone a chance to do something about it while the deal is still warm instead of finding out at a quarterly review that it went cold six weeks ago.
What we’d sequence differently
Building the KYC agent first was right. It had the most obvious failure mode, wrong qualification, so its bugs surfaced fast, before anything else was built on top of them.
Ownership and routing got less attention than the qualification logic did, and that gap is exactly the kind that doesn’t announce itself. Nobody notices a routing rule pointing at an inactive account until someone goes looking. We’d build the active-account check in from the start, not patch it in after a routine audit turned it up.
The system still runs on our own pipeline. That’s the reason we now build the same pattern for client sales teams: the architecture (trigger, agent, review checkpoint, digest) doesn’t change from one CRM to another. The qualification rules and the integration layer do.
If a similar system might fit your own pipeline, the useful first question isn’t what it should do. It’s what it will get wrong first, and how you’d find out.
Share this article:
