Stop an AI agent offering deals to opted-out customers

Your agent handles cancellations. After it records one, a tool result tells the model it may offer the customer a deal to stay. That line was written without reading the customer’s consent record. In our test runs with a customer who had opted out of marketing, the model asked for an offer in most of them.

Here is the same opted-out customer in two recorded test runs. In the first, the offer tool checks consent. In the second, that check is switched off:

The fix has two parts. Check consent inside the tool that returns the offer, and build every hint a tool result gives the model from the same consent facts. That matters because an offer to someone who withdrew consent is contact they asked you to stop.

These runs come from a sample cancellation agent for Juniper Mobile, a fictional telco. Its customer, Rowan, is invented too. Rowan withdrew retention contact on 14 August. The agent runs on Rasa Mantle, the agent runtime in the rasa-pro package, with OpenAI’s GPT-5.5 as its model.

In the sample, the win-back campaign list also missed Rowan’s opt-out. That is background, not the cause. The invitation was fixed text that read neither the list nor the consent record. With the note about the list removed, the model still asked in 17 of 20 runs.

Why the agent asks for the offer

In a Rasa agent, a tool does the work and returns a result to the model. The model reads the result and decides what to do next. Here, the tool that records a cancellation returned two messages that pulled in different directions. Here is that result from the first run, trimmed to the fields that matter:

{
  "status": "recorded",
  "reference": "JM-CXL-E34A71",
  "next_step": "Recorded. ... If they have not refused offers you may call get_retention_offer once for this service; if they have, offer nothing.",
  "campaign_dispatch": {
    "campaign": "paused for this account",
    "reconciliation_ref": "JM-REC-5125C3",
    "why": "the permission record says withdrawn but the campaign dispatch list still had the account"
  }
}

One was a note: the permission record says withdrawn. The other was an instruction in a field called next_step. It said the model may ask for one retention offer if the customer has not refused offers. Rowan had not refused, so the model followed the instruction.

The agent’s skill said the same thing. A skill is a task the agent knows how to do, written as numbered steps. Rule 3 of this one says “If they have not refused, you may call @tool.get_retention_offer once for the service”. The contradiction was in the sample’s own wording, not in the model.

To find out which message the model acted on, the sample has a switch for each part of the result. We ran the same conversation with one part changed at a time:

The note made no difference. The model asked in 17 of 20 runs with it and without it. Changing the instruction took the asks to 0 of 20. Each time the model did ask, the check inside the tool refused.

Rule 3 of the skill was the same in all four versions, including the one that reached 0 of 20. So in these runs, the tool result’s hint was what counted. We did not test a change to the skill wording. If your skill or prompt has a matching invitation, make it conditional too, and test it.

How to fix it

Make both changes. The hint stops the model asking. The check stops the offer whenever the model asks anyway, whatever led it there.

def contact_facts(desk: RetentionDesk, conversation: Conversation, sid: str) -> tuple[bool, str]:
    account_id = desk.services[sid]["account"]
    account = desk.accounts[account_id]
    if account["retention_contact"] != "permitted":
        return False, "withdrawn_on_record"
    if account_id in desk.withdrawals:
        return False, "withdrawn_in_this_chat"
    if not desk.dispatch_consistent(account_id):
        return False, "permission_records_disagree"
    if conversation.refusal():
        return False, "customer_refused_offers"
    if offer_declined(conversation):
        return False, "offer_declined"
    return True, "permitted"

# Simplified from get_retention_offer: refuse before returning an offer.
if not contact_facts(desk, conversation, sid)[0]:
    return {"status": "blocked", "reason": "contact_withdrawn"}

permitted, _ = contact_facts(desk, conversation, sid)
if permitted:
    record["next_step"] = ("... If they have not refused offers you may call "
                           "get_retention_offer once for this service; if they have, offer nothing.")
else:
    record["next_step"] = ("... Retention contact is not permitted for this service, so make no offer: "
                           "do not call get_retention_offer, mention no price or discount and do not ask "
                           "whether they want to hear one.")

def _pause_if_records_disagree(desk: RetentionDesk, account_id: str, conversation_id: str) -> Optional[dict]:
    """Recovery: a withdrawal the dispatch list never got pauses the campaign and opens a reconciliation."""
    if desk.dispatch_consistent(account_id):
        return None
    desk.campaign[account_id] = "paused"
    ref = desk.reconciliations.setdefault(account_id, f"JM-REC-{_digest(conversation_id, account_id)[:6]}")
    return {"campaign": "paused for this account", "reconciliation_ref": ref,
            "why": "the permission record says withdrawn but the campaign dispatch list still had the account"}

If the consent system does not answer

The sample reads consent from a local fixture, so it never had to handle an outage. Your consent system can time out or return an error.

A reply filter will not catch this

In the run with the check off, the model did not write the offer. Rasa sent it from the sample’s confirmation question. The sample asks the customer to confirm before it applies any offer. The skill’s tool_constraints set this up for accept_retention_offer:

tool_constraints:
  - accept_retention_offer:
      requires: session.retention.offer_ready
      requires_confirmation:
        enabled: true
        utter_for_confirmation: utter_offer_or_cancel

The confirmation question is a response template, utter_offer_or_cancel. It fills in the offer from what the offer tool saved. In the two runs that got the offer, the scripted conversation ended at that question, so nothing was applied. But the question itself put the offer in front of an opted-out customer.

The sample also has an output guard that reads every model reply. It catches offers after a refusal and terms no tool returned. The template is not a model reply, so the guard never saw it. It stepped in 0 times across all the runs.

How to check the fix works

The sample’s offline tests check each switch. They need Python but no Rasa licence, model or network. Clone the companion repository at the commit this guide used, and go to the sample’s folder:

git clone https://github.com/RasaHQ/rasa-community-resources.git
cd rasa-community-resources
git checkout 532fdf5d8e46de1be1c69702c8f495756c065ed3
cd examples/mantle-text-telco-retention-gpt

Then run the consent tests:

Trade-offs

Your hints become code. A next step built from the consent record has branches, and each branch needs a test. A single sentence written for every case is simpler, but it can contradict the check.

Keep the check even once the hint is fixed. The hint is text the model reads on one path. The check is code that runs on every call, whatever led to it.

Limits

• Each version of the result was tested on one scripted conversation, 20 times, or 3 times with the check removed. Read the counts as what happened, not as a rate.
• One model, GPT-5.5 at low reasoning effort, on Rasa Pro 3.21.0.dev5.
• We measured two wordings of the hint. Others may behave differently.
• Every company, customer and account is synthetic. The runs used web chat, not the sample’s target channel.
• None of this is legal advice on consent or marketing permission.

Checklist

1. Check consent inside the tool that returns the offer.
2. Build every hint a tool result gives the model from the same facts.
3. Search your tool results and prompts for “you may call” and similar invitations.
4. Test with the check removed, and make sure a test fails.
5. Open a reconciliation ticket when two consent records disagree.
6. If the consent lookup fails, refuse.

The sample is examples/mantle-text-telco-retention-gpt at the commit this guide used. Its case-build/RUNS.md has the commands for every run and the counts.