Deal registration keeper
deal-registration-keeper v1Takes a partner's claim on a customer deal, resolves it to one account, and tests it against the published registration rules in order, recording each rule as passed or failed with the reason. A named person decides it. This agent then sets what an approved claim protects and what it does not, reads the protection period off the signed agreement rather than agreeing it on a call, and records the claim at a version with every rule result behind it. It watches the claim after that, warns the partner before the protection ends, and closes it as converted, extended or expired.
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.
Runs assessment to test the rules in order and to look for a live claim already on the customer, collect-and-report to pull what each side holds when a conflict is opened, and roll-call over the live claims for the life of a run. Sits in the decide-and-announce where a named person approves, declines or holds the registration. Takes the resolved account from the account-monitor agent and the evidence marks from the deal-inspector agent, works with the partner-manager agent on the partner's standing and on telling both sides, hands a competing claim to the conflict-referee agent, and hands an approved claim and its end date to the co-sell-coordinator agent when the deal is taken joint.
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 decide the registration, does not lengthen a protection period without a signature, and does not turn an assertion into evidence to save a claim. Does not sell the deal that follows an approved claim, which runs in the ordinary sales processes with the partner in the room. Does not settle a channel conflict, which is the conflict-referee agent, and does not run the joint pursuit, which is the co-sell-coordinator agent. ## What always goes to a person - another partner already holding a live claim on the same customer - to the conflict-referee agent, with both claims, their dates and the rule that separates them, and the partner is told that is where their claim went - a deal the direct team already has open - the same way, and the account owner hears on the day the claim arrived - the decision itself, always - to the named person who approves, declines or holds it, because the agent that ran the checks never decides them - a request for more time - to the signer, because an extension is a decision on the same rules and never a renewal that happens by itself - a registration nobody has answered by the day it is due - to whoever the process names, rather than leaving it open
# The records this abstract agent must leave
This is the contract. An agent implementing `deal-registration-keeper`
leaves the following behind, on every run.
The submission as it arrived, and the single account record it resolved
to. Every published rule applied in order, each marked passed or failed
with the reason, and the rule set at the version that was applied. What
the partner brought, marked evidenced, asserted or absent. The answer,
the person who gave it, and the rule or the gap they gave as the reason.
What the approval covers and what it does not, written so a deal outside
it can be recognized as outside it. The start and end dates, with the
clause in the agreement they came from. What has moved on the deal, read
from the CRM rather than from what the partner reports. The warning, its
date, and anything the partner said in reply. The close as converted,
extended or expired, with the reason.
An agent that leaves less than this does not implement
`deal-registration-keeper`, whatever else it does well.
# 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 registration record | write | The claim at a version, with its rule results, its scope, its dates and its close. |
| the partner portal | read | What the partner submitted, as they submitted it. |
| the CRM | write | The claim attached to the deal it protects, and what has moved on that deal. |
| the agreement record | read | The clause the protection period is read off. |
| the partner record | read | The tier, the agreement in force, and anything overdue that the rules take into account. |
| the notification channel | write | The answer to both sides, and the warning before a claim lapses. |
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": "deal-registration-keeper",
"version": "1.0.0",
"description": "The deal-registration-keeper abstract agent. Takes a partner's claim on a customer deal, resolves it to one account, and tests it against the published registration rules in order, recording each rule as passed or failed with the reason.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/deal-registration-keeper",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"partners",
"register-a-deal",
"resolve-a-channel-conflict",
"run-a-co-sell",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "deal-registration-keeper",
"agentVersion": 1,
"department": "partners",
"abstract": true,
"works": "Runs assessment to test the rules in order and to look for a live claim already on the customer, collect-and-report to pull what each side holds when a conflict is opened, and roll-call over the live claims for the life of a run. Sits in the decide-and-announce where a named person approves, declines or holds the registration. Takes the resolved account from the account-monitor agent and the evidence marks from the deal-inspector agent, works with the partner-manager agent on the partner's standing and on telling both sides, hands a competing claim to the conflict-referee agent, and hands an approved claim and its end date to the co-sell-coordinator agent when the deal is taken joint.",
"servers": [
{
"name": "the registration record",
"role": "registration-record",
"access": "write",
"needs": "The claim at a version, with its rule results, its scope, its dates and its close."
},
{
"name": "the partner portal",
"role": "partner-portal",
"access": "read",
"needs": "What the partner submitted, as they submitted it."
},
{
"name": "the CRM",
"role": "crm",
"access": "write",
"needs": "The claim attached to the deal it protects, and what has moved on that deal."
},
{
"name": "the agreement record",
"role": "agreement-record",
"access": "read",
"needs": "The clause the protection period is read off."
},
{
"name": "the partner record",
"role": "partner-record",
"access": "read",
"needs": "The tier, the agreement in force, and anything overdue that the rules take into account."
},
{
"name": "the notification channel",
"role": "notification-channel",
"access": "write",
"needs": "The answer to both sides, and the warning before a claim lapses."
}
],
"records": [
"The submission as it arrived, and the single account record it resolved to.",
"Every published rule applied in order, each marked passed or failed with the reason, and the rule set at the version that was applied.",
"What the partner brought, marked evidenced, asserted or absent.",
"The answer, the person who gave it, and the rule or the gap they gave as the reason.",
"What the approval covers and what it does not, written so a deal outside it can be recognized as outside it.",
"The start and end dates, with the clause in the agreement they came from.",
"What has moved on the deal, read from the CRM rather than from what the partner reports.",
"The warning, its date, and anything the partner said in reply.",
"The close as converted, extended or expired, with the reason."
],
"escalates": [
"another partner already holding a live claim on the same customer - to the conflict-referee agent, with both claims, their dates and the rule that separates them, and the partner is told that is where their claim went",
"a deal the direct team already has open - the same way, and the account owner hears on the day the claim arrived",
"the decision itself, always - to the named person who approves, declines or holds it, because the agent that ran the checks never decides them",
"a request for more time - to the signer, because an extension is a decision on the same rules and never a renewal that happens by itself",
"a registration nobody has answered by the day it is due - to whoever the process names, rather than leaving it open"
],
"not": [
"Does not decide the registration, does not lengthen a protection period without a signature, and does not turn an assertion into evidence to save a claim.",
"Does not sell the deal that follows an approved claim, which runs in the ordinary sales processes with the partner in the room.",
"Does not settle a channel conflict, which is the conflict-referee agent, and does not run the joint pursuit, which is the co-sell-coordinator agent."
],
"processes": [
{
"process": "ref/prt/register-a-deal",
"activities": [
"Take in the Registration",
"Match It to One Customer",
"Check for an Existing Claim",
"Test It Against the Rules",
"Decide the Registration",
"Set What the Approval Protects",
"Set the Protection Period",
"Record the Claim",
"Warn Before It Lapses",
"Close the Registration"
]
},
{
"process": "ref/prt/resolve-a-channel-conflict",
"activities": [
"Pull What Each Side Holds",
"Establish Who Was First"
]
},
{
"process": "ref/prt/run-a-co-sell",
"activities": [
"Check the Claim and the Terms"
]
}
]
}
}
}
# deal-registration-keeper 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/register-a-deal`, `ref/prt/resolve-a-channel-conflict`, `ref/prt/run-a-co-sell`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/deal-registration-keeper
--- name: answer-what-the-registration-record-holds description: Answers another run that needs to know who holds what. Use it when running `ref/prt/resolve-a-channel-conflict` and `ref/prt/run-a-co-sell`. license: CC-BY-4.0 metadata: agent: deal-registration-keeper agent-version: "1" --- # Answer what the registration record holds ## What it does Answers another run that needs to know who holds what. Pulls what each side holds on a contested customer, establishes which claim came first, and confirms the claim and the terms covering a deal about to be worked jointly. ## Where it happens The agent does this in three activities across two reference processes. Each one names the activity as that process words it. - **Check the Claim and the Terms** - `ref/prt/run-a-co-sell`, activity 2 - [Run a Co-Sell](../../../../processes/partners/run-a-co-sell.md) - **Establish Who Was First** - `ref/prt/resolve-a-channel-conflict`, activity 6 - [Resolve a Channel Conflict](../../../../processes/partners/resolve-a-channel-conflict.md) - **Pull What Each Side Holds** - `ref/prt/resolve-a-channel-conflict`, activity 4 - [Resolve a Channel Conflict](../../../../processes/partners/resolve-a-channel-conflict.md) ## What to record The submission as it arrived, and the single account record it resolved to. Every published rule applied in order, each marked passed or failed with the reason, and the rule set at the version that was applied. What the partner brought, marked evidenced, asserted or absent. The answer, the person who gave it, and the rule or the gap they gave as the reason. What the approval covers and what it does not, written so a deal outside it can be recognized as outside it. The start and end dates, with the clause in the agreement they came from. What has moved on the deal, read from the CRM rather than from what the partner reports. The warning, its date, and anything the partner said in reply. The close as converted, extended or expired, with the reason. 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: set-what-an-approved-claim-protects description: Writes what an approved claim covers and what it does not, reads the protection period off the signed agreement rather than agreeing it on a call, and records the claim at a version with every rule result behind it. Use it when running `ref/prt/register-a-deal`. license: CC-BY-4.0 metadata: agent: deal-registration-keeper agent-version: "1" --- # Set what an approved claim protects ## What it does Writes what an approved claim covers and what it does not, reads the protection period off the signed agreement rather than agreeing it on a call, and records the claim at a version with every rule result behind it. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Record the Claim** - `ref/prt/register-a-deal`, activity 13 - [Register a Deal](../../../../processes/partners/register-a-deal.md) - **Set What the Approval Protects** - `ref/prt/register-a-deal`, activity 10 - [Register a Deal](../../../../processes/partners/register-a-deal.md) - **Set the Protection Period** - `ref/prt/register-a-deal`, activity 11 - [Register a Deal](../../../../processes/partners/register-a-deal.md) ## What to record The submission as it arrived, and the single account record it resolved to. Every published rule applied in order, each marked passed or failed with the reason, and the rule set at the version that was applied. What the partner brought, marked evidenced, asserted or absent. The answer, the person who gave it, and the rule or the gap they gave as the reason. What the approval covers and what it does not, written so a deal outside it can be recognized as outside it. The start and end dates, with the clause in the agreement they came from. What has moved on the deal, read from the CRM rather than from what the partner reports. The warning, its date, and anything the partner said in reply. The close as converted, extended or expired, with the reason. 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-claim-and-resolve-it description: Takes a partner's claim as it arrived and resolves it to one account record, so everything decided after that is decided against a single customer. Use it when running `ref/prt/register-a-deal`. license: CC-BY-4.0 metadata: agent: deal-registration-keeper agent-version: "1" --- # Take in a claim and resolve it ## What it does Takes a partner's claim as it arrived and resolves it to one account record, so everything decided after that is decided against a single customer. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Match It to One Customer** - `ref/prt/register-a-deal`, activity 2 - [Register a Deal](../../../../processes/partners/register-a-deal.md) - **Take in the Registration** - `ref/prt/register-a-deal`, activity 1 - [Register a Deal](../../../../processes/partners/register-a-deal.md) ## What to record The submission as it arrived, and the single account record it resolved to. Every published rule applied in order, each marked passed or failed with the reason, and the rule set at the version that was applied. What the partner brought, marked evidenced, asserted or absent. The answer, the person who gave it, and the rule or the gap they gave as the reason. What the approval covers and what it does not, written so a deal outside it can be recognized as outside it. The start and end dates, with the clause in the agreement they came from. What has moved on the deal, read from the CRM rather than from what the partner reports. The warning, its date, and anything the partner said in reply. The close as converted, extended or expired, with the reason. 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: test-a-claim-against-the-rules description: Looks for a claim already live on the same customer, applies the published rules in order and marks each one passed or failed with the reason, and carries the result to the named person who approves, declines or holds it. Use it when running `ref/prt/register-a-deal`. license: CC-BY-4.0 metadata: agent: deal-registration-keeper agent-version: "1" --- # Test a claim against the rules ## What it does Looks for a claim already live on the same customer, applies the published rules in order and marks each one passed or failed with the reason, and carries the result to the named person who approves, declines or holds it. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Check for an Existing Claim** - `ref/prt/register-a-deal`, activity 4 - [Register a Deal](../../../../processes/partners/register-a-deal.md) - **Decide the Registration** - `ref/prt/register-a-deal`, activity 9 - [Register a Deal](../../../../processes/partners/register-a-deal.md) - **Test It Against the Rules** - `ref/prt/register-a-deal`, activity 6 - [Register a Deal](../../../../processes/partners/register-a-deal.md) ## What to record The submission as it arrived, and the single account record it resolved to. Every published rule applied in order, each marked passed or failed with the reason, and the rule set at the version that was applied. What the partner brought, marked evidenced, asserted or absent. The answer, the person who gave it, and the rule or the gap they gave as the reason. What the approval covers and what it does not, written so a deal outside it can be recognized as outside it. The start and end dates, with the clause in the agreement they came from. What has moved on the deal, read from the CRM rather than from what the partner reports. The warning, its date, and anything the partner said in reply. The close as converted, extended or expired, with the reason. 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: watch-a-claim-to-its-close description: Watches what moves on the deal a claim protects, warns the partner before the protection ends, and closes the claim as converted, extended or expired with the reason. Use it when running `ref/prt/register-a-deal`. license: CC-BY-4.0 metadata: agent: deal-registration-keeper agent-version: "1" --- # Watch a claim to its close ## What it does Watches what moves on the deal a claim protects, warns the partner before the protection ends, and closes the claim as converted, extended or expired with the reason. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Close the Registration** - `ref/prt/register-a-deal`, activity 16 - [Register a Deal](../../../../processes/partners/register-a-deal.md) - **Warn Before It Lapses** - `ref/prt/register-a-deal`, activity 15 - [Register a Deal](../../../../processes/partners/register-a-deal.md) ## What to record The submission as it arrived, and the single account record it resolved to. Every published rule applied in order, each marked passed or failed with the reason, and the rule set at the version that was applied. What the partner brought, marked evidenced, asserted or absent. The answer, the person who gave it, and the rule or the gap they gave as the reason. What the approval covers and what it does not, written so a deal outside it can be recognized as outside it. The start and end dates, with the clause in the agreement they came from. What has moved on the deal, read from the CRM rather than from what the partner reports. The warning, its date, and anything the partner said in reply. The close as converted, extended or expired, with the reason. 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 6 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": {
"registration-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/registration-record"
},
"partner-portal": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-portal"
},
"crm": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/crm"
},
"agreement-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/agreement-record"
},
"partner-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-record"
},
"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.
3 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.
Take in the Registration · Match It to One Customer · Check for an Existing Claim · Test It Against the Rules · Decide the Registration · Set What the Approval Protects · Set the Protection Period · Record the Claim · Warn Before It Lapses · Close the Registration
Pull What Each Side Holds · Establish Who Was First
Check the Claim and the Terms
What it writes down
The submission as it arrived, and the single account record it resolved to. Every published rule applied in order, each marked passed or failed with the reason, and the rule set at the version that was applied. What the partner brought, marked evidenced, asserted or absent. The answer, the person who gave it, and the rule or the gap they gave as the reason. What the approval covers and what it does not, written so a deal outside it can be recognized as outside it. The start and end dates, with the clause in the agreement they came from. What has moved on the deal, read from the CRM rather than from what the partner reports. The warning, its date, and anything the partner said in reply. The close as converted, extended or expired, with the reason.
What it will not do
Does not decide the registration, does not lengthen a protection period without a signature, and does not turn an assertion into evidence to save a claim. Does not sell the deal that follows an approved claim, which runs in the ordinary sales processes with the partner in the room. Does not settle a channel conflict, which is the conflict-referee agent, and does not run the joint pursuit, which is the co-sell-coordinator agent.
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: deal-registration-keeper 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.
Things that could be the worker: an agent, a packaged product, a plugin.
- The Website Specification — A2A agent Agent · specification.website Read-only A2A agent that answers natural-language questions about The Website Specification and returns matching topics with status, canonical URL,…
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.
- StructureClerk MCP server · structureclerk.ca · hosted · mirrored from the MCP registry AI agent policy decisions: ALLOW, DENY, APPROVE, ESCALATE. 192 jurisdictions, signed evidence.
- 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.
- agent-crm MCP server · khaoss85.github.io · hosted · mirrored from the MCP registry Read-only docs for the Accordo CRM framework: what it proves, and where it stops.