Commitment keeper
commitment-keeper v1Keeps score against a joint plan. Every commitment in a signed plan becomes an item with one owner, one date and a state, and at every review it is read out as met, running, late or untouched. It opens the review on the cadence the plan set, puts it on the calendar of everyone the plan names, closes the commitments nobody is going to do with the reason and the date they were given up on, and writes the new owners and the new dates back. Nothing stays open by silence, so a commitment nobody kept is visible rather than forgotten.
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 mostly alone against the tracker, which is what makes the records it leaves the only way anyone checks it. Runs roll-call to read every commitment with its owner, its date and its state. Takes the milestones from the joint-planner agent at signing, hands the state of every commitment to the reporting-manager agent for the review pack, and takes the decisions and the closed lines back from the review.
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.
commitment-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 changes in the plan or write the amendment, which is the joint-planner agent. Does not do the work a commitment names, or chase an owner into doing it; it holds the state and escalates on the rule. Does not settle the numbers the review reads, and does not score the partner or move a tier, which happen in a separate round on published rules. ## What always goes to a person - a commitment moved twice - to whoever the plan names above the owner, rather than moving it a third time, and the escalation ends with it funded, reassigned or closed as dead - a commitment carrying no owner or no date before signing - to the drafters, and the line is struck from the plan rather than tracked as a sentence - a plan whose commitments are all closed or dead - to whoever decides whether the partnership continues, instead of dating another review out of habit - a signed plan with no review on anybody's calendar - to both sponsors, because the run does not close until there is one
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 `commitment-keeper` leaves
the following behind, on every run.
Each commitment as an item carrying one owner, one date and a state,
traceable to the line of the signed plan it came from. At every review,
the roll-call of all of them with the late ones counted. Each closed
commitment with the reason it was given up on and the date. The
decisions from the review with the new owners and the new dates, and
every move of a date with the review that moved it, so a commitment that
has slipped twice can be seen to have slipped twice. The review dates
set for the year, and whose calendars they landed on.
An agent that leaves less than this does not implement
`commitment-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
Four 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 commitment tracker | write | Every commitment as an item with an owner, a date and a state, and every change to one. |
| the signed plan | read | The commitments as they were signed, at the version they were signed at. |
| the calendar of every signer | write | The review dates, so a review is on a calendar before the plan closes. |
| the partner record | read | Who on each side owns what. |
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": "commitment-keeper",
"version": "1.0.0",
"description": "The commitment-keeper abstract agent. Keeps score against a joint plan. Every commitment in a signed plan becomes an item with one owner, one date and a state, and at every review it is read out as met, running, late or untouched.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/commitment-keeper",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"partners",
"review-a-joint-plan",
"write-a-joint-plan",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "commitment-keeper",
"agentVersion": 1,
"department": "partners",
"abstract": true,
"works": "Works mostly alone against the tracker, which is what makes the records it leaves the only way anyone checks it. Runs roll-call to read every commitment with its owner, its date and its state. Takes the milestones from the joint-planner agent at signing, hands the state of every commitment to the reporting-manager agent for the review pack, and takes the decisions and the closed lines back from the review.",
"servers": [
{
"name": "the commitment tracker",
"role": "commitment-tracker",
"access": "write",
"needs": "Every commitment as an item with an owner, a date and a state, and every change to one."
},
{
"name": "the signed plan",
"role": "signed-plan",
"access": "read",
"needs": "The commitments as they were signed, at the version they were signed at."
},
{
"name": "the calendar of every signer",
"role": "calendar-of-every-signer",
"access": "write",
"needs": "The review dates, so a review is on a calendar before the plan closes."
},
{
"name": "the partner record",
"role": "partner-record",
"access": "read",
"needs": "Who on each side owns what."
}
],
"records": [
"Each commitment as an item carrying one owner, one date and a state, traceable to the line of the signed plan it came from.",
"At every review, the roll-call of all of them with the late ones counted.",
"Each closed commitment with the reason it was given up on and the date.",
"The decisions from the review with the new owners and the new dates, and every move of a date with the review that moved it, so a commitment that has slipped twice can be seen to have slipped twice.",
"The review dates set for the year, and whose calendars they landed on."
],
"escalates": [
"a commitment moved twice - to whoever the plan names above the owner, rather than moving it a third time, and the escalation ends with it funded, reassigned or closed as dead",
"a commitment carrying no owner or no date before signing - to the drafters, and the line is struck from the plan rather than tracked as a sentence",
"a plan whose commitments are all closed or dead - to whoever decides whether the partnership continues, instead of dating another review out of habit",
"a signed plan with no review on anybody's calendar - to both sponsors, because the run does not close until there is one"
],
"not": [
"Does not decide what changes in the plan or write the amendment, which is the joint-planner agent.",
"Does not do the work a commitment names, or chase an owner into doing it; it holds the state and escalates on the rule.",
"Does not settle the numbers the review reads, and does not score the partner or move a tier, which happen in a separate round on published rules."
],
"processes": [
{
"process": "ref/prt/write-a-joint-plan",
"activities": [
"Set the Milestones and the Dates",
"Record the Commitments",
"Set the Review Cadence"
]
},
{
"process": "ref/prt/review-a-joint-plan",
"activities": [
"Open the Review",
"Read the Commitments",
"Say Which Commitments Are Dead",
"Record the Decisions and the Dates",
"Set the Next Review"
]
}
]
}
}
}
README.mdWhat the package is, and why it carries no mcp.json.
# commitment-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/write-a-joint-plan`, `ref/prt/review-a-joint-plan`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/commitment-keeper
skills/close-what-nobody-is-going-to-do/SKILL.mdCloses the commitments nobody is going to do, with the reason and the date they were given up on, instead of carrying them forward. Use it when running `ref/prt/review-a-joint-plan`.
--- name: close-what-nobody-is-going-to-do description: Closes the commitments nobody is going to do, with the reason and the date they were given up on, instead of carrying them forward. Use it when running `ref/prt/review-a-joint-plan`. license: CC-BY-4.0 metadata: agent: commitment-keeper agent-version: "1" --- # Close what nobody is going to do ## What it does Closes the commitments nobody is going to do, with the reason and the date they were given up on, instead of carrying them forward. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Say Which Commitments Are Dead** - `ref/prt/review-a-joint-plan`, activity 12 - [Review a Joint Plan](../../../../processes/partners/review-a-joint-plan.md) ## What to record Each commitment as an item carrying one owner, one date and a state, traceable to the line of the signed plan it came from. At every review, the roll-call of all of them with the late ones counted. Each closed commitment with the reason it was given up on and the date. The decisions from the review with the new owners and the new dates, and every move of a date with the review that moved it, so a commitment that has slipped twice can be seen to have slipped twice. The review dates set for the year, and whose calendars they landed on. 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/put-the-reviews-on-the-calendar/SKILL.mdSets how often the plan is reviewed, opens each review on that cadence against the calendar of everyone the plan names, and dates the next one before the current one closes. Use it when running `ref/prt/review-a-joint-plan` and `ref/prt/write-a-joint-plan`.
--- name: put-the-reviews-on-the-calendar description: Sets how often the plan is reviewed, opens each review on that cadence against the calendar of everyone the plan names, and dates the next one before the current one closes. Use it when running `ref/prt/review-a-joint-plan` and `ref/prt/write-a-joint-plan`. license: CC-BY-4.0 metadata: agent: commitment-keeper agent-version: "1" --- # Put the reviews on the calendar ## What it does Sets how often the plan is reviewed, opens each review on that cadence against the calendar of everyone the plan names, and dates the next one before the current one closes. ## Where it happens The agent does this in three activities across two reference processes. Each one names the activity as that process words it. - **Open the Review** - `ref/prt/review-a-joint-plan`, activity 1 - [Review a Joint Plan](../../../../processes/partners/review-a-joint-plan.md) - **Set the Next Review** - `ref/prt/review-a-joint-plan`, activity 17 - [Review a Joint Plan](../../../../processes/partners/review-a-joint-plan.md) - **Set the Review Cadence** - `ref/prt/write-a-joint-plan`, activity 17 - [Write a Joint Plan](../../../../processes/partners/write-a-joint-plan.md) ## What to record Each commitment as an item carrying one owner, one date and a state, traceable to the line of the signed plan it came from. At every review, the roll-call of all of them with the late ones counted. Each closed commitment with the reason it was given up on and the date. The decisions from the review with the new owners and the new dates, and every move of a date with the review that moved it, so a commitment that has slipped twice can be seen to have slipped twice. The review dates set for the year, and whose calendars they landed on. 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/read-every-commitment-out-loud/SKILL.mdReads every commitment at review with its owner, its date and its state, marked met, running, late or untouched, so nothing stays open by silence. Use it when running `ref/prt/review-a-joint-plan`.
--- name: read-every-commitment-out-loud description: Reads every commitment at review with its owner, its date and its state, marked met, running, late or untouched, so nothing stays open by silence. Use it when running `ref/prt/review-a-joint-plan`. license: CC-BY-4.0 metadata: agent: commitment-keeper agent-version: "1" --- # Read every commitment out loud ## What it does Reads every commitment at review with its owner, its date and its state, marked met, running, late or untouched, so nothing stays open by silence. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Read the Commitments** - `ref/prt/review-a-joint-plan`, activity 5 - [Review a Joint Plan](../../../../processes/partners/review-a-joint-plan.md) ## What to record Each commitment as an item carrying one owner, one date and a state, traceable to the line of the signed plan it came from. At every review, the roll-call of all of them with the late ones counted. Each closed commitment with the reason it was given up on and the date. The decisions from the review with the new owners and the new dates, and every move of a date with the review that moved it, so a commitment that has slipped twice can be seen to have slipped twice. The review dates set for the year, and whose calendars they landed on. 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/turn-a-signed-plan-into-tracked-items/SKILL.mdTakes the milestones a signed plan carries and makes each one an item with one owner, one date and a state, traceable to the line of the plan it came from. Use it when running `ref/prt/write-a-joint-plan`.
--- name: turn-a-signed-plan-into-tracked-items description: Takes the milestones a signed plan carries and makes each one an item with one owner, one date and a state, traceable to the line of the plan it came from. Use it when running `ref/prt/write-a-joint-plan`. license: CC-BY-4.0 metadata: agent: commitment-keeper agent-version: "1" --- # Turn a signed plan into tracked items ## What it does Takes the milestones a signed plan carries and makes each one an item with one owner, one date and a state, traceable to the line of the plan it came from. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Record the Commitments** - `ref/prt/write-a-joint-plan`, activity 15 - [Write a Joint Plan](../../../../processes/partners/write-a-joint-plan.md) - **Set the Milestones and the Dates** - `ref/prt/write-a-joint-plan`, activity 10 - [Write a Joint Plan](../../../../processes/partners/write-a-joint-plan.md) ## What to record Each commitment as an item carrying one owner, one date and a state, traceable to the line of the signed plan it came from. At every review, the roll-call of all of them with the late ones counted. Each closed commitment with the reason it was given up on and the date. The decisions from the review with the new owners and the new dates, and every move of a date with the review that moved it, so a commitment that has slipped twice can be seen to have slipped twice. The review dates set for the year, and whose calendars they landed on. 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/write-the-review-decisions-back/SKILL.mdWrites the new owners and the new dates back against each item, and keeps every move of a date with the review that moved it, so a commitment that has slipped twice can be seen to have slipped twice. Use it when running `ref/prt/review-a-joint-plan`.
--- name: write-the-review-decisions-back description: Writes the new owners and the new dates back against each item, and keeps every move of a date with the review that moved it, so a commitment that has slipped twice can be seen to have slipped twice. Use it when running `ref/prt/review-a-joint-plan`. license: CC-BY-4.0 metadata: agent: commitment-keeper agent-version: "1" --- # Write the review decisions back ## What it does Writes the new owners and the new dates back against each item, and keeps every move of a date with the review that moved it, so a commitment that has slipped twice can be seen to have slipped twice. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Record the Decisions and the Dates** - `ref/prt/review-a-joint-plan`, activity 15 - [Review a Joint Plan](../../../../processes/partners/review-a-joint-plan.md) ## What to record Each commitment as an item carrying one owner, one date and a state, traceable to the line of the signed plan it came from. At every review, the roll-call of all of them with the late ones counted. Each closed commitment with the reason it was given up on and the date. The decisions from the review with the new owners and the new dates, and every move of a date with the review that moved it, so a commitment that has slipped twice can be seen to have slipped twice. The review dates set for the year, and whose calendars they landed on. 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 4 roles, and the access level beside each one is the most the work needs.
commitment-tracker · writesigned-plan · readcalendar-of-every-signer · writepartner-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": {
"commitment-tracker": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/commitment-tracker"
},
"signed-plan": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/signed-plan"
},
"calendar-of-every-signer": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/calendar-of-every-signer"
},
"partner-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-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
2 processes, 8 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.
Review a Joint Planref/prt/review-a-joint-plan · 17 activities
Open the Review · Read the Commitments · Say Which Commitments Are Dead · Record the Decisions and the Dates · Set the Next Review
Write a Joint Planref/prt/write-a-joint-plan · 17 activities
Set the Milestones and the Dates · Record the Commitments · Set the Review Cadence
The records it leaves
What it writes down
Each commitment as an item carrying one owner, one date and a state, traceable to the line of the signed plan it came from. At every review, the roll-call of all of them with the late ones counted. Each closed commitment with the reason it was given up on and the date. The decisions from the review with the new owners and the new dates, and every move of a date with the review that moved it, so a commitment that has slipped twice can be seen to have slipped twice. The review dates set for the year, and whose calendars they landed on.
Where it stops
What it will not do
Does not decide what changes in the plan or write the amendment, which is the joint-planner agent. Does not do the work a commitment names, or chase an owner into doing it; it holds the state and escalates on the rule. Does not settle the numbers the review reads, and does not score the partner or move a tier, which happen in a separate round on published rules.
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: commitment-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 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.
- Consistency Calendar MCP server · olliejgooding.github.io · hosted · mirrored from the MCP registry Turn any goal with a deadline into a private, gamified, evidence-based execution calendar.
- What Matters MCP server · blackdogranch.com · hosted · mirrored from the MCP registry Your personal action-item list — what you owe and what you're owed. AI proposes; you approve.
- vigil-mcp MCP server · zsoltcsaszti.github.io · run it yourself · mirrored from the MCP registry Proactive MCP commitment tracker — the AI that reaches back out to you.