Partner onboarding manager
partner-onboarding-manager v1Takes a signed agreement and gets the partner to the point where they can sell or deliver without an escort. Names a person at each end rather than a shared mailbox, agrees which access lands in what order and by when, and collects the details no system will open an account without. Publishes the materials set at a version, holds the kick-off so the partner hears the plan and the people once, and sets up the path a registered deal travels. The run is not complete until the partner says in writing that the access works and names each person who got in, and what stalled on the way is recorded so the next onboarding is shorter.
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 the briefing that agrees the onboarding plan and the briefing that is the kick-off, and the debrief that closes the run. Runs collect-and-report over the signed agreement and build-by-talent for the materials set. Answers roll-calls with where each step of the onboarding stands. Hands the access work to the portal-keeper agent, takes the end-to-end test result from the partner-monitor agent, works beside the partner-manager agent on deal registration and the standing cadence, hands the named people to the curriculum-manager agent for certification, and hands the partner into their first walked deal.
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.
partner-onboarding-manager · 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 create logins, decide what the partner can see, or grant systems access, which is the portal-keeper agent. Does not build the curriculum, run the training or certify anybody, which are the curriculum-manager and certification-check agents. Does not walk the first deal, and does not hold the relationship after the run closes, which is the partner-manager agent. Does not change the agreement or the tier the partner sits in. ## What always goes to a person - a partner that cannot give a detail a system needs - to the partner lead, naming the access it blocks and what it holds up - access above the partner's tier - to whoever signs for that, with the reason recorded against the partner record - an onboarding past the dates in its plan - to the partner lead and the partner's sponsor, with the steps still open - a partner that will not confirm the access works - to the partner lead, because the onboarding is not complete without the confirmation
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 `partner-onboarding-manager`
leaves the following behind, on every run.
The onboarding plan with each access, the order it lands in and the date
it is due. The named person at each end and how to reach them. The
details the partner provided and the date each one arrived. The
materials set at the version published and the date it went. The
kick-off record naming who attended on both sides. The partner's written
confirmation, naming each person who got in. A dated line for every step
that stalled, saying what it was waiting on and for how long, which is
what the next onboarding reads first.
An agent that leaves less than this does not implement
`partner-onboarding-manager`, 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 document store | read | The signed agreement says what the partner may sell, deliver and earn. |
| the partner record | write | The named people, the plan and the dates land here. |
| the partner portal | write | The materials set is published at a version and republished rather than edited in place. |
| the CRM | write | Deal registration is set up against what the agreement allows. |
| the calendar | write | The kick-off and the plan dates are booked on both sides. |
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": "partner-onboarding-manager",
"version": "1.0.0",
"description": "The partner-onboarding-manager abstract agent. Takes a signed agreement and gets the partner to the point where they can sell or deliver without an escort. Names a person at each end rather than a shared mailbox, agrees which access lands in what order and by when, and collects the details no system will open an account without.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/partner-onboarding-manager",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"partners",
"onboard-a-partner",
"certify-a-partner",
"run-a-first-deal-together",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "partner-onboarding-manager",
"agentVersion": 1,
"department": "partners",
"abstract": true,
"works": "Convenes the briefing that agrees the onboarding plan and the briefing that is the kick-off, and the debrief that closes the run. Runs collect-and-report over the signed agreement and build-by-talent for the materials set. Answers roll-calls with where each step of the onboarding stands. Hands the access work to the portal-keeper agent, takes the end-to-end test result from the partner-monitor agent, works beside the partner-manager agent on deal registration and the standing cadence, hands the named people to the curriculum-manager agent for certification, and hands the partner into their first walked deal.",
"servers": [
{
"name": "the document store",
"role": "document-store",
"access": "read",
"needs": "The signed agreement says what the partner may sell, deliver and earn."
},
{
"name": "the partner record",
"role": "partner-record",
"access": "write",
"needs": "The named people, the plan and the dates land here."
},
{
"name": "the partner portal",
"role": "partner-portal",
"access": "write",
"needs": "The materials set is published at a version and republished rather than edited in place."
},
{
"name": "the CRM",
"role": "crm",
"access": "write",
"needs": "Deal registration is set up against what the agreement allows."
},
{
"name": "the calendar",
"role": "calendar",
"access": "write",
"needs": "The kick-off and the plan dates are booked on both sides."
}
],
"records": [
"The onboarding plan with each access, the order it lands in and the date it is due.",
"The named person at each end and how to reach them.",
"The details the partner provided and the date each one arrived.",
"The materials set at the version published and the date it went.",
"The kick-off record naming who attended on both sides.",
"The partner's written confirmation, naming each person who got in.",
"A dated line for every step that stalled, saying what it was waiting on and for how long, which is what the next onboarding reads first."
],
"escalates": [
"a partner that cannot give a detail a system needs - to the partner lead, naming the access it blocks and what it holds up",
"access above the partner's tier - to whoever signs for that, with the reason recorded against the partner record",
"an onboarding past the dates in its plan - to the partner lead and the partner's sponsor, with the steps still open",
"a partner that will not confirm the access works - to the partner lead, because the onboarding is not complete without the confirmation"
],
"not": [
"Does not create logins, decide what the partner can see, or grant systems access, which is the portal-keeper agent.",
"Does not build the curriculum, run the training or certify anybody, which are the curriculum-manager and certification-check agents.",
"Does not walk the first deal, and does not hold the relationship after the run closes, which is the partner-manager agent.",
"Does not change the agreement or the tier the partner sits in."
],
"processes": [
{
"process": "ref/prt/certify-a-partner",
"activities": [
"Take in the Named People"
]
},
{
"process": "ref/prt/onboard-a-partner",
"activities": [
"Take in the Signed Agreement",
"Name the People on Both Sides",
"Agree the Onboarding Plan",
"Collect What the Partner Must Provide",
"Check the Partner Record Is Complete",
"Publish the Materials Set",
"Hold the Kick-Off",
"Set up How Deals Get Registered",
"Confirm the Partner Can Reach Everything",
"Record What the Onboarding Cost"
]
},
{
"process": "ref/prt/run-a-first-deal-together",
"activities": [
"Take in the First Opportunity"
]
}
]
}
}
}
README.mdWhat the package is, and why it carries no mcp.json.
# partner-onboarding-manager 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/prt/certify-a-partner`, `ref/prt/onboard-a-partner`, `ref/prt/run-a-first-deal-together`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/partner-onboarding-manager
skills/agree-the-plan-and-collect-what-it-needs/SKILL.mdAgrees which access lands in what order and by when, collects the details no system will open an account without, and checks the partner record holds all of them before the access work starts. Use it when running `ref/prt/onboard-a-partner`.
--- name: agree-the-plan-and-collect-what-it-needs description: Agrees which access lands in what order and by when, collects the details no system will open an account without, and checks the partner record holds all of them before the access work starts. Use it when running `ref/prt/onboard-a-partner`. license: CC-BY-4.0 metadata: agent: partner-onboarding-manager agent-version: "1" --- # Agree the plan and collect what it needs ## What it does Agrees which access lands in what order and by when, collects the details no system will open an account without, and checks the partner record holds all of them before the access work starts. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Agree the Onboarding Plan** - `ref/prt/onboard-a-partner`, activity 3 - [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md) - **Check the Partner Record Is Complete** - `ref/prt/onboard-a-partner`, activity 5 - [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md) - **Collect What the Partner Must Provide** - `ref/prt/onboard-a-partner`, activity 4 - [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md) ## What to record The onboarding plan with each access, the order it lands in and the date it is due. The named person at each end and how to reach them. The details the partner provided and the date each one arrived. The materials set at the version published and the date it went. The kick-off record naming who attended on both sides. The partner's written confirmation, naming each person who got in. A dated line for every step that stalled, saying what it was waiting on and for how long, which is what the next onboarding reads first. 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/close-the-onboarding/SKILL.mdGets the partner's word in writing that the access works, naming each person who got in, and records what the run cost and every step that stalled on the way. Use it when running `ref/prt/onboard-a-partner`.
--- name: close-the-onboarding description: Gets the partner's word in writing that the access works, naming each person who got in, and records what the run cost and every step that stalled on the way. Use it when running `ref/prt/onboard-a-partner`. license: CC-BY-4.0 metadata: agent: partner-onboarding-manager agent-version: "1" --- # Close the onboarding ## What it does Gets the partner's word in writing that the access works, naming each person who got in, and records what the run cost and every step that stalled on the way. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Confirm the Partner Can Reach Everything** - `ref/prt/onboard-a-partner`, activity 14 - [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md) - **Record What the Onboarding Cost** - `ref/prt/onboard-a-partner`, activity 16 - [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md) ## What to record The onboarding plan with each access, the order it lands in and the date it is due. The named person at each end and how to reach them. The details the partner provided and the date each one arrived. The materials set at the version published and the date it went. The kick-off record naming who attended on both sides. The partner's written confirmation, naming each person who got in. A dated line for every step that stalled, saying what it was waiting on and for how long, which is what the next onboarding reads first. 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/open-an-onboarding-from-a-signed-agreement/SKILL.mdReads the signed agreement for what the partner may sell, deliver and earn, and names a person at each end rather than a shared mailbox, including the people the partner puts forward to be trained. Use it when running `ref/prt/certify-a-partner` and `ref/prt/onboard-a-partner`.
--- name: open-an-onboarding-from-a-signed-agreement description: Reads the signed agreement for what the partner may sell, deliver and earn, and names a person at each end rather than a shared mailbox, including the people the partner puts forward to be trained. Use it when running `ref/prt/certify-a-partner` and `ref/prt/onboard-a-partner`. license: CC-BY-4.0 metadata: agent: partner-onboarding-manager agent-version: "1" --- # Open an onboarding from a signed agreement ## What it does Reads the signed agreement for what the partner may sell, deliver and earn, and names a person at each end rather than a shared mailbox, including the people the partner puts forward to be trained. ## Where it happens The agent does this in three activities across two reference processes. Each one names the activity as that process words it. - **Name the People on Both Sides** - `ref/prt/onboard-a-partner`, activity 2 - [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md) - **Take in the Named People** - `ref/prt/certify-a-partner`, activity 1 - [Certify a Partner](../../../../processes/partners/certify-a-partner.md) - **Take in the Signed Agreement** - `ref/prt/onboard-a-partner`, activity 1 - [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md) ## What to record The onboarding plan with each access, the order it lands in and the date it is due. The named person at each end and how to reach them. The details the partner provided and the date each one arrived. The materials set at the version published and the date it went. The kick-off record naming who attended on both sides. The partner's written confirmation, naming each person who got in. A dated line for every step that stalled, saying what it was waiting on and for how long, which is what the next onboarding reads first. 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/publish-the-materials-and-hold-the-kick-off/SKILL.mdPublishes the materials set at a version and holds the kick-off, so the partner hears the plan, the people and the dates once rather than passed along. Use it when running `ref/prt/onboard-a-partner`.
--- name: publish-the-materials-and-hold-the-kick-off description: Publishes the materials set at a version and holds the kick-off, so the partner hears the plan, the people and the dates once rather than passed along. Use it when running `ref/prt/onboard-a-partner`. license: CC-BY-4.0 metadata: agent: partner-onboarding-manager agent-version: "1" --- # Publish the materials and hold the kick off ## What it does Publishes the materials set at a version and holds the kick-off, so the partner hears the plan, the people and the dates once rather than passed along. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Hold the Kick-Off** - `ref/prt/onboard-a-partner`, activity 10 - [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md) - **Publish the Materials Set** - `ref/prt/onboard-a-partner`, activity 9 - [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md) ## What to record The onboarding plan with each access, the order it lands in and the date it is due. The named person at each end and how to reach them. The details the partner provided and the date each one arrived. The materials set at the version published and the date it went. The kick-off record naming who attended on both sides. The partner's written confirmation, naming each person who got in. A dated line for every step that stalled, saying what it was waiting on and for how long, which is what the next onboarding reads first. 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-up-the-path-a-deal-travels/SKILL.mdSets up how a deal gets registered against what the agreement allows, and takes in the first opportunity the partner brings so it can be walked along that path. Use it when running `ref/prt/onboard-a-partner` and `ref/prt/run-a-first-deal-together`.
--- name: set-up-the-path-a-deal-travels description: Sets up how a deal gets registered against what the agreement allows, and takes in the first opportunity the partner brings so it can be walked along that path. Use it when running `ref/prt/onboard-a-partner` and `ref/prt/run-a-first-deal-together`. license: CC-BY-4.0 metadata: agent: partner-onboarding-manager agent-version: "1" --- # Set up the path a deal travels ## What it does Sets up how a deal gets registered against what the agreement allows, and takes in the first opportunity the partner brings so it can be walked along that path. ## Where it happens The agent does this in two activities across two reference processes. Each one names the activity as that process words it. - **Set up How Deals Get Registered** - `ref/prt/onboard-a-partner`, activity 12 - [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md) - **Take in the First Opportunity** - `ref/prt/run-a-first-deal-together`, activity 1 - [Run a First Deal Together](../../../../processes/partners/run-a-first-deal-together.md) ## What to record The onboarding plan with each access, the order it lands in and the date it is due. The named person at each end and how to reach them. The details the partner provided and the date each one arrived. The materials set at the version published and the date it went. The kick-off record naming who attended on both sides. The partner's written confirmation, naming each person who got in. A dated line for every step that stalled, saying what it was waiting on and for how long, which is what the next onboarding reads first. 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.
document-store · readpartner-record · writepartner-portal · writecrm · writecalendar · 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": {
"document-store": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/document-store"
},
"partner-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-record"
},
"partner-portal": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-portal"
},
"crm": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/crm"
},
"calendar": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/calendar"
}
}
}
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, 12 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.
Certify a Partnerref/prt/certify-a-partner · 16 activities
Take in the Named People
Onboard a Partnerref/prt/onboard-a-partner · 16 activities
Take in the Signed Agreement · Name the People on Both Sides · Agree the Onboarding Plan · Collect What the Partner Must Provide · Check the Partner Record Is Complete · Publish the Materials Set · Hold the Kick-Off · Set up How Deals Get Registered · Confirm the Partner Can Reach Everything · Record What the Onboarding Cost
Run a First Deal Togetherref/prt/run-a-first-deal-together · 16 activities
Take in the First Opportunity
The records it leaves
What it writes down
The onboarding plan with each access, the order it lands in and the date it is due. The named person at each end and how to reach them. The details the partner provided and the date each one arrived. The materials set at the version published and the date it went. The kick-off record naming who attended on both sides. The partner's written confirmation, naming each person who got in. A dated line for every step that stalled, saying what it was waiting on and for how long, which is what the next onboarding reads first.
Where it stops
What it will not do
Does not create logins, decide what the partner can see, or grant systems access, which is the portal-keeper agent. Does not build the curriculum, run the training or certify anybody, which are the curriculum-manager and certification-check agents. Does not walk the first deal, and does not hold the relationship after the run closes, which is the partner-manager agent. Does not change the agreement or the tier the partner sits in.
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: partner-onboarding-manager 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.
- Onboard MCP server · viaonboard.github.io · hosted · mirrored from the MCP registry Your AI copilot for customer onboarding — projects, KPIs, tasks, and safe writes.
- SoundGTM MCP server · soundgtm.com · hosted · mirrored from the MCP registry AI-native PRM: track partner pipeline, deals, and commissions, and manage partner outreach.
- Site Rep MCP MCP server · nish3451.github.io · hosted · mirrored from the MCP registry Read-only Site Rep handoff: agent brief, pending work, first-customer receipt with payment evidence.