Skip to content
Yusuf Jojeh
LeadScope lead-intelligence dashboard with demo data
All work

Case study · Sales intelligence

ProspectIQ

Also developed as LeadScope AI

Evidence-grounded B2B research and sales intelligence.

ProspectIQ is an evidence-grounded B2B research and sales intelligence system. It combines multi-source research, deterministic scoring, Evidence Graphs, Delta Intelligence, internal Sales Knowledge retrieval and a bounded model-directed agent runtime. Consequential actions are proposed first, explicitly approved, reauthorized at execution time, executed atomically, audited, and resumed within the same AgentRun.

The system path

  1. External research
  2. Normalization
  3. Evidence Graph
  4. Deterministic signals & ICP
  5. Deterministic scoring
  6. Delta Intelligence
  7. Sales Knowledge RAG
  8. Model-directed tool runtime
  9. Capability matching
  10. Sales Copilot
  11. Write proposal
  12. Human approval
  13. Atomic execution
  14. Same AgentRun resume
  15. Grounded final result
01

Research is evidence, not prose

Every provider result is normalized into claims that carry a source, a time and a confidence. The Evidence Graph resolves those claims into facts, and FactResolver weighs sources with fixed, auditable quality weights: a crawl of the company’s own site outranks a directory listing.

Providers

  • Tavily
  • SerpAPI
  • Apify
  1. Normalization
  2. Evidence Graph
  3. FactResolver
  • Source quality
  • Freshness
  • Contradictions
  • Coverage

Apify only runs actors the backend allowlists. The model cannot pass an actor ID, and there is no tool for fetching an arbitrary URL.

02

The score belongs to the backend

ICP fit, signals, digital maturity, the score breakdown and deltas are all computed in code. The model interprets the result. It never computes the facts it is interpreting.

  • ICP match
  • Signals
  • Digital maturity
  • Score breakdown
  • Deltas

Digital maturity, as the code computes it

Official website20
Mobile responsive10
Online booking15
E-commerce15
WhatsApp10
Social presence≤ 15
Contact channels≤ 15
Review volume5
Structured services5

Capped at 100. Low below 40, medium from 40, high from 70.

03

What changed?

A new research run is compared with the last one, fact by fact. Only a real change in a canonical fact becomes a change event, and its effect on the score is recalculated by the same deterministic rules.

  1. Previous research
  2. Current research
  3. FactDiffEngine
  4. ResearchChangeEvent
  5. Deterministic score impact
  6. Optional explanation

Changes it tracks

  • Online booking added
  • Branch count changed
  • Rating moved
  • New service listed
  • WhatsApp added
  • Hiring activity

The model never decides whether something changed. It can only explain a change the diff engine has already recorded.

04

Two kinds of knowledge

Lead evidence

What is true about the prospect?

Tavily, SerpAPI and Apify research, plus earlier runs.

Sales knowledge

What can we credibly sell them?

Services, case studies, playbooks, past proposals and internal docs.

  1. Capability match
  2. Supported opportunity
  3. Grounded outreach

No supported match

When nothing in the knowledge base fits, the Copilot says so. It does not invent a service to make the answer look better.

Retrieval sized to the corpus

Sales knowledge lives in MariaDB. Tenancy is filtered inside the query, then cosine similarity runs in Python over a bounded candidate set. The retrieval architecture is sized to the current corpus instead of adding vector infrastructure without a measured need. Retrieved text is always treated as untrusted.

05

A real agent runtime

The model picks each tool based on what the previous tool returned. The backend validates the arguments against the tool’s schema, checks workspace and permissions, runs it and hands the result back. The order of calls is never scripted.

  1. 01Model chooses a tool
  2. 02Schema validation
  3. 03ToolRegistry
  4. 04Permission and workspace checks
  5. 05Read or research tool runs
  6. 06Result returns to the model
  7. 07Model decides the next step

Tool classes

Read
Lead, evidence, score, history and deltas
Research
Tavily, SerpAPI and allowlisted Apify crawls
RAG
Sales knowledge, playbooks and case studies
Write proposal
Notes, follow-ups, tasks, stage, tags and drafts, as previews
Action
Deep-research requests and external sends. Sending is high risk and off by default

34 registered tools across five classes.

Server-side budgets cap steps, tool calls, searches, crawls and runtime, and identical repeated calls are blocked. One shared runtime serves every agent profile: research, sales copilot, read-only and admin.

06

AI can propose. The backend executes.

Proposal-time permission is never trusted at execution time.
  1. 01LLM proposal
  2. 02AgentAction
  3. 03Exact preview
  4. 04Human approval
  5. 05Current-user reauthorization
  6. 06Payload hash verification
  7. 07Atomic claim
  8. 08Domain service
  9. 09Execute once
  10. 10Audit

Expired, rejected or tampered actions cannot run, and approving an action that has already executed changes nothing.

07

Same-run resume

When the run reaches a consequential action it stops and waits. After the backend confirms the approval, the same AgentRun continues on the same live stream. No new workflow is started.

  1. Queued
  2. Running
  3. Waiting for approval
  4. Running
  5. Completed

Queued

Live streamAgentRun · same run

    An interactive replay of the lifecycle and its real event names, not a recording of a run.

    Live event streaming with persisted replay and reconnect support.

    Release verification

    Gates from the latest release run.

    Backend

    • Ruff · clean
    • mypy strict · 235 source files, no issues
    • pytest · 519 passed, 0 failures

    Frontend

    • TypeScript · 0 errors
    • ESLint · clean
    • Vitest · 52 passed
    • Production build · passed

    End-to-end

    • Playwright · 202 passed
    • 19 intentional skips
    • 0 unexpected failures

    Live, demo and stub modes are explicit, and production fails closed instead of falling back to demo data.

    Accessibility, in specifics

    • Dialogs return focus to the control that opened them
    • Focus stays trapped inside open dialogs
    • Copilot, Evidence Graph and Research History are labelled regions
    • Every select on the lead page has an accessible name
    • Map markers are named after the company
    • Live regions stay bounded during a Copilot run
    • Statuses carry text, not only colour
    • Arabic right-to-left
    • 390px mobile without horizontal overflow

    Audited with axe-core against WCAG 2.1 A and AA on the new surfaces and the lead page. Contrast was checked against the design tokens.

    Real screens

    Captured from a local build of the web app. The marketing strip under the hero is cropped out: it carries placeholder claims, not verified figures.

    LeadScope landing page: Evidence-first lead intelligence
    Landing screen
    LeadScope workspace sign-in screen
    Sign-in screen

    Inside the product

    Logged-in screens from a local build running on the project's own demo seed. The names, units and amounts are fictional test data, not production figures.

    Lead intelligence desk
    Lead intelligence desk
    Lead workspace
    Lead workspace
    Lead detail with evidence
    Lead detail with evidence
    Evidence-grounded AI analysis
    Evidence-grounded AI analysis
    AI outreach drafts
    AI outreach drafts
    CRM pipeline
    CRM pipeline

    Architecture

    FastAPI, Pydantic v2, SQLAlchemy 2 and Alembic on MariaDB. Research through Tavily, SerpAPI and allowlisted Apify actors. A single agent runtime with a typed ToolRegistry, an approval gate and live event streaming. A React, TypeScript and Vite frontend, Docker Compose.

    Stack

    FastAPI · Pydantic v2 · SQLAlchemy 2 · Alembic · MariaDB · React · TypeScript · Vite · Docker Compose · GitHub Actions

    Source

    Private repository

    Next

    Dhura    Discuss this system