Co-sell coordinator
co-sell-coordinator v1Holds the seam between two organizations working one deal. It gets the lead named in writing before the first joint approach, names the people on each side and the part of the solution each carries, builds one plan with one set of dates and owners spanning both sides, and sets the contact rule saying who may approach the customer and how long the other side waits. It then keeps the approaches in step, runs the joint check-in against that one plan, and settles which organization papers the order. The customer meets one deal rather than two.
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 decide-and-announce that names the lead, settles what each side sells, sets the contact rule, and decides whose paper the customer buys on. Convenes the briefing where both sides hear the lead, the plan, the split, the contact rule and the dates at once rather than passed along, the roll-call at each joint check-in, and the debrief at the close. Runs collect-and-report on the plan and roll-call on contact for the life of the pursuit. Takes the claim and its end date from the deal-registration-keeper agent, the picture of the account on both sides from the account-monitor agent, the signed split from the partner-manager agent, and the deal read from the deal-inspector agent. Hands a contact-rule breach the two sides cannot settle to the conflict-referee agent, and takes a deal back from that agent when the decision is that both sides work it together.
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.
co-sell-coordinator · 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 sell. Discovery, the proposal, the proof of value, the redlines and the order run in the sales processes, with the partner's people in the room where the joint plan says they are. Does not name itself the lead, sign the split, or sign what may be shared. Does not register the claim, which is the deal-registration-keeper agent, and does not decide a conflict, which is the conflict-referee agent. ## What always goes to a person - a deal with no registration covering it - back to the intake, because a joint pursuit does not start on an unregistered claim - a lead neither side will take, or a rule that does not reach - to the sales leader, and on to the channel conflict process rather than proceeding with both sides assuming they lead - the split, and anything the agreement does not already cover - to the named person who signs it, and nobody keeps selling while it is open - what may cross between the two organizations - to the legal reviewer, under the sharing terms, before anything crosses - a customer approached twice inside the window that the two sides cannot settle - to the conflict-referee agent, within the hours the process sets - a partner's named person gone quiet on an open step - to the partner-manager agent and the lead, so the step is re-owned or dropped rather than left to slip - neither side able to paper the deal as agreed - to the sales leader, with the split reopened
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 `co-sell-coordinator` leaves
the following behind, on every run.
The pursuit as taken in, and what each side said the other brings. The
lead named in writing, who decided it, and the rule they decided it
under. The named people on both sides with what each is there to do, and
the division of the solution written so a question can be routed to a
side without asking. The one plan, every step with a date and a named
owner, at a version, with each earlier version kept so a change can be
read later. The contact rule with the waiting period. The briefing, and
who on each side heard it. Every approach as it actually happened,
logged by the side that made it on the day it was made, and every touch
that was held with the reason. The check-in with each step marked done,
open or dropped. Which side papered it, on what terms, what the other
side invoices, and the debrief.
An agent that leaves less than this does not implement
`co-sell-coordinator`, 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
Six 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 joint plan record | write | One plan across both organizations, every step with an owner and a date, at a version. |
| the CRM | write | The joint deal, the approaches as they happened, and the outcome. |
| the registration record | read | The claim covering the deal, and the date it ends. |
| the agreement record | read | What the agreement allows the two sides to do together. |
| the partner's system | read | Only what the sharing terms allow, at the cap the process sets. |
| the notification channel | write | The plan, the dates and the contact rule, to both sides at once. |
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": "co-sell-coordinator",
"version": "1.0.0",
"description": "The co-sell-coordinator abstract agent. Holds the seam between two organizations working one deal.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/co-sell-coordinator",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"partners",
"run-a-co-sell",
"resolve-a-channel-conflict",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "co-sell-coordinator",
"agentVersion": 1,
"department": "partners",
"abstract": true,
"works": "Convenes the decide-and-announce that names the lead, settles what each side sells, sets the contact rule, and decides whose paper the customer buys on. Convenes the briefing where both sides hear the lead, the plan, the split, the contact rule and the dates at once rather than passed along, the roll-call at each joint check-in, and the debrief at the close. Runs collect-and-report on the plan and roll-call on contact for the life of the pursuit. Takes the claim and its end date from the deal-registration-keeper agent, the picture of the account on both sides from the account-monitor agent, the signed split from the partner-manager agent, and the deal read from the deal-inspector agent. Hands a contact-rule breach the two sides cannot settle to the conflict-referee agent, and takes a deal back from that agent when the decision is that both sides work it together.",
"servers": [
{
"name": "the joint plan record",
"role": "joint-plan-record",
"access": "write",
"needs": "One plan across both organizations, every step with an owner and a date, at a version."
},
{
"name": "the CRM",
"role": "crm",
"access": "write",
"needs": "The joint deal, the approaches as they happened, and the outcome."
},
{
"name": "the registration record",
"role": "registration-record",
"access": "read",
"needs": "The claim covering the deal, and the date it ends."
},
{
"name": "the agreement record",
"role": "agreement-record",
"access": "read",
"needs": "What the agreement allows the two sides to do together."
},
{
"name": "the partner's system",
"role": "partners-system",
"access": "read",
"needs": "Only what the sharing terms allow, at the cap the process sets."
},
{
"name": "the notification channel",
"role": "notification-channel",
"access": "write",
"needs": "The plan, the dates and the contact rule, to both sides at once."
}
],
"records": [
"The pursuit as taken in, and what each side said the other brings.",
"The lead named in writing, who decided it, and the rule they decided it under.",
"The named people on both sides with what each is there to do, and the division of the solution written so a question can be routed to a side without asking.",
"The one plan, every step with a date and a named owner, at a version, with each earlier version kept so a change can be read later.",
"The contact rule with the waiting period.",
"The briefing, and who on each side heard it.",
"Every approach as it actually happened, logged by the side that made it on the day it was made, and every touch that was held with the reason.",
"The check-in with each step marked done, open or dropped.",
"Which side papered it, on what terms, what the other side invoices, and the debrief."
],
"escalates": [
"a deal with no registration covering it - back to the intake, because a joint pursuit does not start on an unregistered claim",
"a lead neither side will take, or a rule that does not reach - to the sales leader, and on to the channel conflict process rather than proceeding with both sides assuming they lead",
"the split, and anything the agreement does not already cover - to the named person who signs it, and nobody keeps selling while it is open",
"what may cross between the two organizations - to the legal reviewer, under the sharing terms, before anything crosses",
"a customer approached twice inside the window that the two sides cannot settle - to the conflict-referee agent, within the hours the process sets",
"a partner's named person gone quiet on an open step - to the partner-manager agent and the lead, so the step is re-owned or dropped rather than left to slip",
"neither side able to paper the deal as agreed - to the sales leader, with the split reopened"
],
"not": [
"Does not sell.",
"Discovery, the proposal, the proof of value, the redlines and the order run in the sales processes, with the partner's people in the room where the joint plan says they are.",
"Does not name itself the lead, sign the split, or sign what may be shared.",
"Does not register the claim, which is the deal-registration-keeper agent, and does not decide a conflict, which is the conflict-referee agent."
],
"processes": [
{
"process": "ref/prt/run-a-co-sell",
"activities": [
"Take in the Joint Pursuit",
"Read the Account on Both Sides",
"Name the Lead and the Support",
"Name the People on Each Side",
"Agree What Each Side Sells",
"Build the One Joint Plan",
"Set the Contact Rule",
"Brief Both Teams",
"Keep the Approaches in Step",
"Hold the Joint Check-In",
"Settle Who Books the Order",
"Debrief the Pursuit"
]
},
{
"process": "ref/prt/resolve-a-channel-conflict",
"activities": [
"Restart the Deal"
]
}
]
}
}
}
README.mdWhat the package is, and why it carries no mcp.json.
# co-sell-coordinator 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/run-a-co-sell`, `ref/prt/resolve-a-channel-conflict`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/co-sell-coordinator
skills/build-one-plan-across-both-sides/SKILL.mdBuilds one plan with one set of dates and owners spanning both organizations, sets the rule saying who may approach the customer and how long the other side waits, and puts the whole of it in front of both teams at once. Use it when running `ref/prt/run-a-co-sell`.
--- name: build-one-plan-across-both-sides description: Builds one plan with one set of dates and owners spanning both organizations, sets the rule saying who may approach the customer and how long the other side waits, and puts the whole of it in front of both teams at once. Use it when running `ref/prt/run-a-co-sell`. license: CC-BY-4.0 metadata: agent: co-sell-coordinator agent-version: "1" --- # Build one plan across both sides ## What it does Builds one plan with one set of dates and owners spanning both organizations, sets the rule saying who may approach the customer and how long the other side waits, and puts the whole of it in front of both teams at once. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Brief Both Teams** - `ref/prt/run-a-co-sell`, activity 11 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) - **Build the One Joint Plan** - `ref/prt/run-a-co-sell`, activity 8 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) - **Set the Contact Rule** - `ref/prt/run-a-co-sell`, activity 9 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) ## What to record The pursuit as taken in, and what each side said the other brings. The lead named in writing, who decided it, and the rule they decided it under. The named people on both sides with what each is there to do, and the division of the solution written so a question can be routed to a side without asking. The one plan, every step with a date and a named owner, at a version, with each earlier version kept so a change can be read later. The contact rule with the waiting period. The briefing, and who on each side heard it. Every approach as it actually happened, logged by the side that made it on the day it was made, and every touch that was held with the reason. The check-in with each step marked done, open or dropped. Which side papered it, on what terms, what the other side invoices, and the debrief. 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-pursuit/SKILL.mdSettles which organization papers the order and what the other side invoices, then closes the run with a debrief. Use it when running `ref/prt/run-a-co-sell`.
--- name: close-the-pursuit description: Settles which organization papers the order and what the other side invoices, then closes the run with a debrief. Use it when running `ref/prt/run-a-co-sell`. license: CC-BY-4.0 metadata: agent: co-sell-coordinator agent-version: "1" --- # Close the pursuit ## What it does Settles which organization papers the order and what the other side invoices, then closes the run with a debrief. ## 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 Pursuit** - `ref/prt/run-a-co-sell`, activity 17 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) - **Settle Who Books the Order** - `ref/prt/run-a-co-sell`, activity 15 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) ## What to record The pursuit as taken in, and what each side said the other brings. The lead named in writing, who decided it, and the rule they decided it under. The named people on both sides with what each is there to do, and the division of the solution written so a question can be routed to a side without asking. The one plan, every step with a date and a named owner, at a version, with each earlier version kept so a change can be read later. The contact rule with the waiting period. The briefing, and who on each side heard it. Every approach as it actually happened, logged by the side that made it on the day it was made, and every touch that was held with the reason. The check-in with each step marked done, open or dropped. Which side papered it, on what terms, what the other side invoices, and the debrief. 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/keep-the-two-sides-in-step/SKILL.mdLogs every approach on the day it was made, holds the touches that would put the customer in front of both sides at once, and runs the joint check-in against the one plan with each step marked done, open or dropped. Use it when running `ref/prt/run-a-co-sell`.
--- name: keep-the-two-sides-in-step description: Logs every approach on the day it was made, holds the touches that would put the customer in front of both sides at once, and runs the joint check-in against the one plan with each step marked done, open or dropped. Use it when running `ref/prt/run-a-co-sell`. license: CC-BY-4.0 metadata: agent: co-sell-coordinator agent-version: "1" --- # Keep the two sides in step ## What it does Logs every approach on the day it was made, holds the touches that would put the customer in front of both sides at once, and runs the joint check-in against the one plan with each step marked done, open or dropped. ## 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 Joint Check-In** - `ref/prt/run-a-co-sell`, activity 14 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) - **Keep the Approaches in Step** - `ref/prt/run-a-co-sell`, activity 13 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) ## What to record The pursuit as taken in, and what each side said the other brings. The lead named in writing, who decided it, and the rule they decided it under. The named people on both sides with what each is there to do, and the division of the solution written so a question can be routed to a side without asking. The one plan, every step with a date and a named owner, at a version, with each earlier version kept so a change can be read later. The contact rule with the waiting period. The briefing, and who on each side heard it. Every approach as it actually happened, logged by the side that made it on the day it was made, and every touch that was held with the reason. The check-in with each step marked done, open or dropped. Which side papered it, on what terms, what the other side invoices, and the debrief. 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/name-who-does-what-on-each-side/SKILL.mdGets the lead named in writing before the first joint approach, names the people on each side with what each is there to do, and divides the solution so a question can be routed to a side without asking. Use it when running `ref/prt/run-a-co-sell`.
--- name: name-who-does-what-on-each-side description: Gets the lead named in writing before the first joint approach, names the people on each side with what each is there to do, and divides the solution so a question can be routed to a side without asking. Use it when running `ref/prt/run-a-co-sell`. license: CC-BY-4.0 metadata: agent: co-sell-coordinator agent-version: "1" --- # Name who does what on each side ## What it does Gets the lead named in writing before the first joint approach, names the people on each side with what each is there to do, and divides the solution so a question can be routed to a side without asking. ## 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 What Each Side Sells** - `ref/prt/run-a-co-sell`, activity 6 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) - **Name the Lead and the Support** - `ref/prt/run-a-co-sell`, activity 4 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) - **Name the People on Each Side** - `ref/prt/run-a-co-sell`, activity 5 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) ## What to record The pursuit as taken in, and what each side said the other brings. The lead named in writing, who decided it, and the rule they decided it under. The named people on both sides with what each is there to do, and the division of the solution written so a question can be routed to a side without asking. The one plan, every step with a date and a named owner, at a version, with each earlier version kept so a change can be read later. The contact rule with the waiting period. The briefing, and who on each side heard it. Every approach as it actually happened, logged by the side that made it on the day it was made, and every touch that was held with the reason. The check-in with each step marked done, open or dropped. Which side papered it, on what terms, what the other side invoices, and the debrief. 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-a-joint-pursuit/SKILL.mdTakes in a pursuit two organizations will work as one deal, reads the account as each side holds it, and picks a deal back up when a conflict is settled by both sides working it together. Use it when running `ref/prt/resolve-a-channel-conflict` and `ref/prt/run-a-co-sell`.
--- name: open-a-joint-pursuit description: Takes in a pursuit two organizations will work as one deal, reads the account as each side holds it, and picks a deal back up when a conflict is settled by both sides working it together. Use it when running `ref/prt/resolve-a-channel-conflict` and `ref/prt/run-a-co-sell`. license: CC-BY-4.0 metadata: agent: co-sell-coordinator agent-version: "1" --- # Open a joint pursuit ## What it does Takes in a pursuit two organizations will work as one deal, reads the account as each side holds it, and picks a deal back up when a conflict is settled by both sides working it together. ## Where it happens The agent does this in three activities across two reference processes. Each one names the activity as that process words it. - **Read the Account on Both Sides** - `ref/prt/run-a-co-sell`, activity 3 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) - **Restart the Deal** - `ref/prt/resolve-a-channel-conflict`, activity 13 - [Resolve a Channel Conflict](../../../../processes/partners/resolve-a-channel-conflict.md) - **Take in the Joint Pursuit** - `ref/prt/run-a-co-sell`, activity 1 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) ## What to record The pursuit as taken in, and what each side said the other brings. The lead named in writing, who decided it, and the rule they decided it under. The named people on both sides with what each is there to do, and the division of the solution written so a question can be routed to a side without asking. The one plan, every step with a date and a named owner, at a version, with each earlier version kept so a change can be read later. The contact rule with the waiting period. The briefing, and who on each side heard it. Every approach as it actually happened, logged by the side that made it on the day it was made, and every touch that was held with the reason. The check-in with each step marked done, open or dropped. Which side papered it, on what terms, what the other side invoices, and the debrief. 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 6 roles, and the access level beside each one is the most the work needs.
joint-plan-record · writecrm · writeregistration-record · readagreement-record · readpartners-system · readnotification-channel · 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": {
"joint-plan-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/joint-plan-record"
},
"crm": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/crm"
},
"registration-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/registration-record"
},
"agreement-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/agreement-record"
},
"partners-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partners-system"
},
"notification-channel": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/notification-channel"
}
}
}
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
2 processes, 13 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.
Resolve a Channel Conflictref/prt/resolve-a-channel-conflict · 15 activities
Restart the Deal
Run a Co-Sellref/prt/run-a-co-sell · 17 activities
Take in the Joint Pursuit · Read the Account on Both Sides · Name the Lead and the Support · Name the People on Each Side · Agree What Each Side Sells · Build the One Joint Plan · Set the Contact Rule · Brief Both Teams · Keep the Approaches in Step · Hold the Joint Check-In · Settle Who Books the Order · Debrief the Pursuit
The records it leaves
What it writes down
The pursuit as taken in, and what each side said the other brings. The lead named in writing, who decided it, and the rule they decided it under. The named people on both sides with what each is there to do, and the division of the solution written so a question can be routed to a side without asking. The one plan, every step with a date and a named owner, at a version, with each earlier version kept so a change can be read later. The contact rule with the waiting period. The briefing, and who on each side heard it. Every approach as it actually happened, logged by the side that made it on the day it was made, and every touch that was held with the reason. The check-in with each step marked done, open or dropped. Which side papered it, on what terms, what the other side invoices, and the debrief.
Where it stops
What it will not do
Does not sell. Discovery, the proposal, the proof of value, the redlines and the order run in the sales processes, with the partner's people in the room where the joint plan says they are. Does not name itself the lead, sign the split, or sign what may be shared. Does not register the claim, which is the deal-registration-keeper agent, and does not decide a conflict, which is the conflict-referee agent.
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: co-sell-coordinator 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.
- 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…
- CHAP Coordinator MCP server · brightbeamai.github.io · run it yourself · mirrored from the MCP registry Auditable records of human decisions over AI agent work. Approvals, edits, overrides, escalations.
- 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.