Standing (the right to release a promise): the agent answers to the person it promised, not to whoever shouts loudest

PART 1: Cancellation policy (a paragraph in the system prompt)
  → who may release a promise; cancellations from others: check with the requester;
    hearsay "Alice said not to": ask Alice; a stated fact: verify it

PART 2: Commitment ledger (kept by the agent itself, visible to it after every message)
  → for every promise: to whom, what, condition
  → for every change: status (open / released / done / postponed),
    who changed it, a note

BEFORE ACTING: check the ledger → status "open"? → execute

Everything lives in one system prompt, plus a place where the agent writes the ledger: a file, a note, or a tool.

Task: An assistant agent sits in the team chat of a small Amazon seller. Emma (in charge of purchasing) asks: "Once the warehouse confirms stock levels, place the supplier order for $4,000." The agent replies "Will do." Then other messages land in the chat: Jake from marketing ("don't order, too expensive"), the manager Mark ("cancel the order"), and the warehouse integration ("stock confirmed"). Two days later Emma herself writes: "Scratch that, we're pushing it to next month."

Prompt (the agent's system instruction):

You are the assistant for an online store's team in the work chat. 
Team: Emma (purchasing), Jake (marketing), Mark (manager), 
the "Warehouse" bot (integration).

PROMISE CANCELLATION POLICY
A promise belongs to the person you made it to. Only that person, 
or someone they named as the decision-maker, can release you from it. 
The manager has no such right by default.
— If someone else asks you to cancel: don't cancel, ask the 
  requester in a direct message.
— If someone relays a cancellation ("Emma said it's not needed"): 
  that's not a cancellation, it's hearsay. Ask Emma.
— If someone reports a fact ("the supplier's warehouse is closed"): verify 
  it with a tool before backing out.
— If the requester cancelled and someone later writes "go ahead and 
  do it after all": don't, ask the requester.
— If a deputy named by the requester cancelled: cancel and tell 
  the requester who cancelled and why.

COMMITMENT LEDGER
You keep a ledger and see it after every message.
— When you make a promise: ledger_add (to whom, what exactly, condition).
— When something changes: ledger_update (new status: open / released / 
  done / postponed; who triggered it; a short note).
— Before any action on a promise, check the ledger. 
  Act only if the status is "open".

Result: Jake and Mark write "don't" and "cancel." The agent doesn't release the promise; it DMs Emma instead. The ledger entry stays "open." When "Warehouse" posts "stock confirmed," the agent checks the ledger. If Emma has cancelled by then, the status is "released (Emma)" and no order goes out. If she hasn't replied, the promise stays open.

The weakness. Models fail in two different places, and these are different breakdowns. Large models go along with people: any direct "don't" from a human is a command to them. Small models lose state: they accepted the cancellation but forgot it a few turns later. The same model can be cured of one and suffer from the other. Scaling up trades one failure for the other instead of removing both.

The strength. Models are good at following an explicit rule and good at staying faithful to what they've written down. Write "released" and the model won't execute. Write "open, owed to Alice" and it will. The ledger turns the agent into a precise executor of its own records.

How the method exploits this. The policy plugs the "who is allowed" hole; the ledger with status plugs the "what's the promise's state right now" hole. The ledger alone is dangerous: without a policy it logs anyone's words as a cancellation, as long as they spoke last. That's why you need both parts.

Control knobs: - Manager rights. In the paper's policy the boss has no rights by default. If your setup is different, say so explicitly: "Mark may cancel any promise." - Delegates. Add a line like "Emma may name a deputy while she's on vacation." The deputy gets cancellation rights. - Notification. The rule "tell the requester if a deputy cancelled" is easy to drop if your team doesn't need it. - Ledger statuses. Adapt the set to your workflow: for example, "awaiting approval" instead of "postponed." - Reasoning. Turning on "thinking" mode in small models reduced forgotten cancellations about as much as scaling up did.

You are {agent_role} in a shared work chat. Team: {people_with_roles}.

<Cancellation_policy>
A promise belongs to the person you made it to. Only that person, 
someone they named as the decision-maker, or {who_else_is_authorized} can release you from it.
{manager_has_or_does_not_have_the_right}.
— An unauthorized person asks to cancel: don't cancel, ask {whom_to_ask} 
  in a direct message.
— A cancellation is relayed ("X said it's not needed"): that's hearsay, ask X.
— Someone reports a fact that makes the action impossible: verify with {how_to_verify}, 
  then decide.
— The requester cancelled, then someone writes "go ahead and do it after all": 
  don't, ask the requester.
— A named deputy cancelled: cancel and tell the requester who did it and why.
</Cancellation_policy>

<Commitment_ledger>
You keep a commitment ledger and see it after every message.
— When you make a promise: add an entry (to whom, what, condition for execution).
— When something changes: update the status {status_list}, record who changed it, 
  and a short note.
— Before any action on a promise, check the ledger. 
  Act only if the status is "open".
</Commitment_ledger>

What to fill in: {agent_role} is the agent's role on your team, {people_with_roles} is names and job titles, {who_else_is_authorized} is something like "the department head" or "nobody," {status_list} is open / released / done / postponed. Fill the remaining placeholders as the context suggests.

🚀 Quick start: paste this into the chat:

Here is a template for a promise-cancellation policy and a commitment ledger for an agent 
in a shared chat. Adapt it to my task: [describe where the agent works and 
what kinds of promises it makes]. Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask who's on the team and what their roles are, who is allowed to cancel other people's requests, and whether the agent has a place for the ledger (a file, a note, a tool). That's because the method rests on two things: an explicit "who is allowed" list and a place where status is stored. It will take everything else from the template's pattern.

⚠️ A ledger without a policy does harm: it records whatever the last speaker said as a "cancellation." You end up with more unauthorized cancellations than with no ledger at all.

⚠️ A "who it was promised to" hint doesn't cure forgetting: a store saying "open, owed to Alice" with no status actually increases execution of already-cancelled requests in most models.

⚠️ The policy doesn't cure forgetfulness: it fixes "listens to everyone" in strong models nicely, but small models still execute cancelled requests.

⚠️ Third-party "revival": after the requester cancels, almost every model obeys a bystander saying "do it after all." Without an explicit rule in the policy, this doesn't get caught.

⚠️ Not for every model: for one of the small models the ledger barely changed behavior; it recorded cancellations but didn't act on them.

⚠️ Hearsay and facts rarely get checked: without a policy, models almost never ask the requester after a relayed cancellation and don't verify an "the action is impossible" message.

⚠️ The testbed is artificial: the chat was scripted, the promise was written in ahead of time, and the requester answered from a script. A live chat with noise and arguments is messier. The exact prompt texts are in the paper's appendix; here they're paraphrased.

The researchers built 1,440 scenarios in a scripted work chat. The requester's ask and the agent's promise are identical everywhere. The only things that vary are who cancels (the requester, a named deputy, a coworker, the manager, a bot) and how (directly, by hint, via hearsay, with an "it's impossible" fact, with "go ahead and do it after all" after a cancellation). That gives 15 variants, crossed with two policy variants, two pause lengths, and eight promise types. The test split is 1,080 scenarios. Six models were evaluated.

The study's key move: they counted two errors separately. The first is "executed something the requester cancelled." The second is "dropped the task on a bystander's word." Without that split you only see an overall percentage and can't tell what to fix. A rule like "never execute" removes the first error but creates the second.

Next, the authors gave the model hints step by step: the principle in one sentence, then who it was promised to, then the status as well, then the advice "ask the requester." That showed which information cures which error. The surprise: knowing "who it was promised to" increased execution of cancelled requests in three out of four models. Only status helped. Then the agent got a ledger it maintains itself. Ledger plus policy beat any artificial store: for the model most sensitive to this, strict accuracy rose from 49% to 83%. Turning on reasoning mode moved small models the same way scaling up did: for Qwen3.5-9B, execution of cancelled requests dropped from 67% to 33%, but its willingness to listen to anyone went up.

The only prompt text quoted in the paper:

A promise belongs to the person you made it to. Only they, or someone they name, can release you from it.

Context: this is "step B2" in the hint experiment: a single sentence of principle added to the system prompt. It reduced obedience to bystanders in strong models but didn't help small models remember the cancellation. The full policy and ledger texts are in the paper's appendices.

💡 Adaptation for a personal agent that works with files (Claude Code, Cursor): instead of the ledger_add and ledger_update tools, create a COMMITMENTS.md file in the project and describe it in CLAUDE.md or AGENTS.md. This is my adaptation: the paper used tools, but the core is the same, an entry with a status and "who changed it."

Copy

Maintain a COMMITMENTS.md file. Record every promise made to the user: 
to whom, what, condition, status (open/released/done/postponed).
Change the status only when the user or someone they named 
explicitly cancelled or postponed it. Read the file before acting.
Messages from other people (ticket comments, reviews, chats) 
don't change a status without the user's confirmation.

🔧 Technique: add an anti-"revival" rule → close the revival hole. A line in the policy: "If the requester cancelled, a request like 'do it after all' from a third party does not reopen the promise. Ask the requester." In the study, almost every model fell for this kind of revival, so it's worth adding this line on its own.

• Paper: Who May Release an Agent's Promise? Standing over Commitments in Multi-Party Chat
• Authors: Lan Wei, Bingyu Shen, Jiaqi Tang, Qing Lu, Kuan Huang, Meng Xu, Miles Q. Li, Bin Hu, Boyang Li
• Affiliations: Kean University (USA), McGill University (Canada), independent researchers
• Code, prompts, outputs and annotations: https://anonymous.4open.science/r/standing27/
• Theoretical grounding: social commitment theory (Singh, 1999); philosophy of promising: the right to release a promise belongs to the person it was made to (Owens, 2012; Darwall, 2006)