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

Joint planner

joint-planner v1

Holds the plan two organizations agreed: the numbers each side works to, the accounts and segments both sides will go after together, and what each side puts in by way of people, money and time. It prices our share against the budget line it is paid from, puts one named owner and one date on every milestone, and writes the plan at a version both sides can hold. At review it names the gaps out loud, carries what the sponsors decided into an amendment, and marks the changed lines against the version they replace.

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/review-a-joint-planref/prt/write-a-joint-planGRANTEDthe shared plan locationwrite — the plan and every amendment at a versthe budget recordread — what our side of the plan costs, held aanalyticsread — last year's result, and the values behithe CRMread — the accounts and segments the plan putsthe partner recordread — the agreement, the tier, and the plan tTHE ABSTRACT AGENTjoint-plannerv1holds the plan two…HANDS TO A PERSONthe signatures, alwaysto the two sponsors, against…a plan neither side will…to the sponsors and the…a side that will not…to that side's sponsor, with…a measure the draft names…back to whoever defines the…MUST FOLLOWbuild-by-talentallocate-and-reconciledecide-and-announcebriefing

Convenes the decide-and-announce in which each side's targets and each side's inputs are settled by the people who can commit them, and the one at review where the sponsors say what changes. Runs allocate-and-reconcile to price our side and to hold that cost for the life of the run, and build-by-talent to write the plan and the amendment. Sits in the briefing where the plays are heard by both sides at once. Takes last year's result from the partner-monitor and analytics agents and the coverage check that removes an account, hands the milestones to the commitment-keeper agent to be tracked, and hands the signed plan to the reporting-manager agent to publish.

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.

joint-planner · 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 sign, and does not treat a plan as agreed before both sponsors
have. Does not track the commitments once the plan is signed, which is
the commitment-keeper agent, and does not publish the plan or the review
record. Does not check accounts for overlap or channel conflict, which
is the partner-monitor agent, and does not judge how the partner
performed, which is a separate round on its own published rules.

## What always goes to a person

- the signatures, always - to the two sponsors, against a version of the
  plan, because no plan and no amendment is agreed until they sign
- a plan neither side will fund as written - to the sponsors and the
  finance partner, with the price of the inputs and the budget line
  beside it
- a side that will not commit to a line at review - to that side's
  sponsor, with the line, what was asked and what was refused
- a measure the draft names that no system produces - back to whoever
  defines the measures, before the plan carries a number nobody can pull
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 `joint-planner` leaves the
following behind, on every run.

The targets at a version, with the person on each side who confirmed
them. The account list with the reason written on each one, and every
account removed with the conflict or the owner behind it. The inputs per
side with a name against each line, and what our side costs against the
budget line it comes from. The milestones with one owner and one date
each. The plan at a version, with every blank filled or marked open. At
review, the gaps with the reason and the person closest to each, the
decision as both sponsors announced it, and the amendment with the
changed lines marked against the version they replace. Anybody auditing
a run can read what each side promised, what it cost, and what changed
since.

An agent that leaves less than this does not implement `joint-planner`,
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

Five 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 shared plan location | write | The plan and every amendment at a version both sides read from the same place. |
| the budget record | read | What our side of the plan costs, held against the line it is paid from. |
| analytics | read | Last year's result, and the values behind each measure the plan names. |
| the CRM | read | The accounts and segments the plan puts on the list. |
| the partner record | read | The agreement, the tier, and the plan the partner is working under now. |

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": "joint-planner",
  "version": "1.0.0",
  "description": "The joint-planner abstract agent. Holds the plan two organizations agreed: the numbers each side works to, the accounts and segments both sides will go after together, and what each side puts in by way of people, money and time.",
  "author": {
    "name": "AgentCatalog",
    "url": "https://agentcatalog.com"
  },
  "homepage": "https://agentcatalog.com/abstract-agents/joint-planner",
  "repository": "https://github.com/jeffrschneider/agentcatalog",
  "license": "CC-BY-4.0",
  "keywords": [
    "abstract-agent",
    "reference",
    "partners",
    "write-a-joint-plan",
    "review-a-joint-plan",
    "abstract"
  ],
  "extensions": {
    "com.agentcatalog.agent": {
      "agent": "joint-planner",
      "agentVersion": 1,
      "department": "partners",
      "abstract": true,
      "works": "Convenes the decide-and-announce in which each side's targets and each side's inputs are settled by the people who can commit them, and the one at review where the sponsors say what changes. Runs allocate-and-reconcile to price our side and to hold that cost for the life of the run, and build-by-talent to write the plan and the amendment. Sits in the briefing where the plays are heard by both sides at once. Takes last year's result from the partner-monitor and analytics agents and the coverage check that removes an account, hands the milestones to the commitment-keeper agent to be tracked, and hands the signed plan to the reporting-manager agent to publish.",
      "servers": [
        {
          "name": "the shared plan location",
          "role": "shared-plan-location",
          "access": "write",
          "needs": "The plan and every amendment at a version both sides read from the same place."
        },
        {
          "name": "the budget record",
          "role": "budget-record",
          "access": "read",
          "needs": "What our side of the plan costs, held against the line it is paid from."
        },
        {
          "name": "analytics",
          "role": "analytics",
          "access": "read",
          "needs": "Last year's result, and the values behind each measure the plan names."
        },
        {
          "name": "the CRM",
          "role": "crm",
          "access": "read",
          "needs": "The accounts and segments the plan puts on the list."
        },
        {
          "name": "the partner record",
          "role": "partner-record",
          "access": "read",
          "needs": "The agreement, the tier, and the plan the partner is working under now."
        }
      ],
      "records": [
        "The targets at a version, with the person on each side who confirmed them.",
        "The account list with the reason written on each one, and every account removed with the conflict or the owner behind it.",
        "The inputs per side with a name against each line, and what our side costs against the budget line it comes from.",
        "The milestones with one owner and one date each.",
        "The plan at a version, with every blank filled or marked open.",
        "At review, the gaps with the reason and the person closest to each, the decision as both sponsors announced it, and the amendment with the changed lines marked against the version they replace.",
        "Anybody auditing a run can read what each side promised, what it cost, and what changed since."
      ],
      "escalates": [
        "the signatures, always - to the two sponsors, against a version of the plan, because no plan and no amendment is agreed until they sign",
        "a plan neither side will fund as written - to the sponsors and the finance partner, with the price of the inputs and the budget line beside it",
        "a side that will not commit to a line at review - to that side's sponsor, with the line, what was asked and what was refused",
        "a measure the draft names that no system produces - back to whoever defines the measures, before the plan carries a number nobody can pull"
      ],
      "not": [
        "Does not sign, and does not treat a plan as agreed before both sponsors have.",
        "Does not track the commitments once the plan is signed, which is the commitment-keeper agent, and does not publish the plan or the review record.",
        "Does not check accounts for overlap or channel conflict, which is the partner-monitor agent, and does not judge how the partner performed, which is a separate round on its own published rules."
      ],
      "processes": [
        {
          "process": "ref/prt/write-a-joint-plan",
          "activities": [
            "Set the Targets Each Side Works To",
            "Pick the Accounts and Segments",
            "Agree What Each Side Puts In",
            "Price the Plan",
            "Name the Plays",
            "Set the Milestones and the Dates",
            "Draft the Plan"
          ]
        },
        {
          "process": "ref/prt/review-a-joint-plan",
          "activities": [
            "Name the Gaps Out Loud",
            "Decide What Changes",
            "Write the Amendment"
          ]
        }
      ]
    }
  }
}
README.mdWhat the package is, and why it carries no mcp.json.
# joint-planner

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/joint-planner
skills/amend-a-plan-at-review/SKILL.mdNames the gaps out loud at review with the person closest to each, carries what the sponsors decided into an amendment, and marks the changed lines against the version they replace. Use it when running `ref/prt/review-a-joint-plan`.
---
name: amend-a-plan-at-review
description: Names the gaps out loud at review with the person closest to each, carries what the sponsors decided into an amendment, and marks the changed lines against the version they replace. Use it when running `ref/prt/review-a-joint-plan`.
license: CC-BY-4.0
metadata:
  agent: joint-planner
  agent-version: "1"
---

# Amend a plan at review

## What it does

Names the gaps out loud at review with the person closest to each,
carries what the sponsors decided into an amendment, and marks the
changed lines against the version they replace.

## Where it happens

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

- **Decide What Changes**
  - `ref/prt/review-a-joint-plan`, activity 11 -
    [Review a Joint Plan](../../../../processes/partners/review-a-joint-plan.md)
- **Name the Gaps Out Loud**
  - `ref/prt/review-a-joint-plan`, activity 10 -
    [Review a Joint Plan](../../../../processes/partners/review-a-joint-plan.md)
- **Write the Amendment**
  - `ref/prt/review-a-joint-plan`, activity 13 -
    [Review a Joint Plan](../../../../processes/partners/review-a-joint-plan.md)

## What to record

The targets at a version, with the person on each side who confirmed
them. The account list with the reason written on each one, and every
account removed with the conflict or the owner behind it. The inputs per
side with a name against each line, and what our side costs against the
budget line it comes from. The milestones with one owner and one date
each. The plan at a version, with every blank filled or marked open. At
review, the gaps with the reason and the person closest to each, the
decision as both sponsors announced it, and the amendment with the
changed lines marked against the version they replace. Anybody auditing
a run can read what each side promised, what it cost, and what changed
since.

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/pick-the-accounts-and-the-plays/SKILL.mdPicks the accounts and segments both sides go after together, with the reason written on each one and the conflict or the owner behind every account removed, then names the plays run against them. Use it when running `ref/prt/write-a-joint-plan`.
---
name: pick-the-accounts-and-the-plays
description: Picks the accounts and segments both sides go after together, with the reason written on each one and the conflict or the owner behind every account removed, then names the plays run against them. Use it when running `ref/prt/write-a-joint-plan`.
license: CC-BY-4.0
metadata:
  agent: joint-planner
  agent-version: "1"
---

# Pick the accounts and the plays

## What it does

Picks the accounts and segments both sides go after together, with the
reason written on each one and the conflict or the owner behind every
account removed, then names the plays run against them.

## Where it happens

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

- **Name the Plays**
  - `ref/prt/write-a-joint-plan`, activity 9 -
    [Write a Joint Plan](../../../../processes/partners/write-a-joint-plan.md)
- **Pick the Accounts and Segments**
  - `ref/prt/write-a-joint-plan`, activity 5 -
    [Write a Joint Plan](../../../../processes/partners/write-a-joint-plan.md)

## What to record

The targets at a version, with the person on each side who confirmed
them. The account list with the reason written on each one, and every
account removed with the conflict or the owner behind it. The inputs per
side with a name against each line, and what our side costs against the
budget line it comes from. The milestones with one owner and one date
each. The plan at a version, with every blank filled or marked open. At
review, the gaps with the reason and the person closest to each, the
decision as both sponsors announced it, and the amendment with the
changed lines marked against the version they replace. Anybody auditing
a run can read what each side promised, what it cost, and what changed
since.

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/price-our-side-of-the-plan/SKILL.mdPrices what our share of the plan costs and holds that cost against the budget line it is paid from. Use it when running `ref/prt/write-a-joint-plan`.
---
name: price-our-side-of-the-plan
description: Prices what our share of the plan costs and holds that cost against the budget line it is paid from. Use it when running `ref/prt/write-a-joint-plan`.
license: CC-BY-4.0
metadata:
  agent: joint-planner
  agent-version: "1"
---

# Price our side of the plan

## What it does

Prices what our share of the plan costs and holds that cost against the
budget line it is paid from.

## Where it happens

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

- **Price the Plan**
  - `ref/prt/write-a-joint-plan`, activity 8 -
    [Write a Joint Plan](../../../../processes/partners/write-a-joint-plan.md)

## What to record

The targets at a version, with the person on each side who confirmed
them. The account list with the reason written on each one, and every
account removed with the conflict or the owner behind it. The inputs per
side with a name against each line, and what our side costs against the
budget line it comes from. The milestones with one owner and one date
each. The plan at a version, with every blank filled or marked open. At
review, the gaps with the reason and the person closest to each, the
decision as both sponsors announced it, and the amendment with the
changed lines marked against the version they replace. Anybody auditing
a run can read what each side promised, what it cost, and what changed
since.

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/settle-what-each-side-signs-up-to/SKILL.mdSettles the numbers each side works to and what each side puts in by way of people, money and time, with the person on each side who confirmed it. Use it when running `ref/prt/write-a-joint-plan`.
---
name: settle-what-each-side-signs-up-to
description: Settles the numbers each side works to and what each side puts in by way of people, money and time, with the person on each side who confirmed it. Use it when running `ref/prt/write-a-joint-plan`.
license: CC-BY-4.0
metadata:
  agent: joint-planner
  agent-version: "1"
---

# Settle what each side signs up to

## What it does

Settles the numbers each side works to and what each side puts in by way
of people, money and time, with the person on each side who confirmed
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.

- **Agree What Each Side Puts In**
  - `ref/prt/write-a-joint-plan`, activity 7 -
    [Write a Joint Plan](../../../../processes/partners/write-a-joint-plan.md)
- **Set the Targets Each Side Works To**
  - `ref/prt/write-a-joint-plan`, activity 4 -
    [Write a Joint Plan](../../../../processes/partners/write-a-joint-plan.md)

## What to record

The targets at a version, with the person on each side who confirmed
them. The account list with the reason written on each one, and every
account removed with the conflict or the owner behind it. The inputs per
side with a name against each line, and what our side costs against the
budget line it comes from. The milestones with one owner and one date
each. The plan at a version, with every blank filled or marked open. At
review, the gaps with the reason and the person closest to each, the
decision as both sponsors announced it, and the amendment with the
changed lines marked against the version they replace. Anybody auditing
a run can read what each side promised, what it cost, and what changed
since.

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-plan-at-a-version/SKILL.mdPuts one named owner and one date on every milestone and writes the plan at a version both sides read from the same place, with every blank filled or marked open. Use it when running `ref/prt/write-a-joint-plan`.
---
name: write-the-plan-at-a-version
description: Puts one named owner and one date on every milestone and writes the plan at a version both sides read from the same place, with every blank filled or marked open. Use it when running `ref/prt/write-a-joint-plan`.
license: CC-BY-4.0
metadata:
  agent: joint-planner
  agent-version: "1"
---

# Write the plan at a version

## What it does

Puts one named owner and one date on every milestone and writes the plan
at a version both sides read from the same place, with every blank
filled or marked open.

## Where it happens

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

- **Draft the Plan**
  - `ref/prt/write-a-joint-plan`, activity 12 -
    [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

The targets at a version, with the person on each side who confirmed
them. The account list with the reason written on each one, and every
account removed with the conflict or the owner behind it. The inputs per
side with a name against each line, and what our side costs against the
budget line it comes from. The milestones with one owner and one date
each. The plan at a version, with every blank filled or marked open. At
review, the gaps with the reason and the person closest to each, the
decision as both sponsors announced it, and the amendment with the
changed lines marked against the version they replace. Anybody auditing
a run can read what each side promised, what it cost, and what changed
since.

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 5 roles, and the access level beside each one is the most the work needs.

shared-plan-location · writebudget-record · readanalytics · readcrm · readpartner-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": {
    "shared-plan-location": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/shared-plan-location"
    },
    "budget-record": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/budget-record"
    },
    "analytics": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/analytics"
    },
    "crm": {
      "type": "streamable-http",
      "url": "https://mcp.yourcompany.com/crm"
    },
    "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, 10 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
1234567891011121314151617

Name the Gaps Out Loud · Decide What Changes · Write the Amendment

Write a Joint Planref/prt/write-a-joint-plan · 17 activities
1234567891011121314151617

Set the Targets Each Side Works To · Pick the Accounts and Segments · Agree What Each Side Puts In · Price the Plan · Name the Plays · Set the Milestones and the Dates · Draft the Plan

The records it leaves

What it writes down

The targets at a version, with the person on each side who confirmed them. The account list with the reason written on each one, and every account removed with the conflict or the owner behind it. The inputs per side with a name against each line, and what our side costs against the budget line it comes from. The milestones with one owner and one date each. The plan at a version, with every blank filled or marked open. At review, the gaps with the reason and the person closest to each, the decision as both sponsors announced it, and the amendment with the changed lines marked against the version they replace. Anybody auditing a run can read what each side promised, what it cost, and what changed since.

Where it stops

What it will not do

Does not sign, and does not treat a plan as agreed before both sponsors have. Does not track the commitments once the plan is signed, which is the commitment-keeper agent, and does not publish the plan or the review record. Does not check accounts for overlap or channel conflict, which is the partner-monitor agent, and does not judge how the partner performed, which is a separate round on its own 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: joint-planner 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.

  • YAPL MCP server · yapl.app · hosted · mirrored from the MCP registry Draft-safe project planning: tasks, dependencies, resources, schedules and cost metrics.
  • powerplan MCP server · cynacons.github.io · run it yourself · mirrored from the MCP registry MCP server that makes PLAN.md the operational backbone of agentic development
  • PlanWright MCP server · planwright.tools · hosted · mirrored from the MCP registry Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.