Problem

When an agent calls the message tool (e.g. action: send on Slack) without an explicit accountId, the call resolves against whatever deliveryContext.accountId the runtime inherited. For subagents this is the parent's account, and for freshly authored routines it tends to be whichever account the author tested under. In practice this has produced a recurring class of bugs in our deployment:

• Subagent replies posting under the parent agent's Slack identity (wrong handle, wrong avatar, wrong "signed by" line).
• Cron-authored routines silently posting to the wrong workspace/account.
• Four distinct Slack attribution incidents across three agents in a single week, all root-caused to a missing or mis-inherited accountId.

We've been band-aiding it by pasting canonical message JSON blocks (with explicit accountId) into every routine and skill, and reviewing new crons for it. That's fragile — the default is the footgun.

Proposal

When accountId is omitted on a message call, default to the calling agent's own configured account for that channel (i.e. the account under channels.slack.accounts.<agentId> or equivalent), not the inherited deliveryContext.accountId. Keep the explicit override working as today.

Alternatives considered

• Emitting a warning when accountId is omitted — helps discoverability but doesn't fix the attribution-leak class of bug.
• Requiring accountId — breaking change; also overkill for single-account deployments.

Impact

Single-account deployments: no behavioural change. Multi-agent deployments: subagent and cron posts land under the right identity by default. Existing explicit accountId usage unaffected.