abstract agent · partners · 3 processes · plugin 1.0.0

Portal keeper

portal-keeper v1

Holds what a partner can reach. Opens a named login for each person the partner listed, switches on the materials, the prices and the rules that partner's tier allows and leaves everything else off, opens the systems the agreement covers, and publishes material at a version rather than editing it in place. Registers a deal against the partner with its protection period so the same deal cannot be worked twice or claimed later. Takes access away again on the same terms it was given: a person who leaves the partner, within the hours the process sets, and everything the partner holds when the relationship ends.

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 alone at the systems it holds, and reconciles rather than convenes. Runs assessment on whether the partner record is complete enough for access to be opened at all, and allocate-and-reconcile over what is open against what the tier and the agreement allow. Takes the plan and the named people from the partner-onboarding-manager agent, takes the tier and what it entitles from the partner-manager agent, takes course materials and certificates from the curriculum-manager and certification-check agents, and hands the end-to-end test to the partner-monitor agent.

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.

Download the package View on GitHub

portal-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 what a tier is entitled to, which is the tier rules and
the partner-manager agent. Does not write, choose or approve the
material it publishes; it publishes what it is given at the version it
was given. Does not train or certify anybody, which are the
curriculum-manager and certification-check agents, and it issues and
publishes only what a signed pass has already produced. Does not read
what the partner did with the access, which is the partner-monitor
agent.

## What always goes to a person

- a request for access the tier does not cover - to whoever signs for
  that, with the tier rule attached, and nothing is opened while it
  waits
- a shared login or a generic mailbox offered in place of a named person
  - back to the partner's operations contact, refused until a person is
  named
- a test path that does not arrive where it should - to the systems
  administrator, and the access stays uncounted until it does
- access it is asked to close while a customer still depends on it - to
  the partner lead, named rather than quietly left 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 `portal-keeper` leaves the
following behind, on every run.

For every account: the person it belongs to, how they can be reached,
the date it was opened and who asked for it. For everything switched on
or left off: the tier rule or the agreement clause that decided it. For
every material published: the version and the date it went to the
partner. The end-to-end test that proved a path works, because no access
is counted as granted until something the partner raised arrived where
it should. For every registered deal: the partner, the date and the
protection period. For every closure: the date, the reason and who told
us.

An agent that leaves less than this does not implement `portal-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 identity system | write | Cap: accounts per partner, set by the adopting organization. |
| the partner portal | write | Visibility, published material and the list of who is certified. |
| deal registration | write | A deal is registered against the partner with its protection period. |
| the support desk | write | The partner's route to help opens and closes with the rest of their access. |
| the licensing system | write | What the partner may issue, opened against what the agreement covers. |
| the certification record | read | Nobody is entitled by a certificate they do not hold. |

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": "portal-keeper",
  "version": "1.0.0",
  "description": "The portal-keeper abstract agent. Holds what a partner can reach.",
  "author": {
    "name": "AgentCatalog",
    "url": "https://agentcatalog.com"
  },
  "homepage": "https://agentcatalog.com/abstract-agents/portal-keeper",
  "repository": "https://github.com/jeffrschneider/agentcatalog",
  "license": "CC-BY-4.0",
  "keywords": [
    "abstract-agent",
    "reference",
    "partners",
    "onboard-a-partner",
    "certify-a-partner",
    "run-a-first-deal-together",
    "abstract"
  ],
  "extensions": {
    "com.agentcatalog.agent": {
      "agent": "portal-keeper",
      "agentVersion": 1,
      "department": "partners",
      "abstract": true,
      "works": "Works alone at the systems it holds, and reconciles rather than convenes. Runs assessment on whether the partner record is complete enough for access to be opened at all, and allocate-and-reconcile over what is open against what the tier and the agreement allow. Takes the plan and the named people from the partner-onboarding-manager agent, takes the tier and what it entitles from the partner-manager agent, takes course materials and certificates from the curriculum-manager and certification-check agents, and hands the end-to-end test to the partner-monitor agent.",
      "servers": [
        {
          "name": "the identity system",
          "role": "identity-system",
          "access": "write",
          "needs": "Cap: accounts per partner, set by the adopting organization."
        },
        {
          "name": "the partner portal",
          "role": "partner-portal",
          "access": "write",
          "needs": "Visibility, published material and the list of who is certified."
        },
        {
          "name": "deal registration",
          "role": "deal-registration",
          "access": "write",
          "needs": "A deal is registered against the partner with its protection period."
        },
        {
          "name": "the support desk",
          "role": "support-desk",
          "access": "write",
          "needs": "The partner's route to help opens and closes with the rest of their access."
        },
        {
          "name": "the licensing system",
          "role": "licensing-system",
          "access": "write",
          "needs": "What the partner may issue, opened against what the agreement covers."
        },
        {
          "name": "the certification record",
          "role": "certification-record",
          "access": "read",
          "needs": "Nobody is entitled by a certificate they do not hold."
        }
      ],
      "records": [
        "For every account: the person it belongs to, how they can be reached, the date it was opened and who asked for it.",
        "For everything switched on or left off: the tier rule or the agreement clause that decided it.",
        "For every material published: the version and the date it went to the partner.",
        "The end-to-end test that proved a path works, because no access is counted as granted until something the partner raised arrived where it should.",
        "For every registered deal: the partner, the date and the protection period.",
        "For every closure: the date, the reason and who told us."
      ],
      "escalates": [
        "a request for access the tier does not cover - to whoever signs for that, with the tier rule attached, and nothing is opened while it waits",
        "a shared login or a generic mailbox offered in place of a named person - back to the partner's operations contact, refused until a person is named",
        "a test path that does not arrive where it should - to the systems administrator, and the access stays uncounted until it does",
        "access it is asked to close while a customer still depends on it - to the partner lead, named rather than quietly left open"
      ],
      "not": [
        "Does not decide what a tier is entitled to, which is the tier rules and the partner-manager agent.",
        "Does not write, choose or approve the material it publishes; it publishes what it is given at the version it was given.",
        "Does not train or certify anybody, which are the curriculum-manager and certification-check agents, and it issues and publishes only what a signed pass has already produced.",
        "Does not read what the partner did with the access, which is the partner-monitor agent."
      ],
      "processes": [
        {
          "process": "ref/prt/certify-a-partner",
          "activities": [
            "Publish the Course Materials",
            "Issue the Certificates",
            "Publish Who Is Certified"
          ]
        },
        {
          "process": "ref/prt/onboard-a-partner",
          "activities": [
            "Check the Partner Record Is Complete",
            "Create the Portal Accounts",
            "Set What the Partner Can See",
            "Grant the Systems Access",
            "Publish the Materials Set",
            "Walk the Partner Through the Portal",
            "Test the Path End to End"
          ]
        },
        {
          "process": "ref/prt/run-a-first-deal-together",
          "activities": [
            "Register the Deal"
          ]
        }
      ]
    }
  }
}

README.mdWhat the package is, and why it carries no mcp.json.

# portal-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/certify-a-partner`, `ref/prt/onboard-a-partner`,
`ref/prt/run-a-first-deal-together`. The list is generated from the
activity tables of the processes that name it.

https://agentcatalog.com/abstract-agents/portal-keeper

skills/issue-and-publish-certificates/SKILL.mdIssues the certificate a passed course has already produced, and puts the list of who is certified where the people who rely on it can read it. Use it when running `ref/prt/certify-a-partner`.

---
name: issue-and-publish-certificates
description: Issues the certificate a passed course has already produced, and puts the list of who is certified where the people who rely on it can read it. Use it when running `ref/prt/certify-a-partner`.
license: CC-BY-4.0
metadata:
  agent: portal-keeper
  agent-version: "1"
---

# Issue and publish certificates

## What it does

Issues the certificate a passed course has already produced, and puts
the list of who is certified where the people who rely on it can read
it.

## Where it happens

The agent does this in two activities across one reference process. Each
one names the activity as that process words it.

- **Issue the Certificates**
  - `ref/prt/certify-a-partner`, activity 14 -
    [Certify a Partner](../../../../processes/partners/certify-a-partner.md)
- **Publish Who Is Certified**
  - `ref/prt/certify-a-partner`, activity 15 -
    [Certify a Partner](../../../../processes/partners/certify-a-partner.md)

## What to record

For every account: the person it belongs to, how they can be reached,
the date it was opened and who asked for it. For everything switched on
or left off: the tier rule or the agreement clause that decided it. For
every material published: the version and the date it went to the
partner. The end-to-end test that proved a path works, because no access
is counted as granted until something the partner raised arrived where
it should. For every registered deal: the partner, the date and the
protection period. For every closure: the date, the reason and who told
us.

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-access-for-a-partner/SKILL.mdChecks the partner record holds enough for access to be opened at all, opens a named login for each person the partner listed, switches on the materials, the prices and the rules that partner's tier allows and leaves everything else off, and opens the systems the agreement covers. Use it when running `ref/prt/onboard-a-partner`.

---
name: open-access-for-a-partner
description: Checks the partner record holds enough for access to be opened at all, opens a named login for each person the partner listed, switches on the materials, the prices and the rules that partner's tier allows and leaves everything else off, and opens the systems the agreement covers. Use it when running `ref/prt/onboard-a-partner`.
license: CC-BY-4.0
metadata:
  agent: portal-keeper
  agent-version: "1"
---

# Open access for a partner

## What it does

Checks the partner record holds enough for access to be opened at all,
opens a named login for each person the partner listed, switches on the
materials, the prices and the rules that partner's tier allows and
leaves everything else off, and opens the systems the agreement covers.

## Where it happens

The agent does this in four activities across one reference process.
Each one names the activity as that process words it.

- **Check the Partner Record Is Complete**
  - `ref/prt/onboard-a-partner`, activity 5 -
    [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md)
- **Create the Portal Accounts**
  - `ref/prt/onboard-a-partner`, activity 6 -
    [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md)
- **Grant the Systems Access**
  - `ref/prt/onboard-a-partner`, activity 8 -
    [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md)
- **Set What the Partner Can See**
  - `ref/prt/onboard-a-partner`, activity 7 -
    [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md)

## What to record

For every account: the person it belongs to, how they can be reached,
the date it was opened and who asked for it. For everything switched on
or left off: the tier rule or the agreement clause that decided it. For
every material published: the version and the date it went to the
partner. The end-to-end test that proved a path works, because no access
is counted as granted until something the partner raised arrived where
it should. For every registered deal: the partner, the date and the
protection period. For every closure: the date, the reason and who told
us.

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/prove-the-access-works/SKILL.mdWalks the partner through what they can now reach, and runs something the partner raised all the way through to where it should arrive, because no access counts as granted until that works. Use it when running `ref/prt/onboard-a-partner`.

---
name: prove-the-access-works
description: Walks the partner through what they can now reach, and runs something the partner raised all the way through to where it should arrive, because no access counts as granted until that works. Use it when running `ref/prt/onboard-a-partner`.
license: CC-BY-4.0
metadata:
  agent: portal-keeper
  agent-version: "1"
---

# Prove the access works

## What it does

Walks the partner through what they can now reach, and runs something
the partner raised all the way through to where it should arrive,
because no access counts as granted until that works.

## Where it happens

The agent does this in two activities across one reference process. Each
one names the activity as that process words it.

- **Test the Path End to End**
  - `ref/prt/onboard-a-partner`, activity 13 -
    [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md)
- **Walk the Partner Through the Portal**
  - `ref/prt/onboard-a-partner`, activity 11 -
    [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md)

## What to record

For every account: the person it belongs to, how they can be reached,
the date it was opened and who asked for it. For everything switched on
or left off: the tier rule or the agreement clause that decided it. For
every material published: the version and the date it went to the
partner. The end-to-end test that proved a path works, because no access
is counted as granted until something the partner raised arrived where
it should. For every registered deal: the partner, the date and the
protection period. For every closure: the date, the reason and who told
us.

That contract covers every activity this abstract agent takes on, and it
is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract
agent does not do is in `com.agentcatalog.agent/NOT.md`.

skills/publish-material-at-a-version/SKILL.mdPuts material in front of the partner at a version and republishes it rather than editing it in place, so a reader can tell which version they were given and on what date. Use it when running `ref/prt/certify-a-partner` and `ref/prt/onboard-a-partner`.

---
name: publish-material-at-a-version
description: Puts material in front of the partner at a version and republishes it rather than editing it in place, so a reader can tell which version they were given and on what date. Use it when running `ref/prt/certify-a-partner` and `ref/prt/onboard-a-partner`.
license: CC-BY-4.0
metadata:
  agent: portal-keeper
  agent-version: "1"
---

# Publish material at a version

## What it does

Puts material in front of the partner at a version and republishes it
rather than editing it in place, so a reader can tell which version they
were given and on what date.

## Where it happens

The agent does this in two activities across two reference processes.
Each one names the activity as that process words it.

- **Publish the Course Materials**
  - `ref/prt/certify-a-partner`, activity 6 -
    [Certify a Partner](../../../../processes/partners/certify-a-partner.md)
- **Publish the Materials Set**
  - `ref/prt/onboard-a-partner`, activity 9 -
    [Onboard a Partner](../../../../processes/partners/onboard-a-partner.md)

## What to record

For every account: the person it belongs to, how they can be reached,
the date it was opened and who asked for it. For everything switched on
or left off: the tier rule or the agreement clause that decided it. For
every material published: the version and the date it went to the
partner. The end-to-end test that proved a path works, because no access
is counted as granted until something the partner raised arrived where
it should. For every registered deal: the partner, the date and the
protection period. For every closure: the date, the reason and who told
us.

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/register-a-deal-against-a-partner/SKILL.mdRegisters a deal against the partner with its protection period, so the same deal cannot be worked twice or claimed later. Use it when running `ref/prt/run-a-first-deal-together`.

---
name: register-a-deal-against-a-partner
description: Registers a deal against the partner with its protection period, so the same deal cannot be worked twice or claimed later. Use it when running `ref/prt/run-a-first-deal-together`.
license: CC-BY-4.0
metadata:
  agent: portal-keeper
  agent-version: "1"
---

# Register a deal against a partner

## What it does

Registers a deal against the partner with its protection period, so the
same deal cannot be worked twice or claimed later.

## Where it happens

The agent does this in one activity across one reference process. Each
one names the activity as that process words it.

- **Register the Deal**
  - `ref/prt/run-a-first-deal-together`, activity 4 -
    [Run a First Deal Together](../../../../processes/partners/run-a-first-deal-together.md)

## What to record

For every account: the person it belongs to, how they can be reached,
the date it was opened and who asked for it. For everything switched on
or left off: the tier rule or the agreement clause that decided it. For
every material published: the version and the date it went to the
partner. The end-to-end test that proved a path works, because no access
is counted as granted until something the partner raised arrived where
it should. For every registered deal: the partner, the date and the
protection period. For every closure: the date, the reason and who told
us.

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.

identity-system · writepartner-portal · writedeal-registration · writesupport-desk · writelicensing-system · writecertification-record · read

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": {
    "identity-system": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/identity-system"
    },
    "partner-portal": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/partner-portal"
    },
    "deal-registration": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/deal-registration"
    },
    "support-desk": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/support-desk"
    },
    "licensing-system": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/licensing-system"
    },
    "certification-record": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/certification-record"
    }
  }
}

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, 11 activities

The highlighted activities are the ones this abstract agent does. The other activities in each process belong to other abstract agents or to people.

Certify a Partnerref/prt/certify-a-partner · 16 activities

Publish the Course Materials · Issue the Certificates · Publish Who Is Certified

Onboard a Partnerref/prt/onboard-a-partner · 16 activities

Check the Partner Record Is Complete · Create the Portal Accounts · Set What the Partner Can See · Grant the Systems Access · Publish the Materials Set · Walk the Partner Through the Portal · Test the Path End to End

Run a First Deal Togetherref/prt/run-a-first-deal-together · 16 activities

Register the Deal

The records it leaves

What it writes down

For every account: the person it belongs to, how they can be reached, the date it was opened and who asked for it. For everything switched on or left off: the tier rule or the agreement clause that decided it. For every material published: the version and the date it went to the partner. The end-to-end test that proved a path works, because no access is counted as granted until something the partner raised arrived where it should. For every registered deal: the partner, the date and the protection period. For every closure: the date, the reason and who told us.

Where it stops

What it will not do

Does not decide what a tier is entitled to, which is the tier rules and the partner-manager agent. Does not write, choose or approve the material it publishes; it publishes what it is given at the version it was given. Does not train or certify anybody, which are the curriculum-manager and certification-check agents, and it issues and publishes only what a signed pass has already produced. Does not read what the partner did with the access, which is the partner-monitor 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: portal-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.

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.
map MCP server · maraventano.github.io · run it yourself · mirrored from the MCP registry A subtractive MCP for agent commerce: read · pay · publish. Teacher, not butler.
gateway MCP server · duvera.ai · hosted · mirrored from the MCP registry Governed AI actions with signed, verifiable receipts: free keyless reads, human-approved writes.