Tier assessor
tier-assessor v1Applies the published tiering rules the same way to every partner. It reads the rules at the version in force, checks that the same evidence is present for every partner in scope and marks an absence as absent rather than counting it as a zero, and lets the rules produce a tier before anybody argues. Every proposal that differs from the rules is written down as an exception with a reason, a person asking and a date it expires. It scores partners against the plans they agreed to in the performance round, says what would move each one up or down, and records where the rules gave a result nobody could defend.
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 apply the rules to the evidence and to score each partner against the plan they agreed to. Sits in the approval where a named signer approves the tier set and a named signer approves every exception. Convenes the debrief that records where the rules did not fit, and runs collect-and-report over the exception register for the life of a round. Takes the evidence from the analytics and partner-monitor agents and the cost of each tier from the margin-keeper agent, hands the referrals out of a performance round into the tiering round, and hands the entitlement check to the partner-monitor agent.
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 sign a tier or an exception. Does not price what a tier costs or check its discount against the margin floor, which is the margin-keeper agent, and does not confirm the support behind a tier can be staffed. Does not decide whether a partner is held, helped, warned or ended, which the channel leader does in the performance round, and does not change a tier inside that round: a result that moves a tier is referred, and the published rules decide it in the tiering round. Does not rewrite the rules; it records where they failed. ## What always goes to a person - the approval, always - to the named signer for the tier set and a named signer for every exception, because no tier is set by an agent - a partner whose evidence stays incomplete - to whoever owns the missing source, and the partner keeps their current tier with the reason recorded rather than being dropped by a rule that never ran - a tier the rules gave that nobody can defend - to the signer, as an exception with a name behind it, never overridden quietly - exceptions outnumbering the rule - to whoever owns the rules, with the count, because the next version is the fix and not a longer exception list - a partner disputing the numbers behind a referral - back to the reconcile, because a tier does not move on a number under dispute - a partner moving down - to whoever serves the notice, so the notice period runs and the old terms hold while it does
# The records this abstract agent must leave
This is the contract. An agent implementing `tier-assessor` leaves the
following behind, on every run.
The rules at the version in force, and the date they were published. The
evidence per partner, each line naming the system and the date it was
read from, with every gap marked as a gap. The tier the rules gave, with
the inputs it was computed from, so somebody else can recompute it from
what was written down. Every exception with its reason, the person
asking, the signer, and the date it expires, counted in the published
round. In a performance round, the score with the rules version beside
it, the finding said as on plan, behind or at risk, and the referral
with the score and the date behind it. At an exit, the access that was
taken down and when. At the close, where the rules gave a tier nobody
could defend, and what the next version should say.
An agent that leaves less than this does not implement `tier-assessor`,
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 partner record | write | The tier each partner holds, the inputs that produced it, and the rules version behind it. |
| the published tier rules | read | At the version in force, with the date they were published. |
| the evidence set | read | The same measures, over the same period, from the same systems, for every partner in scope. |
| the exception register | write | Every departure from the rules, its reason, the person asking, and the date it expires. |
| the partner portal | write | The entitlement a tier carries, and its removal when a relationship ends. |
| the agreement record | read | What the partner was promised at the tier they 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.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
"name": "tier-assessor",
"version": "1.0.0",
"description": "The tier-assessor abstract agent. Applies the published tiering rules the same way to every partner. It reads the rules at the version in force, checks that the same evidence is present for every partner in scope and marks an absence as absent rather than counting it as a zero, and lets the rules produce a tier before anybody argues.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/tier-assessor",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"partners",
"set-a-partner-tier",
"review-partner-performance",
"end-a-partner-relationship",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "tier-assessor",
"agentVersion": 1,
"department": "partners",
"abstract": true,
"works": "Runs assessment to apply the rules to the evidence and to score each partner against the plan they agreed to. Sits in the approval where a named signer approves the tier set and a named signer approves every exception. Convenes the debrief that records where the rules did not fit, and runs collect-and-report over the exception register for the life of a round. Takes the evidence from the analytics and partner-monitor agents and the cost of each tier from the margin-keeper agent, hands the referrals out of a performance round into the tiering round, and hands the entitlement check to the partner-monitor agent.",
"servers": [
{
"name": "the partner record",
"role": "partner-record",
"access": "write",
"needs": "The tier each partner holds, the inputs that produced it, and the rules version behind it."
},
{
"name": "the published tier rules",
"role": "published-tier-rules",
"access": "read",
"needs": "At the version in force, with the date they were published."
},
{
"name": "the evidence set",
"role": "evidence-set",
"access": "read",
"needs": "The same measures, over the same period, from the same systems, for every partner in scope."
},
{
"name": "the exception register",
"role": "exception-register",
"access": "write",
"needs": "Every departure from the rules, its reason, the person asking, and the date it expires."
},
{
"name": "the partner portal",
"role": "partner-portal",
"access": "write",
"needs": "The entitlement a tier carries, and its removal when a relationship ends."
},
{
"name": "the agreement record",
"role": "agreement-record",
"access": "read",
"needs": "What the partner was promised at the tier they hold."
}
],
"records": [
"The rules at the version in force, and the date they were published.",
"The evidence per partner, each line naming the system and the date it was read from, with every gap marked as a gap.",
"The tier the rules gave, with the inputs it was computed from, so somebody else can recompute it from what was written down.",
"Every exception with its reason, the person asking, the signer, and the date it expires, counted in the published round.",
"In a performance round, the score with the rules version beside it, the finding said as on plan, behind or at risk, and the referral with the score and the date behind it.",
"At an exit, the access that was taken down and when.",
"At the close, where the rules gave a tier nobody could defend, and what the next version should say."
],
"escalates": [
"the approval, always - to the named signer for the tier set and a named signer for every exception, because no tier is set by an agent",
"a partner whose evidence stays incomplete - to whoever owns the missing source, and the partner keeps their current tier with the reason recorded rather than being dropped by a rule that never ran",
"a tier the rules gave that nobody can defend - to the signer, as an exception with a name behind it, never overridden quietly",
"exceptions outnumbering the rule - to whoever owns the rules, with the count, because the next version is the fix and not a longer exception list",
"a partner disputing the numbers behind a referral - back to the reconcile, because a tier does not move on a number under dispute",
"a partner moving down - to whoever serves the notice, so the notice period runs and the old terms hold while it does"
],
"not": [
"Does not sign a tier or an exception.",
"Does not price what a tier costs or check its discount against the margin floor, which is the margin-keeper agent, and does not confirm the support behind a tier can be staffed.",
"Does not decide whether a partner is held, helped, warned or ended, which the channel leader does in the performance round, and does not change a tier inside that round: a result that moves a tier is referred, and the published rules decide it in the tiering round.",
"Does not rewrite the rules; it records where they failed."
],
"processes": [
{
"process": "ref/prt/set-a-partner-tier",
"activities": [
"Open the Tiering Round",
"Read the Rules in Force",
"Check the Evidence Is Complete",
"Apply the Rules",
"List Every Exception",
"Approve the Tiers and the Exceptions",
"Record What the Rules Got Wrong"
]
},
{
"process": "ref/prt/review-partner-performance",
"activities": [
"Score Each Partner Against the Plan",
"Draft the Finding per Partner",
"Refer the Tier Changes"
]
},
{
"process": "ref/prt/end-a-partner-relationship",
"activities": [
"Close Off the Access"
]
}
]
}
}
}
# tier-assessor 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/set-a-partner-tier`, `ref/prt/review-partner-performance`, `ref/prt/end-a-partner-relationship`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/tier-assessor
--- name: apply-the-rules-and-list-the-exceptions description: Lets the rules produce a tier for each partner from the evidence, and writes down every proposal that differs from that result as an exception with a reason, a person asking and a date it expires. Use it when running `ref/prt/set-a-partner-tier`. license: CC-BY-4.0 metadata: agent: tier-assessor agent-version: "1" --- # Apply the rules and list the exceptions ## What it does Lets the rules produce a tier for each partner from the evidence, and writes down every proposal that differs from that result as an exception with a reason, a person asking and a date it expires. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Apply the Rules** - `ref/prt/set-a-partner-tier`, activity 5 - [Set a Partner Tier](../../../../processes/partners/set-a-partner-tier.md) - **List Every Exception** - `ref/prt/set-a-partner-tier`, activity 6 - [Set a Partner Tier](../../../../processes/partners/set-a-partner-tier.md) ## What to record The rules at the version in force, and the date they were published. The evidence per partner, each line naming the system and the date it was read from, with every gap marked as a gap. The tier the rules gave, with the inputs it was computed from, so somebody else can recompute it from what was written down. Every exception with its reason, the person asking, the signer, and the date it expires, counted in the published round. In a performance round, the score with the rules version beside it, the finding said as on plan, behind or at risk, and the referral with the score and the date behind it. At an exit, the access that was taken down and when. At the close, where the rules gave a tier nobody could defend, and what the next version should say. 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: close-the-tiering-round description: Puts the tier set and every exception to the named signers, then records where the rules gave a result nobody could defend and what the next version of the rules should say. Use it when running `ref/prt/set-a-partner-tier`. license: CC-BY-4.0 metadata: agent: tier-assessor agent-version: "1" --- # Close the tiering round ## What it does Puts the tier set and every exception to the named signers, then records where the rules gave a result nobody could defend and what the next version of the rules should say. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Approve the Tiers and the Exceptions** - `ref/prt/set-a-partner-tier`, activity 10 - [Set a Partner Tier](../../../../processes/partners/set-a-partner-tier.md) - **Record What the Rules Got Wrong** - `ref/prt/set-a-partner-tier`, activity 16 - [Set a Partner Tier](../../../../processes/partners/set-a-partner-tier.md) ## What to record The rules at the version in force, and the date they were published. The evidence per partner, each line naming the system and the date it was read from, with every gap marked as a gap. The tier the rules gave, with the inputs it was computed from, so somebody else can recompute it from what was written down. Every exception with its reason, the person asking, the signer, and the date it expires, counted in the published round. In a performance round, the score with the rules version beside it, the finding said as on plan, behind or at risk, and the referral with the score and the date behind it. At an exit, the access that was taken down and when. At the close, where the rules gave a tier nobody could defend, and what the next version should say. 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: open-a-tiering-round description: Starts a round, reads the tiering rules at the version in force with the date they were published, and checks that the same evidence is present for every partner in scope. Use it when running `ref/prt/set-a-partner-tier`. license: CC-BY-4.0 metadata: agent: tier-assessor agent-version: "1" --- # Open a tiering round ## What it does Starts a round, reads the tiering rules at the version in force with the date they were published, and checks that the same evidence is present for every partner in scope. A gap is marked as a gap rather than counted as a zero. ## 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 the Evidence Is Complete** - `ref/prt/set-a-partner-tier`, activity 4 - [Set a Partner Tier](../../../../processes/partners/set-a-partner-tier.md) - **Open the Tiering Round** - `ref/prt/set-a-partner-tier`, activity 1 - [Set a Partner Tier](../../../../processes/partners/set-a-partner-tier.md) - **Read the Rules in Force** - `ref/prt/set-a-partner-tier`, activity 2 - [Set a Partner Tier](../../../../processes/partners/set-a-partner-tier.md) ## What to record The rules at the version in force, and the date they were published. The evidence per partner, each line naming the system and the date it was read from, with every gap marked as a gap. The tier the rules gave, with the inputs it was computed from, so somebody else can recompute it from what was written down. Every exception with its reason, the person asking, the signer, and the date it expires, counted in the published round. In a performance round, the score with the rules version beside it, the finding said as on plan, behind or at risk, and the referral with the score and the date behind it. At an exit, the access that was taken down and when. At the close, where the rules gave a tier nobody could defend, and what the next version should say. 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: score-a-partner-against-its-plan description: Scores each partner against the plan it agreed to, writes the finding as on plan, behind or at risk, and refers any result that would move a tier into the tiering round, where the published rules decide it. Use it when running `ref/prt/review-partner-performance`. license: CC-BY-4.0 metadata: agent: tier-assessor agent-version: "1" --- # Score a partner against its plan ## What it does Scores each partner against the plan it agreed to, writes the finding as on plan, behind or at risk, and refers any result that would move a tier into the tiering round, where the published rules decide 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. - **Draft the Finding per Partner** - `ref/prt/review-partner-performance`, activity 9 - [Review Partner Performance](../../../../processes/partners/review-partner-performance.md) - **Refer the Tier Changes** - `ref/prt/review-partner-performance`, activity 14 - [Review Partner Performance](../../../../processes/partners/review-partner-performance.md) - **Score Each Partner Against the Plan** - `ref/prt/review-partner-performance`, activity 7 - [Review Partner Performance](../../../../processes/partners/review-partner-performance.md) ## What to record The rules at the version in force, and the date they were published. The evidence per partner, each line naming the system and the date it was read from, with every gap marked as a gap. The tier the rules gave, with the inputs it was computed from, so somebody else can recompute it from what was written down. Every exception with its reason, the person asking, the signer, and the date it expires, counted in the published round. In a performance round, the score with the rules version beside it, the finding said as on plan, behind or at risk, and the referral with the score and the date behind it. At an exit, the access that was taken down and when. At the close, where the rules gave a tier nobody could defend, and what the next version should say. 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-down-what-a-tier-gave description: Removes the entitlement a tier carried when a relationship ends, and records what was taken down and when. Use it when running `ref/prt/end-a-partner-relationship`. license: CC-BY-4.0 metadata: agent: tier-assessor agent-version: "1" --- # Take down what a tier gave ## What it does Removes the entitlement a tier carried when a relationship ends, and records what was taken down and when. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Close Off the Access** - `ref/prt/end-a-partner-relationship`, activity 14 - [End a Partner Relationship](../../../../processes/partners/end-a-partner-relationship.md) ## What to record The rules at the version in force, and the date they were published. The evidence per partner, each line naming the system and the date it was read from, with every gap marked as a gap. The tier the rules gave, with the inputs it was computed from, so somebody else can recompute it from what was written down. Every exception with its reason, the person asking, the signer, and the date it expires, counted in the published round. In a performance round, the score with the rules version beside it, the finding said as on plan, behind or at risk, and the referral with the score and the date behind it. At an exit, the access that was taken down and when. At the close, where the rules gave a tier nobody could defend, and what the next version should say. 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": {
"partner-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-record"
},
"published-tier-rules": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/published-tier-rules"
},
"evidence-set": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/evidence-set"
},
"exception-register": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/exception-register"
},
"partner-portal": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-portal"
},
"agreement-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/agreement-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.
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.
Close Off the Access
Score Each Partner Against the Plan · Draft the Finding per Partner · Refer the Tier Changes
Open the Tiering Round · Read the Rules in Force · Check the Evidence Is Complete · Apply the Rules · List Every Exception · Approve the Tiers and the Exceptions · Record What the Rules Got Wrong
What it writes down
The rules at the version in force, and the date they were published. The evidence per partner, each line naming the system and the date it was read from, with every gap marked as a gap. The tier the rules gave, with the inputs it was computed from, so somebody else can recompute it from what was written down. Every exception with its reason, the person asking, the signer, and the date it expires, counted in the published round. In a performance round, the score with the rules version beside it, the finding said as on plan, behind or at risk, and the referral with the score and the date behind it. At an exit, the access that was taken down and when. At the close, where the rules gave a tier nobody could defend, and what the next version should say.
What it will not do
Does not sign a tier or an exception. Does not price what a tier costs or check its discount against the margin floor, which is the margin-keeper agent, and does not confirm the support behind a tier can be staffed. Does not decide whether a partner is held, helped, warned or ended, which the channel leader does in the performance round, and does not change a tier inside that round: a result that moves a tier is referred, and the published rules decide it in the tiering round. Does not rewrite the rules; it records where they failed.
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: tier-assessor 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.
- ai·rete·rag MCP server · ai-rete-rag.com · hosted · run it yourself · mirrored from the MCP registry Author rules from policy docs, then decide: a Rete engine gives the verdict, an LLM explains why.
- Tier1 IT Assessment MCP server · mcp.tier1.nz · hosted · mirrored from the MCP registry Read-only IT Health Check, domain security, recommendations, pricing, and draft enquiries.
- Norma by Quality Clouds MCP server · qualityclouds.ai · hosted · mirrored from the MCP registry Deterministic AI code review, with an audit record. Governance inside the agent loop.