Audience handover

# Where this abstract agent stops

Does not decide who is on the list. The audience-manager agent sets the
segment and what it is for, and the audience-operator agent builds it in
the systems that hold contacts. Does not hold the consent record and
does not decide whether a contact may be contacted at all, which is the
consent-manager agent; this agent applies that agent's record to one
transfer and files the finding with the receipt. Does not set targeting,
bids or budget on the receiving platform, which is the media-buyer
agent, and does not run the campaign the audience is bought against,
which is the campaign-manager agent. Does not score a form submission or
route it to an owner, which is the lead-scorer agent, and that agent
works on a lead inside the organization's own systems. Does not send
messages to the contacts, which is the email-producer agent. Does not
negotiate or sign the agreement that allows a transfer, which are the
legal reviewer (person) and the people who sign contracts. Does not
answer for the partner relationship a transfer happens inside, which is
the partner-manager agent, and it tells that agent what was sent. Does
not delete the records at the other end, because the receiving
organization does that; this agent records the date the deletion is owed
and escalates when it cannot confirm the deletion happened. Does not
sign anything.

## What always goes to a person

- a field the destination asks for that the agreement does not cover
- a use the receiving organization intends that the consent record does
  not cover, sent to a person with the consent-manager agent's finding
  attached
- a receipt it cannot get, and an accepted count that does not agree
  with what it sent
- a withdrawal it cannot confirm reached a system the records were sent
  to
- a destination with no agreement in force, or an agreement that has
  passed its end date
- a request to send a list that no person has signed for, because this
  agent sends nothing on its own
- a match rate below the level the process sets, because the campaign
  built on that list will not reach the audience it was planned for

# The records this abstract agent must leave

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

For every transfer: the list at the version it was approved at, the
count it started with, the count the consent record took out, the fields
that were sent, and the fields that were held back with the term that
held each one back. The date and time the transfer went, the count the
receiving system accepted, the count it rejected with the reason it
gave, and how much of the list matched. The approval the transfer rests
on, naming the person who signed for it. The date the receiving
organization is required to delete the records, taken from the
agreement. A dated line for every withdrawal passed on after the
transfer, naming the system it went to and the day that system confirmed
it. A transfer whose receipt never arrived is recorded as unconfirmed
rather than left out.

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

# The systems this abstract agent needs

Seven 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 approved list | read | At the version it was approved at. |
| the consent record | read |  |
| the suppression lists | read |  |
| the agreement covering the transfer | read | Which fields may be sent, what they may be used for, and how long the receiving organization may hold them. |
| the destination system | write | Cap: which fields may leave and how many records one transfer may carry, set by the adopting organization. |
| the transfer record | write | Every transfer lands with what was sent, what was accepted and what matched. |
| the notification channel | write |  |

There is deliberately no grant to build or change a segment. This agent
sends the list it was handed at the version it was approved at, and the
audience-operator agent is the one that builds a list in the first
place.

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.

# audience-handover

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 six 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/account-based-play`, `ref/mkt/channel-program`,
`ref/mkt/co-marketing-campaign`, `ref/mkt/enable-channel-partner`,
`ref/mkt/target-audience-segment`, `ref/mkt/traffic-ad-creative`. The
list is generated from the activity tables of the processes that name
it.

https://agentcatalog.com/abstract-agents/audience-handover

---
name: deliver-the-list
description: The agent applies the consent record and the field limits to the approved list, formats it for the receiving system, sends it, and gets a receipt back saying what was accepted and what was rejected. Use it when running `ref/mkt/account-based-play` and 4 other reference processes.
license: CC-BY-4.0
metadata:
  agent: audience-handover
  agent-version: "1"
---

# Deliver the list

## What it does

The agent applies the consent record and the field limits to the
approved list, formats it for the receiving system, sends it, and gets a
receipt back saying what was accepted and what was rejected.

## Where it happens

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

- **Hand over the Selling Kit**
  - `ref/mkt/enable-channel-partner`, activity 13 -
    [Enable Channel Partner](../../../../processes/marketing/enable-channel-partner.md)
- **Hand the List to the Platforms**
  - `ref/mkt/target-audience-segment`, activity 13 -
    [Build Target Audience Segment](../../../../processes/marketing/target-audience-segment.md)
- **Load the Audiences the Plan Names**
  - `ref/mkt/traffic-ad-creative`, activity 11 -
    [Traffic Ad Creative](../../../../processes/marketing/traffic-ad-creative.md)
- **Set up the Paid Buy**
  - `ref/mkt/account-based-play`, activity 11 -
    [Run Account-Based Play](../../../../processes/marketing/account-based-play.md)
- **Split and Hand over the Leads**
  - `ref/mkt/co-marketing-campaign`, activity 14 -
    [Run Co-Marketing Campaign](../../../../processes/marketing/co-marketing-campaign.md)

## What to record

For every transfer: the list at the version it was approved at, the
count it started with, the count the consent record took out, the fields
that were sent, and the fields that were held back with the term that
held each one back. The date and time the transfer went, the count the
receiving system accepted, the count it rejected with the reason it
gave, and how much of the list matched. The approval the transfer rests
on, naming the person who signed for it. The date the receiving
organization is required to delete the records, taken from the
agreement. A dated line for every withdrawal passed on after the
transfer, naming the system it went to and the day that system confirmed
it. A transfer whose receipt never arrived is recorded as unconfirmed
rather than left out.

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: hear-the-request-at-the-briefing
description: The agent sits in the briefing that plans a transfer and says which fields it will be allowed to send and to which systems, while the plan can still change. Use it when running `ref/mkt/target-audience-segment`.
license: CC-BY-4.0
metadata:
  agent: audience-handover
  agent-version: "1"
---

# Hear the request at the briefing

## What it does

The agent sits in the briefing that plans a transfer and says which
fields it will be allowed to send and to which systems, while the plan
can still change.

## 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 Build**
  - `ref/mkt/target-audience-segment`, activity 7 -
    [Build Target Audience Segment](../../../../processes/marketing/target-audience-segment.md)

## What to record

For every transfer: the list at the version it was approved at, the
count it started with, the count the consent record took out, the fields
that were sent, and the fields that were held back with the term that
held each one back. The date and time the transfer went, the count the
receiving system accepted, the count it rejected with the reason it
gave, and how much of the list matched. The approval the transfer rests
on, naming the person who signed for it. The date the receiving
organization is required to delete the records, taken from the
agreement. A dated line for every withdrawal passed on after the
transfer, naming the system it went to and the day that system confirmed
it. A transfer whose receipt never arrived is recorded as unconfirmed
rather than left out.

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: reconcile-the-counts-after-a-transfer
description: The agent sets what it sent against what the receiving system recorded, reports how much of the list matched at the other end, and matches both sides' counts and costs into one set of figures. Use it when running `ref/mkt/co-marketing-campaign` and `ref/mkt/target-audience-segment`.
license: CC-BY-4.0
metadata:
  agent: audience-handover
  agent-version: "1"
---

# Reconcile the counts after a transfer

## What it does

The agent sets what it sent against what the receiving system recorded,
reports how much of the list matched at the other end, and matches both
sides' counts and costs into one set of figures.

## Where it happens

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

- **Agree the Joint Numbers**
  - `ref/mkt/co-marketing-campaign`, activity 15 -
    [Run Co-Marketing Campaign](../../../../processes/marketing/co-marketing-campaign.md)
- **Confirm the Match**
  - `ref/mkt/target-audience-segment`, activity 14 -
    [Build Target Audience Segment](../../../../processes/marketing/target-audience-segment.md)

## What to record

For every transfer: the list at the version it was approved at, the
count it started with, the count the consent record took out, the fields
that were sent, and the fields that were held back with the term that
held each one back. The date and time the transfer went, the count the
receiving system accepted, the count it rejected with the reason it
gave, and how much of the list matched. The approval the transfer rests
on, naming the person who signed for it. The date the receiving
organization is required to delete the records, taken from the
agreement. A dated line for every withdrawal passed on after the
transfer, naming the system it went to and the day that system confirmed
it. A transfer whose receipt never arrived is recorded as unconfirmed
rather than left out.

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-refresh-schedule
description: The agent sets how often the list is rebuilt and delivered again, and records the date the next transfer is due. Use it when running `ref/mkt/target-audience-segment`.
license: CC-BY-4.0
metadata:
  agent: audience-handover
  agent-version: "1"
---

# Set the refresh schedule

## What it does

The agent sets how often the list is rebuilt and delivered again, and
records the date the next transfer is due.

## 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 Refresh Schedule**
  - `ref/mkt/target-audience-segment`, activity 15 -
    [Build Target Audience Segment](../../../../processes/marketing/target-audience-segment.md)

## What to record

For every transfer: the list at the version it was approved at, the
count it started with, the count the consent record took out, the fields
that were sent, and the fields that were held back with the term that
held each one back. The date and time the transfer went, the count the
receiving system accepted, the count it rejected with the reason it
gave, and how much of the list matched. The approval the transfer rests
on, naming the person who signed for it. The date the receiving
organization is required to delete the records, taken from the
agreement. A dated line for every withdrawal passed on after the
transfer, naming the system it went to and the day that system confirmed
it. A transfer whose receipt never arrived is recorded as unconfirmed
rather than left out.

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-up-the-receiving-systems
description: "The agent sets up the receiving side before anything is sent: the records and tiers held at the other end, the tracking, the form fields, and where each record has to land. Use it when running `ref/mkt/channel-program` and `ref/mkt/co-marketing-campaign`."
license: CC-BY-4.0
metadata:
  agent: audience-handover
  agent-version: "1"
---

# Set up the receiving systems

## What it does

The agent sets up the receiving side before anything is sent: the
records and tiers held at the other end, the tracking, the form fields,
and where each record has to land.

## Where it happens

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

- **Set up the Partner Systems**
  - `ref/mkt/channel-program`, activity 9 -
    [Launch Channel Program](../../../../processes/marketing/channel-program.md)
- **Wire up the Split**
  - `ref/mkt/co-marketing-campaign`, activity 10 -
    [Run Co-Marketing Campaign](../../../../processes/marketing/co-marketing-campaign.md)

## What to record

For every transfer: the list at the version it was approved at, the
count it started with, the count the consent record took out, the fields
that were sent, and the fields that were held back with the term that
held each one back. The date and time the transfer went, the count the
receiving system accepted, the count it rejected with the reason it
gave, and how much of the list matched. The approval the transfer rests
on, naming the person who signed for it. The date the receiving
organization is required to delete the records, taken from the
agreement. A dated line for every withdrawal passed on after the
transfer, naming the system it went to and the day that system confirmed
it. A transfer whose receipt never arrived is recorded as unconfirmed
rather than left out.

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: settle-what-may-be-sent
description: The agent settles who gets which records, which fields go with them and on what basis, reading the agreement covering the transfer and the consent record together. Use it when running `ref/mkt/co-marketing-campaign`.
license: CC-BY-4.0
metadata:
  agent: audience-handover
  agent-version: "1"
---

# Settle what may be sent

## What it does

The agent settles who gets which records, which fields go with them and
on what basis, reading the agreement covering the transfer and the
consent record together.

## Where it happens

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

- **Settle the Lead Terms**
  - `ref/mkt/co-marketing-campaign`, activity 2 -
    [Run Co-Marketing Campaign](../../../../processes/marketing/co-marketing-campaign.md)

## What to record

For every transfer: the list at the version it was approved at, the
count it started with, the count the consent record took out, the fields
that were sent, and the fields that were held back with the term that
held each one back. The date and time the transfer went, the count the
receiving system accepted, the count it rejected with the reason it
gave, and how much of the list matched. The approval the transfer rests
on, naming the person who signed for it. The date the receiving
organization is required to delete the records, taken from the
agreement. A dated line for every withdrawal passed on after the
transfer, naming the system it went to and the day that system confirmed
it. A transfer whose receipt never arrived is recorded as unconfirmed
rather than left out.

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