Onboarding manager
onboarding-manager v1Carries somebody who has just joined a revenue team from a confirmed start date to a real customer conversation they can hold unaided. Takes in who is joining and into which job, orders the access before the first day and makes the joiner test it rather than trusting the ticket, takes in the territory and the ramped number from wherever they were set, and holds the plan of what is learned in which week. It runs the calendar and the checklist around the teaching rather than doing the teaching, and it knows the joiner is ready only when a signed pass says so. The run stays open until the first conversation has been debriefed and the ramp has been reported.
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 where the manager states the job and the ramp, and the briefing where the joiner meets the people they will have to ask things of. Runs assessment on the access list, because a system is open only when the joiner has signed into it. Runs roll-call as the standing check-in and collect-and-report on access that has not landed and on the ramp at the end. Takes the debrief on the first customer conversation from the manager who listened to it. Hands the learning plan to the curriculum-manager agent and the readiness gate to the certification-check agent, and takes the pass back from it before any customer is booked. Takes the territory and the ramped number from whoever set them, and hands the signed material from a roll-out into the same library a new joiner is taught from.
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.
# Where this abstract agent stops Does not teach. The product, the market, the process and the pitch belong to the curriculum-manager agent and the people it books, and this agent holds the calendar and the checklist around them. Does not decide whether the joiner is ready, which is the certification-check agent's run and a human signature. Does not set the territory or the ramped number, does not grant its own access, and does not sit in the first customer conversation or take it over. ## What always goes to a person - a system that never opened, to IT operations, with the request date and the ticket attached, and the run held rather than closed around it - no territory assigned, back to the job and the manager, because a joiner taught against a patch they do not have learns the wrong accounts - a session nobody covered, to the sales leader, with the record of what was missed, before the readiness gate is convened - a joiner about to meet a customer without a signed pass, to the sales manager, and the conversation is not booked - a joiner who leaves during the ramp, to the manager and to sales operations, with access withdrawn the same day, the territory returned unassigned, and every account already contacted listed with what was said to it
# The records this abstract agent must leave
This is the contract. An agent implementing `onboarding-manager` leaves
the following behind, on every run.
Per joiner: the start as taken in, with the job, the manager and the
date. The job and the ramp in the manager's own words, from the briefing
that agreed them. Every access request with its system, the date it was
raised and the ticket it went under, and next to it the date the joiner
signed in successfully or the fact that they never did. The territory
and the ramped number at the version handed over. The learning plan at a
version, with the week each subject sits in, the person teaching it, and
a date against any change made after teaching started. Each session as
held or missed, and who covered a session the teacher missed. The calls
listened to, with dates. The sitting as scheduled, with what the joiner
was told they may bring. The first conversation as debriefed, naming
what the customer asked that the joiner could not answer and the date
each gap is fixed by. The ramp report at each checkpoint. An auditor can
read the run and see what was taught, what was open, and what the joiner
was never given.
An agent that leaves less than this does not implement
`onboarding-manager`, whatever else it does well.
# The systems this abstract agent needs
Eight 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 identity system | write | Accounts and licences ordered before day one, at the job's list rather than a copy of somebody else's. |
| the learning system | write | The plan at a version, and who has completed what. |
| the enablement library | write | One address holds the material a joiner is taught from, so the roll-out and the curriculum never differ. |
| the territory record | read | The patch and the ramped number, at the version the territory process signed. |
| the call recording system | read | The calls the joiner listens to, with the date of each one. |
| the calendar | write | Sessions, the sitting and the first customer conversation in diaries on both sides. |
| the CRM | read | The accounts the joiner has been given, so teaching is against the real patch. |
| analytics | read | Where the joiner stands against the ramp plan. |
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.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
"name": "onboarding-manager",
"version": "1.0.0",
"description": "The onboarding-manager abstract agent. Carries somebody who has just joined a revenue team from a confirmed start date to a real customer conversation they can hold unaided.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/onboarding-manager",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"revenue-operations",
"onboard-a-seller",
"certify-a-seller",
"roll-out-a-change",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "onboarding-manager",
"agentVersion": 1,
"department": "revenue-operations",
"abstract": true,
"works": "Convenes the briefing where the manager states the job and the ramp, and the briefing where the joiner meets the people they will have to ask things of. Runs assessment on the access list, because a system is open only when the joiner has signed into it. Runs roll-call as the standing check-in and collect-and-report on access that has not landed and on the ramp at the end. Takes the debrief on the first customer conversation from the manager who listened to it. Hands the learning plan to the curriculum-manager agent and the readiness gate to the certification-check agent, and takes the pass back from it before any customer is booked. Takes the territory and the ramped number from whoever set them, and hands the signed material from a roll-out into the same library a new joiner is taught from.",
"servers": [
{
"name": "the identity system",
"role": "identity-system",
"access": "write",
"needs": "Accounts and licences ordered before day one, at the job's list rather than a copy of somebody else's."
},
{
"name": "the learning system",
"role": "learning-system",
"access": "write",
"needs": "The plan at a version, and who has completed what."
},
{
"name": "the enablement library",
"role": "enablement-library",
"access": "write",
"needs": "One address holds the material a joiner is taught from, so the roll-out and the curriculum never differ."
},
{
"name": "the territory record",
"role": "territory-record",
"access": "read",
"needs": "The patch and the ramped number, at the version the territory process signed."
},
{
"name": "the call recording system",
"role": "call-recording-system",
"access": "read",
"needs": "The calls the joiner listens to, with the date of each one."
},
{
"name": "the calendar",
"role": "calendar",
"access": "write",
"needs": "Sessions, the sitting and the first customer conversation in diaries on both sides."
},
{
"name": "the CRM",
"role": "crm",
"access": "read",
"needs": "The accounts the joiner has been given, so teaching is against the real patch."
},
{
"name": "analytics",
"role": "analytics",
"access": "read",
"needs": "Where the joiner stands against the ramp plan."
}
],
"records": [
"Per joiner: the start as taken in, with the job, the manager and the date.",
"The job and the ramp in the manager's own words, from the briefing that agreed them.",
"Every access request with its system, the date it was raised and the ticket it went under, and next to it the date the joiner signed in successfully or the fact that they never did.",
"The territory and the ramped number at the version handed over.",
"The learning plan at a version, with the week each subject sits in, the person teaching it, and a date against any change made after teaching started.",
"Each session as held or missed, and who covered a session the teacher missed.",
"The calls listened to, with dates.",
"The sitting as scheduled, with what the joiner was told they may bring.",
"The first conversation as debriefed, naming what the customer asked that the joiner could not answer and the date each gap is fixed by.",
"The ramp report at each checkpoint.",
"An auditor can read the run and see what was taught, what was open, and what the joiner was never given."
],
"escalates": [
"a system that never opened, to IT operations, with the request date and the ticket attached, and the run held rather than closed around it",
"no territory assigned, back to the job and the manager, because a joiner taught against a patch they do not have learns the wrong accounts",
"a session nobody covered, to the sales leader, with the record of what was missed, before the readiness gate is convened",
"a joiner about to meet a customer without a signed pass, to the sales manager, and the conversation is not booked",
"a joiner who leaves during the ramp, to the manager and to sales operations, with access withdrawn the same day, the territory returned unassigned, and every account already contacted listed with what was said to it"
],
"not": [
"Does not teach.",
"The product, the market, the process and the pitch belong to the curriculum-manager agent and the people it books, and this agent holds the calendar and the checklist around them.",
"Does not decide whether the joiner is ready, which is the certification-check agent's run and a human signature.",
"Does not set the territory or the ramped number, does not grant its own access, and does not sit in the first customer conversation or take it over."
],
"processes": [
{
"process": "ref/rev/certify-a-seller",
"activities": [
"Schedule the Sitting"
]
},
{
"process": "ref/rev/onboard-a-seller",
"activities": [
"Take in the Start",
"Confirm the Job and the Manager",
"Order the Access",
"Take in the Territory and the Number",
"Check the Access Landed",
"Build the Learning Plan",
"Meet the People",
"Listen to Real Conversations",
"Debrief the First Conversation",
"Report the Ramp"
]
},
{
"process": "ref/rev/roll-out-a-change",
"activities": [
"Publish to One Address"
]
}
]
}
}
}
# 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/rev/certify-a-seller`, `ref/rev/onboard-a-seller`, `ref/rev/roll-out-a-change`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/onboarding-manager
--- name: close-the-ramp-out description: Keeps the run open until the first customer conversation has been debriefed, naming what the customer asked that the joiner could not answer and the date each gap is fixed by, and reports where the joiner stands against the ramp plan. Use it when running `ref/rev/onboard-a-seller`. license: CC-BY-4.0 metadata: agent: onboarding-manager agent-version: "1" --- # Close the ramp out ## What it does Keeps the run open until the first customer conversation has been debriefed, naming what the customer asked that the joiner could not answer and the date each gap is fixed by, and reports where the joiner stands against the ramp plan. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Debrief the First Conversation** - `ref/rev/onboard-a-seller`, activity 16 - [Onboard a Seller](../../../../processes/revenue-operations/onboard-a-seller.md) - **Report the Ramp** - `ref/rev/onboard-a-seller`, activity 17 - [Onboard a Seller](../../../../processes/revenue-operations/onboard-a-seller.md) ## What to record Per joiner: the start as taken in, with the job, the manager and the date. The job and the ramp in the manager's own words, from the briefing that agreed them. Every access request with its system, the date it was raised and the ticket it went under, and next to it the date the joiner signed in successfully or the fact that they never did. The territory and the ramped number at the version handed over. The learning plan at a version, with the week each subject sits in, the person teaching it, and a date against any change made after teaching started. Each session as held or missed, and who covered a session the teacher missed. The calls listened to, with dates. The sitting as scheduled, with what the joiner was told they may bring. The first conversation as debriefed, naming what the customer asked that the joiner could not answer and the date each gap is fixed by. The ramp report at each checkpoint. An auditor can read the run and see what was taught, what was open, and what the joiner was never given. 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`.
--- name: get-the-access-open-before-day-one description: Orders the accounts, licences and systems the job's own list calls for before the first day, then has the joiner sign into each one. Use it when running `ref/rev/onboard-a-seller`. license: CC-BY-4.0 metadata: agent: onboarding-manager agent-version: "1" --- # Get the access open before day one ## What it does Orders the accounts, licences and systems the job's own list calls for before the first day, then has the joiner sign into each one. A system is open when the joiner has used it, not when the ticket closed. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Check the Access Landed** - `ref/rev/onboard-a-seller`, activity 5 - [Onboard a Seller](../../../../processes/revenue-operations/onboard-a-seller.md) - **Order the Access** - `ref/rev/onboard-a-seller`, activity 3 - [Onboard a Seller](../../../../processes/revenue-operations/onboard-a-seller.md) ## What to record Per joiner: the start as taken in, with the job, the manager and the date. The job and the ramp in the manager's own words, from the briefing that agreed them. Every access request with its system, the date it was raised and the ticket it went under, and next to it the date the joiner signed in successfully or the fact that they never did. The territory and the ramped number at the version handed over. The learning plan at a version, with the week each subject sits in, the person teaching it, and a date against any change made after teaching started. Each session as held or missed, and who covered a session the teacher missed. The calls listened to, with dates. The sitting as scheduled, with what the joiner was told they may bring. The first conversation as debriefed, naming what the customer asked that the joiner could not answer and the date each gap is fixed by. The ramp report at each checkpoint. An auditor can read the run and see what was taught, what was open, and what the joiner was never given. 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`.
--- name: hold-one-address-for-the-material description: Puts the signed material from a roll-out into the same library a new joiner is taught from, so the roll-out and the curriculum never differ. Use it when running `ref/rev/roll-out-a-change`. license: CC-BY-4.0 metadata: agent: onboarding-manager agent-version: "1" --- # Hold one address for the material ## What it does Puts the signed material from a roll-out into the same library a new joiner is taught from, so the roll-out and the curriculum never differ. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Publish to One Address** - `ref/rev/roll-out-a-change`, activity 11 - [Roll Out a Change](../../../../processes/revenue-operations/roll-out-a-change.md) ## What to record Per joiner: the start as taken in, with the job, the manager and the date. The job and the ramp in the manager's own words, from the briefing that agreed them. Every access request with its system, the date it was raised and the ticket it went under, and next to it the date the joiner signed in successfully or the fact that they never did. The territory and the ramped number at the version handed over. The learning plan at a version, with the week each subject sits in, the person teaching it, and a date against any change made after teaching started. Each session as held or missed, and who covered a session the teacher missed. The calls listened to, with dates. The sitting as scheduled, with what the joiner was told they may bring. The first conversation as debriefed, naming what the customer asked that the joiner could not answer and the date each gap is fixed by. The ramp report at each checkpoint. An auditor can read the run and see what was taught, what was open, and what the joiner was never given. 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`.
--- name: run-the-calendar-around-the-teaching description: Holds the plan of what is learned in which week and who teaches it, and books the introductions, the recorded and live calls the joiner listens to, and the sitting itself, in diaries on both sides. Use it when running `ref/rev/certify-a-seller` and `ref/rev/onboard-a-seller`. license: CC-BY-4.0 metadata: agent: onboarding-manager agent-version: "1" --- # Run the calendar around the teaching ## What it does Holds the plan of what is learned in which week and who teaches it, and books the introductions, the recorded and live calls the joiner listens to, and the sitting itself, in diaries on both sides. It runs the calendar and the checklist rather than doing the teaching. ## Where it happens The agent does this in four activities across two reference processes. Each one names the activity as that process words it. - **Build the Learning Plan** - `ref/rev/onboard-a-seller`, activity 6 - [Onboard a Seller](../../../../processes/revenue-operations/onboard-a-seller.md) - **Listen to Real Conversations** - `ref/rev/onboard-a-seller`, activity 12 - [Onboard a Seller](../../../../processes/revenue-operations/onboard-a-seller.md) - **Meet the People** - `ref/rev/onboard-a-seller`, activity 7 - [Onboard a Seller](../../../../processes/revenue-operations/onboard-a-seller.md) - **Schedule the Sitting** - `ref/rev/certify-a-seller`, activity 8 - [Certify a Seller](../../../../processes/revenue-operations/certify-a-seller.md) ## What to record Per joiner: the start as taken in, with the job, the manager and the date. The job and the ramp in the manager's own words, from the briefing that agreed them. Every access request with its system, the date it was raised and the ticket it went under, and next to it the date the joiner signed in successfully or the fact that they never did. The territory and the ramped number at the version handed over. The learning plan at a version, with the week each subject sits in, the person teaching it, and a date against any change made after teaching started. Each session as held or missed, and who covered a session the teacher missed. The calls listened to, with dates. The sitting as scheduled, with what the joiner was told they may bring. The first conversation as debriefed, naming what the customer asked that the joiner could not answer and the date each gap is fixed by. The ramp report at each checkpoint. An auditor can read the run and see what was taught, what was open, and what the joiner was never given. 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`.
--- name: take-in-a-joiner-and-their-job description: Takes in who is joining, into which job and from when, has the manager state the job and the ramp expected in their own words, and takes the patch and the ramped number at the version whoever set them signed. Use it when running `ref/rev/onboard-a-seller`. license: CC-BY-4.0 metadata: agent: onboarding-manager agent-version: "1" --- # Take in a joiner and their job ## What it does Takes in who is joining, into which job and from when, has the manager state the job and the ramp expected in their own words, and takes the patch and the ramped number at the version whoever set them signed. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Confirm the Job and the Manager** - `ref/rev/onboard-a-seller`, activity 2 - [Onboard a Seller](../../../../processes/revenue-operations/onboard-a-seller.md) - **Take in the Start** - `ref/rev/onboard-a-seller`, activity 1 - [Onboard a Seller](../../../../processes/revenue-operations/onboard-a-seller.md) - **Take in the Territory and the Number** - `ref/rev/onboard-a-seller`, activity 4 - [Onboard a Seller](../../../../processes/revenue-operations/onboard-a-seller.md) ## What to record Per joiner: the start as taken in, with the job, the manager and the date. The job and the ramp in the manager's own words, from the briefing that agreed them. Every access request with its system, the date it was raised and the ticket it went under, and next to it the date the joiner signed in successfully or the fact that they never did. The territory and the ramped number at the version handed over. The learning plan at a version, with the week each subject sits in, the person teaching it, and a date against any change made after teaching started. Each session as held or missed, and who covered a session the teacher missed. The calls listened to, with dates. The sitting as scheduled, with what the joiner was told they may bring. The first conversation as debriefed, naming what the customer asked that the joiner could not answer and the date each gap is fixed by. The ramp report at each checkpoint. An auditor can read the run and see what was taught, what was open, and what the joiner was never given. 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`.
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.
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 8 roles, and the access level beside each one is the most the work needs.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/mcp.schema.json",
"mcpServers": {
"identity-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/identity-system"
},
"learning-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/learning-system"
},
"enablement-library": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/enablement-library"
},
"territory-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/territory-record"
},
"call-recording-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/call-recording-system"
},
"calendar": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/calendar"
},
"crm": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/crm"
},
"analytics": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/analytics"
}
}
}
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.
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.
Schedule the Sitting
Take in the Start · Confirm the Job and the Manager · Order the Access · Take in the Territory and the Number · Check the Access Landed · Build the Learning Plan · Meet the People · Listen to Real Conversations · Debrief the First Conversation · Report the Ramp
Publish to One Address
What it writes down
Per joiner: the start as taken in, with the job, the manager and the date. The job and the ramp in the manager's own words, from the briefing that agreed them. Every access request with its system, the date it was raised and the ticket it went under, and next to it the date the joiner signed in successfully or the fact that they never did. The territory and the ramped number at the version handed over. The learning plan at a version, with the week each subject sits in, the person teaching it, and a date against any change made after teaching started. Each session as held or missed, and who covered a session the teacher missed. The calls listened to, with dates. The sitting as scheduled, with what the joiner was told they may bring. The first conversation as debriefed, naming what the customer asked that the joiner could not answer and the date each gap is fixed by. The ramp report at each checkpoint. An auditor can read the run and see what was taught, what was open, and what the joiner was never given.
What it will not do
Does not teach. The product, the market, the process and the pitch belong to the curriculum-manager agent and the people it books, and this agent holds the calendar and the checklist around them. Does not decide whether the joiner is ready, which is the certification-check agent's run and a human signature. Does not set the territory or the ramped number, does not grant its own access, and does not sit in the first customer conversation or take it over.
These limits are written into the job on purpose, so that everyone adopting the process knows which decisions stay with a person.
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.
implements: onboarding-manager v1
One line in your agent's manifest. The catalog checks it against the records your runs actually leave.
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.
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.
- Airtable Sales Ops Skill Skill · airtable.com Set up and run Airtable-based sales operations and CRM workflows — pipeline management, account and renewal management, deal desk, RFP / tender…
- FastMCP seed raise pipeline tracker — syncs from Obsidian CRM, generates meeting MCP server · adelaidasofia.github.io · run it yourself · mirrored from the MCP registry FastMCP seed raise pipeline tracker — syncs from Obsidian CRM, generates meeting prep, tracks…