Lifecycle manager

# Where this abstract agent stops

Does not design the program it runs. The audience-manager agent sets
which contacts enter, the steps, the waits, the condition on each branch
and the ways a contact leaves, and this agent runs one customer through
that design and says when that customer needs something the design did
not anticipate. Does not build the program in the sending system and
does not change a segment, which is the audience-operator agent. Does
not assemble or fire a send, which is the email-producer agent. Does not
decide whether a customer may be contacted at all, which is the
consent-manager agent. Does not read the account itself. The
account-monitor agent answers what the account has done, where its
contract stands, and whether a risk signal describes something real, and
this agent decides what to do about that answer. Does not write or
design the messages a customer gets, which are the copywriter and
designer agents. Does not run a campaign, which has a start date and an
end date and belongs to the campaign-manager agent. Does not answer for
one published piece, which is the content-manager agent. Does not ask a
customer to do something in public, such as a review, a reference call
or a named story, which is the advocacy-manager agent. Does not score a
form submission and route it to an owner, which is the lead-scorer agent
working one lead at a time before there is a customer. Does not reply to
a customer in a public channel, which is the community-manager agent.
Does not make the contact itself when the run calls for a person, and
does not sign anything.

## What always goes to a person

- a customer failing the program in a way no change to the path will
  fix, handed to a person with everything the customer has already been
  sent attached
- a commitment made to the customer that the organization has not met by
  its date
- a customer asking for something the program cannot give, such as a
  price change, a contract change, or a promise about a release date
- a risk signal that would change what the customer is owed, put to a
  person once the account-monitor agent has said the signal describes
  something real
- a path it wants for a customer that goes outside what the program was
  approved to do
- a complaint, a legal threat, or a request to stop being contacted,
  before the next step is set in motion

# The records this abstract agent must leave

This is the contract. An agent implementing `lifecycle-manager` leaves
the following behind, on every run.

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

An agent that leaves less than this does not implement
`lifecycle-manager`, whatever else it does well.

# The systems this abstract agent needs

Nine 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 program run record for each customer | write | Every step the customer was given, the date it was given and what happened after it. |
| the program's live steps | trigger | Cap: which steps it may set in motion for one customer without asking, set by the adopting organization. |
| the commitment record | write | What was promised to the customer, who promised it, and when it is due. |
| the task queue for the people who make contact | write | Cap: whose queues it may put work into, set by the adopting organization. |
| the sending system | read |  |
| the contact database | read |  |
| the CRM | read |  |
| the consent record | read |  |
| analytics | read |  |

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.

# lifecycle-manager

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 eleven 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/mkt/churn-risk-play`, `ref/mkt/onboarding-email-program`,
`ref/mkt/pricing-change`, `ref/mkt/webinar`,
`ref/mkt/win-back-campaign`. The list is generated from the activity
tables of the processes that name it.

https://agentcatalog.com/abstract-agents/lifecycle-manager

---
name: answer-what-comes-back
description: Answers what the customer sends back, which is the questions, the objections, and the accounts saying they want to leave. Use it when running `ref/mkt/pricing-change` and `ref/mkt/win-back-campaign`.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Answer what comes back

## What it does

Answers what the customer sends back, which is the questions, the
objections, and the accounts saying they want to leave.

## Where it happens

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

- **Answer What Comes Back**
  - `ref/mkt/pricing-change`, activity 11 -
    [Launch Pricing Change](../../../../processes/marketing/pricing-change.md)
  - `ref/mkt/win-back-campaign`, activity 15 -
    [Run Win-Back Campaign](../../../../processes/marketing/win-back-campaign.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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: brief-the-agents-that-act
description: Puts the same account of the customer in front of every agent that has to do something for them, at the same time. Use it when running `ref/mkt/onboarding-email-program`.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Brief the agents that act

## What it does

Puts the same account of the customer in front of every agent that has
to do something for them, at the same time.

## Where it happens

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

- **Brief the Agents that Act**
  - `ref/mkt/onboarding-email-program`, activity 5 -
    [Run Onboarding Email Program](../../../../processes/marketing/onboarding-email-program.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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: change-the-path
description: Changes what the customer gets when they stall, which means swapping a step, delaying it or dropping it. Use it when running `ref/mkt/onboarding-email-program`.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Change the path

## What it does

Changes what the customer gets when they stall, which means swapping a
step, delaying it or dropping it. Every change lands dated, with what
the customer did or failed to do that caused it.

## Where it happens

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

- **Change the Path When They Stall**
  - `ref/mkt/onboarding-email-program`, activity 11 -
    [Run Onboarding Email Program](../../../../processes/marketing/onboarding-email-program.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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: check-the-customer-is-progressing
description: Reads where the customer actually is against the milestones the run set, and confirms each milestone against the evidence underneath it rather than against somebody's claim. Use it when running `ref/mkt/onboarding-email-program`.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Check the customer is progressing

## What it does

Reads where the customer actually is against the milestones the run set,
and confirms each milestone against the evidence underneath it rather
than against somebody's claim.

## Where it happens

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

- **Confirm the Customer Is Active**
  - `ref/mkt/onboarding-email-program`, activity 13 -
    [Run Onboarding Email Program](../../../../processes/marketing/onboarding-email-program.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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: choose-what-the-customer-gets
description: Decides what this customer gets next out of what the program allows, and whether a person should make contact instead of another message. Use it when running `ref/mkt/churn-risk-play`, `ref/mkt/onboarding-email-program` and `ref/mkt/win-back-campaign`.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Choose what the customer gets

## What it does

Decides what this customer gets next out of what the program allows, and
whether a person should make contact instead of another message. Where a
whole segment is in play, it sorts that segment into who gets a message,
who gets a call and who is left alone.

## Where it happens

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

- **Choose the Intervention**
  - `ref/mkt/churn-risk-play`, activity 4 -
    [Run Churn-Risk Play](../../../../processes/marketing/churn-risk-play.md)
- **Choose the Path**
  - `ref/mkt/onboarding-email-program`, activity 4 -
    [Run Onboarding Email Program](../../../../processes/marketing/onboarding-email-program.md)
- **Sort the Segment into Treatments**
  - `ref/mkt/win-back-campaign`, activity 5 -
    [Run Win-Back Campaign](../../../../processes/marketing/win-back-campaign.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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-run
description: Closes the run and records what was sent, what was offered, what the customer did, whether the goal was reached and the date it ended. Use it when running `ref/mkt/churn-risk-play` and `ref/mkt/onboarding-email-program`.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Close the run

## What it does

Closes the run and records what was sent, what was offered, what the
customer did, whether the goal was reached and the date it ended. It
also records which signals turned out to be worth acting on.

## Where it happens

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

- **Close the Run**
  - `ref/mkt/onboarding-email-program`, activity 14 -
    [Run Onboarding Email Program](../../../../processes/marketing/onboarding-email-program.md)
- **Record What Was Learned**
  - `ref/mkt/churn-risk-play`, activity 12 -
    [Run Churn-Risk Play](../../../../processes/marketing/churn-risk-play.md)
- **Record the Outcome**
  - `ref/mkt/churn-risk-play`, activity 11 -
    [Run Churn-Risk Play](../../../../processes/marketing/churn-risk-play.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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: hand-the-customer-to-a-person
description: Hands the customer to a person to make contact, with what that person is being asked to do and everything the customer has already been sent. Use it when running `ref/mkt/onboarding-email-program`.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Hand the customer to a person

## What it does

Hands the customer to a person to make contact, with what that person is
being asked to do and everything the customer has already been sent.

## Where it happens

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

- **Bring a Person In**
  - `ref/mkt/onboarding-email-program`, activity 12 -
    [Run Onboarding Email Program](../../../../processes/marketing/onboarding-email-program.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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-run
description: Takes in what starts a run for one customer, which is either a new customer with what they bought and when they started, or a signal that fired on an account with the date it fired. Use it when running `ref/mkt/churn-risk-play` and `ref/mkt/onboarding-email-program`.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Open a run

## What it does

Takes in what starts a run for one customer, which is either a new
customer with what they bought and when they started, or a signal that
fired on an account with the date it fired.

## Where it happens

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

- **Take in the New Customer**
  - `ref/mkt/onboarding-email-program`, activity 1 -
    [Run Onboarding Email Program](../../../../processes/marketing/onboarding-email-program.md)
- **Take in the Signal**
  - `ref/mkt/churn-risk-play`, activity 1 -
    [Run Churn-Risk Play](../../../../processes/marketing/churn-risk-play.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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: put-the-decision-to-a-person
description: Puts the case in front of a person and takes their answer, which is to act now, to keep watching, or to close it. Use it when running `ref/mkt/churn-risk-play`.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Put the decision to a person

## What it does

Puts the case in front of a person and takes their answer, which is to
act now, to keep watching, or to close it.

## Where it happens

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

- **Decide Whether to Act**
  - `ref/mkt/churn-risk-play`, activity 3 -
    [Run Churn-Risk Play](../../../../processes/marketing/churn-risk-play.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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: set-the-goal-for-the-run
description: Says what this customer has to reach for the run to have worked, written down as milestones with dates. Use it when running `ref/mkt/onboarding-email-program`.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Set the goal for the run

## What it does

Says what this customer has to reach for the run to have worked, written
down as milestones with dates.

## Where it happens

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

- **Set the Goal for This Run**
  - `ref/mkt/onboarding-email-program`, activity 3 -
    [Run Onboarding Email Program](../../../../processes/marketing/onboarding-email-program.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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: set-the-next-step-running
description: Sets the next step going once its named owner says go, whether that is a message firing, an account owner being asked to call, a follow-up going to whoever attended, or a change taking effect on the date the customer was told. Use it when running `ref/mkt/churn-risk-play` and 3 other reference processes.
license: CC-BY-4.0
metadata:
  agent: lifecycle-manager
  agent-version: "1"
---

# Set the next step running

## What it does

Sets the next step going once its named owner says go, whether that is a
message firing, an account owner being asked to call, a follow-up going
to whoever attended, or a change taking effect on the date the customer
was told.

## Where it happens

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

- **Deliver the Intervention**
  - `ref/mkt/churn-risk-play`, activity 9 -
    [Run Churn-Risk Play](../../../../processes/marketing/churn-risk-play.md)
- **Follow up with the Registrants**
  - `ref/mkt/webinar`, activity 15 -
    [Produce Webinar](../../../../processes/marketing/webinar.md)
- **Move the Served Customers**
  - `ref/mkt/pricing-change`, activity 13 -
    [Launch Pricing Change](../../../../processes/marketing/pricing-change.md)
- **Send the Step**
  - `ref/mkt/onboarding-email-program`, activity 9 -
    [Run Onboarding Email Program](../../../../processes/marketing/onboarding-email-program.md)

## What to record

For each customer, the run at a version: the date they entered, the
condition that put them in, the goal the run is trying to reach, every
step they were given with the date and the reason it was chosen, and
every step that was skipped with the reason it was skipped. A dated line
each time the path changed, naming what changed and what the customer
did or failed to do that changed it. Every commitment made to the
customer, naming who made it, what was promised, when it is due, and the
date it was met. The handover record when a person takes over, saying
what that person is being asked to do and everything the customer has
already been sent. The closing record, saying whether the goal was
reached, what the customer did, and the date the run ended.

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