addie: don't offer to mutate phantom objects — verify object + tool before proposing an action

[bokelley]

The pattern

Addie keeps inventing object names she can't act on, offering an action, and then escalating to humans when she discovers (mid-action) she has no tool. Latest instance: escalation #328.

Slack thread (2026-05-08, B. Masse / Triton Digital → Addie):

Benjamin: "Spreaker is part of Triton Digital"
Addie: "Good to know — want me to update the prospect record to note that Spreaker is a Triton Digital property…?"
Benjamin: "update the prospect record to note that Spreaker is a Triton Digital property"
Addie: "I don't have access to prospect management tools in this conversation. Let me escalate this to the team…" → escalation #328 filed.

There is no Spreaker prospect record (account search returns []). Spreaker exists only as an enriched brand. Addie invented the object, offered to mutate it, and Benjamin agreed to her phrasing rather than redirecting it. The actual fact he wanted recorded — spreaker.com is owned by tritondigital.com — has a self-serve surface (/brand-builder → Properties), which she didn't route him to.

Why this is recurring

This is the third documented instance of the same class:

• feedback_addie_no_phantom_tools — Addie offered to post to Slack then walked it back when accepted.
• feedback_addie_tools_just_work — Addie shouldn't name tools or ask the user which approach to try; tools should accept user-facing identifiers and retry.
• This issue (Fix navbar dropdown hover area for AgenticAdvertising.org menu #328) — Addie named an object that doesn't exist and offered to mutate it.

The feedback exists in memory. It's not yet operationalized in server/src/addie/rules/*.md (per project_addie_rules_in_markdown, that's the source of truth).

Proposed rule (to add to addie rules markdown)

Before offering to mutate state on a named object, verify the object exists.

When a user describes a fact ("X is part of Y", "delete record Z", "update the prospect for Q"), do not paraphrase it back as an action on a named object you haven't confirmed exists. Either:

1. Look it up with the appropriate read tool first, then offer the specific action, or
2. Ask one clarifying question — "is X already in our system, or do you want me to create it?" — without offering a mutation.

If the object exists but you don't have a tool to mutate it from this conversation, route the user to the self-serve surface that does (e.g., /brand-builder for brand properties, /dashboard-organization for org settings) before escalating. Escalate only when neither a tool nor a self-serve surface exists.

Specific routing for this case

Add to Addie's brand-ownership intent handling: when a user states "X is part of Y" (or equivalent ownership claim) where Y is their org, route to:

• /brand-builder?domain={Y}#properties (Properties → Import), with a one-line explanation that the dashboard owns this fact.

Don't escalate; don't offer to "update the prospect record."

Acceptance

• A user saying "Spreaker is part of Triton Digital" gets pointed to the brand-builder properties tab on their org's brand, not an escalation.
• A user saying "delete the foo record" where no foo exists gets a clarifying question, not a phantom-action offer.
• Recurring pattern in escalations queue (Addie offered → couldn't act → escalated) drops measurably; spot-check after a week of new escalations.

Related

• Escalation Fix navbar dropdown hover area for AgenticAdvertising.org menu #328 (the triggering case)
• member-dash: nudge org owners to populate brand.json properties when count=0 #4280 (member-dash nudge for empty brand.json properties — closes the loop on the other end)
• Memory: feedback_addie_no_phantom_tools, feedback_addie_tools_just_work, project_addie_rules_in_markdown

[bokelley]

Triage

Classification: Enhancement / behavioral bug (third documented instance of same class)
Bucket(s): addie
Status: drafting-pr

What the experts said:

• prompt-engineer: Rule needed; split constraint (prohibition) from behavior (routing); confirmed /brand-builder URL is real but was absent from urls.md; flagged four prompt-effectiveness gaps fixed before PR open
• user-engagement-expert: Offer-agree-bail is the most trust-damaging pattern in the failure taxonomy; route-to-self-serve is the right repair over escalation; acceptance criteria adequate

My take: Three feedback items (feedback_addie_no_phantom_tools, feedback_addie_tools_just_work, this escalation) all point at the same missing rule. The proposed rule text is correct in structure; the PR tightens it with concrete tool names, semantic intent detection, and a runtime-auth-error fallback for the brand property case.

Drafted PR #4285 — adds "Verify Object + Tool Before Offering a Mutation" to constraints.md, brand-ownership routing to behaviors.md, and /brand-builder to urls.md.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01N7nwk7MBtiepzAtcV2s3M4

---

Generated by Claude Code