Sign in
abstract agent · partners · 3 processes · plugin 1.0.0

Deal registration keeper

deal-registration-keeper v1

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. 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.

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.

WORKS INref/prt/register-a-dealref/prt/resolve-a-channel-conflictref/prt/run-a-co-sellGRANTEDthe registration recordwrite — the claim at a version, with its rule the partner portalread — what the partner submitted, as they subthe CRMwrite — the claim attached to the deal it protthe agreement recordread — the clause the protection period is reathe partner recordread — the tier, the agreement in force, and athe notification channelwrite — the answer to both sides, and the warnTHE ABSTRACT AGENTdeal-registration-keeperv1takes a partner's claim…HANDS TO A PERSONanother partner already…to the conflict-referee…a deal the direct team…the same way, and the…the decision itself, alwaysto the named person who…a request for more timeto the signer, because an…a registration nobody has…to whoever the process…MUST FOLLOWcollect-and-reportdecide-and-announceassessmentroll call

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.

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.

deal-registration-keeper · 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 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
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 `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.
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 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.
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": "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"
          ]
        }
      ]
    }
  }
}
README.mdWhat the package is, and why it carries no mcp.json.
# 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
skills/answer-what-the-registration-record-holds/SKILL.mdAnswers 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`.
---
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`.
skills/set-what-an-approved-claim-protects/SKILL.mdWrites 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`.
---
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`.
skills/take-in-a-claim-and-resolve-it/SKILL.mdTakes 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`.
---
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`.
skills/test-a-claim-against-the-rules/SKILL.mdLooks 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`.
---
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`.
skills/watch-a-claim-to-its-close/SKILL.mdWatches 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`.
---
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`.
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.

registration-record · writepartner-portal · readcrm · writeagreement-record · readpartner-record · 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": {
    "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.

Where it works

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.

Register a Dealref/prt/register-a-deal · 16 activities
12345678910111213141516

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

Resolve a Channel Conflictref/prt/resolve-a-channel-conflict · 15 activities
123456789101112131415

Pull What Each Side Holds · Establish Who Was First

Run a Co-Sellref/prt/run-a-co-sell · 17 activities
1234567891011121314151617

Check the Claim and the Terms

The records it leaves

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.

Where it stops

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.

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: deal-registration-keeper 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 do the job

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,…
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.

  • 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.