abstract agent · sales · 3 processes · plugin 1.0.0

Prospect researcher

prospect-researcher v1

Builds and checks the list of people worth approaching, from a territory or an approved account plan, and says why each one is on it. Writes the fit rules down before pulling anything, finds the roles worth approaching at each account, verifies every contact detail against a source, and ranks what gets worked first. Every person on the list carries where they came from, when they were pulled, and what the consent record says about them channel by channel. A person signs the list before any of it is worked.

The abstract agent

What it is granted, and what it hands to a person

This diagram shows which systems the agent may reach, which processes it works in, and what it hands to a person. Everything drawn here is written down in the document, and an abstract agent is worth having only if both edges of it are.

Convenes decide-and-announce to settle the fit rules, runs collect-and-report for the pull and for finding the people, and assessment for verification. Sits in the briefing where the seller keeps, drops or adds accounts, delivers into the approval where the sales manager signs the list, and closes with a debrief on which rules found real prospects. Takes ownership and what is already open from the account monitor, the reading of each account from the researcher, and the consent finding from the consent manager. Hands the signed list to the sequence operator, and takes back from the meeting scheduler what each reply turned into.

The plugin

What is in the package

5 skills and the systems they need, written to version 1.1.0 of the Agent Plugins standard. Nothing in these files names a product. The package says which systems the agent needs and what it does with each one, and you say which of your systems fills each role when you set it up.

Download the package View on GitHub

prospect-researcher · 10 files · 1.0.0

com.agentcatalog.agent/NOT.mdWhat the agent does not do, and when it asks a person.

# Where this abstract agent stops

Does not contact anybody on the list. The touches belong to the sequence
operator, and a referred person is never dropped into an outbound
sequence. Does not rule on consent or suppression, which the consent
manager decides channel by channel. Does not write the account plan, and
does not hold the meeting or qualify the account itself.

## What always goes to a person

- an account another seller already owns, or that another list is
  already working - to whoever agrees the move, and it goes back on the
  list only after that agreement is recorded
- an account that may not be approached at all, whether for a dispute,
  an open support crisis or collections - to the seller, as an account
  to reach some other way
- signing the list - to the sales manager, always, at a version, before
  any of it is worked, and again if it changes after signing
- a seller who drops most of the list - back to the fit rules with the
  reasons attached, because that is a rules problem and not a pull
  problem

com.agentcatalog.agent/RECORDS.mdThe records the agent must leave behind.

# The records this abstract agent must leave

This is the contract. An agent implementing `prospect-researcher` leaves
the following behind, on every run.

The fit rules as written, at a version, plain enough for another person
to apply without asking. Per person: the account and the role, the
source they came from, the date they were pulled, the verification
result kept apart from the details that failed, and the consent finding
channel by channel with the count the record took out. Per list: the
rank with the inputs and the model version behind it, a reason against
every account the seller dropped or added, the signature with the signer
and the date, the loaded list as it reached the CRM and the sending
system, and the rebuild date with the triggers that force a rebuild
earlier.

An agent that leaves less than this does not implement
`prospect-researcher`, whatever else it does well.

com.agentcatalog.agent/SERVERS.mdThe systems the agent needs, by role rather than by product.

# The systems this abstract agent needs

Five systems, named by role rather than by product. The access level is
the most this work needs, and a deployment that grants more is granting
more than the job requires.

| Role | Access | What the access is for |
|---|---|---|
| the account data sources | read | The candidate accounts, each one naming where it came from. |
| the contact data sources | read | Inside the run's daily cap. |
| the verification source | read | Every address and number is checked before it is used. |
| the CRM | write | The list, and where every person on it sits. |
| the sending system | write | The signed list lands where the sequences read it, with its consent finding attached. |

Whoever builds an agent from this plugin writes the `mcp.json` that
points these roles at their own systems. Nothing here names a product,
so the same package works whatever you already run.

plugin.jsonThe manifest. It lists the skills and the systems the agent needs.

{
  "$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
  "name": "prospect-researcher",
  "version": "1.0.0",
  "description": "The prospect-researcher abstract agent. Builds and checks the list of people worth approaching, from a territory or an approved account plan, and says why each one is on it.",
  "author": {
    "name": "AgentCatalog",
    "url": "https://agentcatalog.com"
  },
  "homepage": "https://agentcatalog.com/abstract-agents/prospect-researcher",
  "repository": "https://github.com/jeffrschneider/agentcatalog",
  "license": "CC-BY-4.0",
  "keywords": [
    "abstract-agent",
    "reference",
    "sales",
    "build-a-prospect-list",
    "work-a-referral",
    "book-the-meeting",
    "abstract"
  ],
  "extensions": {
    "com.agentcatalog.agent": {
      "agent": "prospect-researcher",
      "agentVersion": 1,
      "department": "sales",
      "abstract": true,
      "works": "Convenes decide-and-announce to settle the fit rules, runs collect-and-report for the pull and for finding the people, and assessment for verification. Sits in the briefing where the seller keeps, drops or adds accounts, delivers into the approval where the sales manager signs the list, and closes with a debrief on which rules found real prospects. Takes ownership and what is already open from the account monitor, the reading of each account from the researcher, and the consent finding from the consent manager. Hands the signed list to the sequence operator, and takes back from the meeting scheduler what each reply turned into.",
      "servers": [
        {
          "name": "the account data sources",
          "role": "account-data-sources",
          "access": "read",
          "needs": "The candidate accounts, each one naming where it came from."
        },
        {
          "name": "the contact data sources",
          "role": "contact-data-sources",
          "access": "read",
          "needs": "Inside the run's daily cap."
        },
        {
          "name": "the verification source",
          "role": "verification-source",
          "access": "read",
          "needs": "Every address and number is checked before it is used."
        },
        {
          "name": "the CRM",
          "role": "crm",
          "access": "write",
          "needs": "The list, and where every person on it sits."
        },
        {
          "name": "the sending system",
          "role": "sending-system",
          "access": "write",
          "needs": "The signed list lands where the sequences read it, with its consent finding attached."
        }
      ],
      "records": [
        "The fit rules as written, at a version, plain enough for another person to apply without asking.",
        "Per person: the account and the role, the source they came from, the date they were pulled, the verification result kept apart from the details that failed, and the consent finding channel by channel with the count the record took out.",
        "Per list: the rank with the inputs and the model version behind it, a reason against every account the seller dropped or added, the signature with the signer and the date, the loaded list as it reached the CRM and the sending system, and the rebuild date with the triggers that force a rebuild earlier."
      ],
      "escalates": [
        "an account another seller already owns, or that another list is already working - to whoever agrees the move, and it goes back on the list only after that agreement is recorded",
        "an account that may not be approached at all, whether for a dispute, an open support crisis or collections - to the seller, as an account to reach some other way",
        "signing the list - to the sales manager, always, at a version, before any of it is worked, and again if it changes after signing",
        "a seller who drops most of the list - back to the fit rules with the reasons attached, because that is a rules problem and not a pull problem"
      ],
      "not": [
        "Does not contact anybody on the list.",
        "The touches belong to the sequence operator, and a referred person is never dropped into an outbound sequence.",
        "Does not rule on consent or suppression, which the consent manager decides channel by channel.",
        "Does not write the account plan, and does not hold the meeting or qualify the account itself."
      ],
      "processes": [
        {
          "process": "ref/sls/build-a-prospect-list",
          "activities": [
            "Take in the Territory or Plan",
            "Set the Fit Rules",
            "Pull the Candidate Accounts",
            "Find the People",
            "Verify the Contact Details",
            "Score and Rank",
            "Review with the Seller",
            "Load the List",
            "Set the Refresh",
            "Record What Was Learned"
          ]
        },
        {
          "process": "ref/sls/work-a-referral",
          "activities": [
            "Take in the Referral",
            "Read the Person and the Account",
            "Agree What Is Being Asked",
            "Record the Referral"
          ]
        },
        {
          "process": "ref/sls/book-the-meeting",
          "activities": [
            "Decide If It Goes Forward",
            "Record What Was Learned"
          ]
        }
      ]
    }
  }
}

README.mdWhat the package is, and why it carries no mcp.json.

# prospect-researcher

This is an abstract agent, published as an Agent Plugin. An abstract
agent is a job description rather than an implementation. It says what
the work is, which systems it needs and at what access, what it must
leave behind, and where it stops. Any agent that leaves the records can
implement it.

The plugin carries five skills, no `mcp.json`, and everything the
abstract agent owes under `com.agentcatalog.agent/`.

## Why there is no mcp.json

A conformant server entry in `mcp.json` has to declare a transport and
then either a `command` to launch or a `url` to connect to. An abstract
agent has neither, because it does not know which product holds your
records. Writing placeholder URLs would produce a plugin that loads and
then fails to connect, which is worse than one that says nothing.

Section 6.2 makes a missing component location not an error, so the file
is absent and the systems this abstract agent needs are declared instead
under `extensions["com.agentcatalog.agent"].servers`, as a role, an
access level and what the access is for. Whoever builds an agent from
this plugin writes the `mcp.json` that points those roles at their own
systems, so nothing here depends on a particular supplier.

## Why the obligations are in an extension

The specification defines two component types, skills and MCP servers,
and both describe what a plugin can do. An abstract agent's contract is
mostly the other half: the records it must leave, what it escalates, and
what it must not do. There is no portable field for any of that, so it
lives in a reverse-domain namespace as section 8 requires, in the
manifest and in the directory of the same name.

## Where this abstract agent is used

`ref/sls/build-a-prospect-list`, `ref/sls/work-a-referral`,
`ref/sls/book-the-meeting`. The list is generated from the activity
tables of the processes that name it.

https://agentcatalog.com/abstract-agents/prospect-researcher

skills/pull-and-verify-the-people/SKILL.mdPulls the accounts that meet the rules, finds the roles worth approaching at each one, and checks every address and number against a source before it is used. Use it when running `ref/sls/build-a-prospect-list`.

---
name: pull-and-verify-the-people
description: Pulls the accounts that meet the rules, finds the roles worth approaching at each one, and checks every address and number against a source before it is used. Use it when running `ref/sls/build-a-prospect-list`.
license: CC-BY-4.0
metadata:
  agent: prospect-researcher
  agent-version: "1"
---

# Pull and verify the people

## What it does

Pulls the accounts that meet the rules, finds the roles worth
approaching at each one, and checks every address and number against a
source before it is used. Each person carries where they came from and
the date they were pulled.

## Where it happens

The agent does this in three activities across one reference process.
Each one names the activity as that process words it.

- **Find the People**
  - `ref/sls/build-a-prospect-list`, activity 6 -
    [Build a Prospect List](../../../../processes/sales/build-a-prospect-list.md)
- **Pull the Candidate Accounts**
  - `ref/sls/build-a-prospect-list`, activity 3 -
    [Build a Prospect List](../../../../processes/sales/build-a-prospect-list.md)
- **Verify the Contact Details**
  - `ref/sls/build-a-prospect-list`, activity 7 -
    [Build a Prospect List](../../../../processes/sales/build-a-prospect-list.md)

## What to record

The fit rules as written, at a version, plain enough for another person
to apply without asking. Per person: the account and the role, the
source they came from, the date they were pulled, the verification
result kept apart from the details that failed, and the consent finding
channel by channel with the count the record took out. Per list: the
rank with the inputs and the model version behind it, a reason against
every account the seller dropped or added, the signature with the signer
and the date, the loaded list as it reached the CRM and the sending
system, and the rebuild date with the triggers that force a rebuild
earlier.

That contract covers every activity this abstract agent takes on, and it
is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract
agent does not do is in `com.agentcatalog.agent/NOT.md`.

skills/rank-and-hand-over-the-list/SKILL.mdRanks the list so the seller knows what to work first, takes the seller's keeps, drops and adds with a reason against each, and loads the signed list where the sequences read it. Use it when running `ref/sls/build-a-prospect-list`.

---
name: rank-and-hand-over-the-list
description: Ranks the list so the seller knows what to work first, takes the seller's keeps, drops and adds with a reason against each, and loads the signed list where the sequences read it. Use it when running `ref/sls/build-a-prospect-list`.
license: CC-BY-4.0
metadata:
  agent: prospect-researcher
  agent-version: "1"
---

# Rank and hand over the list

## What it does

Ranks the list so the seller knows what to work first, takes the
seller's keeps, drops and adds with a reason against each, and loads the
signed list where the sequences read it. Sets the date the list is built
again and the triggers that force it earlier.

## Where it happens

The agent does this in four activities across one reference process.
Each one names the activity as that process words it.

- **Load the List**
  - `ref/sls/build-a-prospect-list`, activity 12 -
    [Build a Prospect List](../../../../processes/sales/build-a-prospect-list.md)
- **Review with the Seller**
  - `ref/sls/build-a-prospect-list`, activity 10 -
    [Build a Prospect List](../../../../processes/sales/build-a-prospect-list.md)
- **Score and Rank**
  - `ref/sls/build-a-prospect-list`, activity 9 -
    [Build a Prospect List](../../../../processes/sales/build-a-prospect-list.md)
- **Set the Refresh**
  - `ref/sls/build-a-prospect-list`, activity 13 -
    [Build a Prospect List](../../../../processes/sales/build-a-prospect-list.md)

## What to record

The fit rules as written, at a version, plain enough for another person
to apply without asking. Per person: the account and the role, the
source they came from, the date they were pulled, the verification
result kept apart from the details that failed, and the consent finding
channel by channel with the count the record took out. Per list: the
rank with the inputs and the model version behind it, a reason against
every account the seller dropped or added, the signature with the signer
and the date, the loaded list as it reached the CRM and the sending
system, and the rebuild date with the triggers that force a rebuild
earlier.

That contract covers every activity this abstract agent takes on, and it
is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract
agent does not do is in `com.agentcatalog.agent/NOT.md`.

skills/read-what-the-list-produced/SKILL.md"Reads what the work produced: whether an account goes forward after the first conversation, and which fit rules found real prospects and which found noise. Use it when running `ref/sls/book-the-meeting` and `ref/sls/build-a-prospect-list`."

---
name: read-what-the-list-produced
description: "Reads what the work produced: whether an account goes forward after the first conversation, and which fit rules found real prospects and which found noise. Use it when running `ref/sls/book-the-meeting` and `ref/sls/build-a-prospect-list`."
license: CC-BY-4.0
metadata:
  agent: prospect-researcher
  agent-version: "1"
---

# Read what the list produced

## What it does

Reads what the work produced: whether an account goes forward after the
first conversation, and which fit rules found real prospects and which
found noise.

## Where it happens

The agent does this in two activities across two reference processes.
Each one names the activity as that process words it.

- **Decide If It Goes Forward**
  - `ref/sls/book-the-meeting`, activity 12 -
    [Book the Meeting](../../../../processes/sales/book-the-meeting.md)
- **Record What Was Learned**
  - `ref/sls/book-the-meeting`, activity 16 -
    [Book the Meeting](../../../../processes/sales/book-the-meeting.md)
  - `ref/sls/build-a-prospect-list`, activity 14 -
    [Build a Prospect List](../../../../processes/sales/build-a-prospect-list.md)

## What to record

The fit rules as written, at a version, plain enough for another person
to apply without asking. Per person: the account and the role, the
source they came from, the date they were pulled, the verification
result kept apart from the details that failed, and the consent finding
channel by channel with the count the record took out. Per list: the
rank with the inputs and the model version behind it, a reason against
every account the seller dropped or added, the signature with the signer
and the date, the loaded list as it reached the CRM and the sending
system, and the rebuild date with the triggers that force a rebuild
earlier.

That contract covers every activity this abstract agent takes on, and it
is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract
agent does not do is in `com.agentcatalog.agent/NOT.md`.

skills/set-the-rules-a-list-is-built-to/SKILL.mdTakes in the territory or the approved plan a list is built from, and writes the fit rules down before anything is pulled. Use it when running `ref/sls/build-a-prospect-list`.

---
name: set-the-rules-a-list-is-built-to
description: Takes in the territory or the approved plan a list is built from, and writes the fit rules down before anything is pulled. Use it when running `ref/sls/build-a-prospect-list`.
license: CC-BY-4.0
metadata:
  agent: prospect-researcher
  agent-version: "1"
---

# Set the rules a list is built to

## What it does

Takes in the territory or the approved plan a list is built from, and
writes the fit rules down before anything is pulled. The rules are
written plain enough for another person to apply them without asking.

## Where it happens

The agent does this in two activities across one reference process. Each
one names the activity as that process words it.

- **Set the Fit Rules**
  - `ref/sls/build-a-prospect-list`, activity 2 -
    [Build a Prospect List](../../../../processes/sales/build-a-prospect-list.md)
- **Take in the Territory or Plan**
  - `ref/sls/build-a-prospect-list`, activity 1 -
    [Build a Prospect List](../../../../processes/sales/build-a-prospect-list.md)

## What to record

The fit rules as written, at a version, plain enough for another person
to apply without asking. Per person: the account and the role, the
source they came from, the date they were pulled, the verification
result kept apart from the details that failed, and the consent finding
channel by channel with the count the record took out. Per list: the
rank with the inputs and the model version behind it, a reason against
every account the seller dropped or added, the signature with the signer
and the date, the loaded list as it reached the CRM and the sending
system, and the rebuild date with the triggers that force a rebuild
earlier.

That contract covers every activity this abstract agent takes on, and it
is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract
agent does not do is in `com.agentcatalog.agent/NOT.md`.

skills/work-a-referral-into-the-list/SKILL.mdTakes in an introduction somebody offers, reads the person and the account before anybody writes to them, and agrees with the seller what the introduction should ask for. Use it when running `ref/sls/work-a-referral`.

---
name: work-a-referral-into-the-list
description: Takes in an introduction somebody offers, reads the person and the account before anybody writes to them, and agrees with the seller what the introduction should ask for. Use it when running `ref/sls/work-a-referral`.
license: CC-BY-4.0
metadata:
  agent: prospect-researcher
  agent-version: "1"
---

# Work a referral into the list

## What it does

Takes in an introduction somebody offers, reads the person and the
account before anybody writes to them, and agrees with the seller what
the introduction should ask for. Records who introduces well and what
came of it.

## Where it happens

The agent does this in four activities across one reference process.
Each one names the activity as that process words it.

- **Agree What Is Being Asked**
  - `ref/sls/work-a-referral`, activity 5 -
    [Work a Referral](../../../../processes/sales/work-a-referral.md)
- **Read the Person and the Account**
  - `ref/sls/work-a-referral`, activity 4 -
    [Work a Referral](../../../../processes/sales/work-a-referral.md)
- **Record the Referral**
  - `ref/sls/work-a-referral`, activity 14 -
    [Work a Referral](../../../../processes/sales/work-a-referral.md)
- **Take in the Referral**
  - `ref/sls/work-a-referral`, activity 1 -
    [Work a Referral](../../../../processes/sales/work-a-referral.md)

## What to record

The fit rules as written, at a version, plain enough for another person
to apply without asking. Per person: the account and the role, the
source they came from, the date they were pulled, the verification
result kept apart from the details that failed, and the consent finding
channel by channel with the count the record took out. Per list: the
rank with the inputs and the model version behind it, a reason against
every account the seller dropped or added, the signature with the signer
and the date, the loaded list as it reached the CRM and the sending
system, and the rebuild date with the triggers that force a rebuild
earlier.

That contract covers every activity this abstract agent takes on, and it
is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract
agent does not do is in `com.agentcatalog.agent/NOT.md`.

mcp.jsonNot in the package.

Every server entry in an mcp.json needs either a command to run or a url to connect to, and the package cannot know either of those until somebody points it at their own systems. So the file is left out, the systems the agent needs are named by role in plugin.json, and you write the mcp.json when you set it up.

Setting it up

Point it at your systems

To run an agent built from this package, write an mcp.json that says which of your systems fills each role. The package names these 5 roles, and the access level beside each one is the most the work needs.

account-data-sources · readcontact-data-sources · readverification-source · readcrm · writesending-system · write

mcp.json You write this file. It is not part of the package.

{
  "$schema": "https://agent-plugins.org/schemas/1.1.0/mcp.schema.json",
  "mcpServers": {
    "account-data-sources": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/account-data-sources"
    },
    "contact-data-sources": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/contact-data-sources"
    },
    "verification-source": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/verification-source"
    },
    "crm": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/crm"
    },
    "sending-system": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/sending-system"
    }
  }
}

The hostnames here are a placeholder for your own. Whichever product holds each of these systems, the agent you build is yours and nobody else has to be involved in running it.

Where it works

3 processes, 16 activities

The highlighted activities are the ones this abstract agent does. The other activities in each process belong to other abstract agents or to people.

Book the Meetingref/sls/book-the-meeting · 16 activities

Decide If It Goes Forward · Record What Was Learned

Build a Prospect Listref/sls/build-a-prospect-list · 14 activities

Take in the Territory or Plan · Set the Fit Rules · Pull the Candidate Accounts · Find the People · Verify the Contact Details · Score and Rank · Review with the Seller · Load the List · Set the Refresh · Record What Was Learned

Work a Referralref/sls/work-a-referral · 14 activities

Take in the Referral · Read the Person and the Account · Agree What Is Being Asked · Record the Referral

The records it leaves

What it writes down

The fit rules as written, at a version, plain enough for another person to apply without asking. Per person: the account and the role, the source they came from, the date they were pulled, the verification result kept apart from the details that failed, and the consent finding channel by channel with the count the record took out. Per list: the rank with the inputs and the model version behind it, a reason against every account the seller dropped or added, the signature with the signer and the date, the loaded list as it reached the CRM and the sending system, and the rebuild date with the triggers that force a rebuild earlier.

Where it stops

What it will not do

Does not contact anybody on the list. The touches belong to the sequence operator, and a referred person is never dropped into an outbound sequence. Does not rule on consent or suppression, which the consent manager decides channel by channel. Does not write the account plan, and does not hold the meeting or qualify the account itself.

These limits are written into the job on purpose, so that everyone adopting the process knows which decisions stay with a person.

Agents built from this plugin

Who has built one, and how far each one got

Nobody has built one yet. The catalog says so rather than leaving the section off, because an empty list is a fact about the document.

declare it implements: prospect-researcher v1 One line in your agent's manifest. The catalog checks it against the records your runs actually leave.

A guess, not a claim

The closest things in the catalog, by description

Nobody above has claimed any of these. This is the nearest match by wording between the job written above and what publishers wrote about their own listings, closest first, and wording is not evidence: some of these will be wrong, and a job with nothing suitable still gets whatever was nearest. The publishers have never heard of this abstract agent and have promised nothing about it. What a claim looks like is in the table above, and it is signed.

Might be reached for

Not workers. These are capability that whatever does the job would use, which is a different relationship and kept in its own column for that reason.

Red String MCP server · redstringapp.xyz · hosted · mirrored from the MCP registry Revenue research and pipeline tools for agencies: scouting, contact intel, ABM, cadences, briefs.
RepScale MCP server · kbrayatl.github.io · hosted · mirrored from the MCP registry Sales research and prep tools for B2B reps. Prospect briefs, angles, citations.
Kairon MCP server · heykairon.com · hosted · mirrored from the MCP registry Build prospecting lists from buying signals, enrich them, and run LinkedIn outreach.