Skip to content

[Feature]: Allow topic/forum cron deliveries to use main-session announce/agent-turn flow instead of forced direct delivery #38573

Description

@wonrax

Summary

Add a config or per-cron option to let topic/forum targets use the same announce → main-agent-turn behavior that currently works in DMs, instead of always forcing direct delivery.

Problem to solve

Right now isolated cron jobs targeting topic/forum chats are forced into direct delivery when the resolved target has a threadId. That means cron output is sent straight to the channel and bypasses the main-session announce/agent-turn path.

This creates a behavior mismatch between DM and group-topic sessions:

• In DMs, isolated cron output can go through the main-session announce path, which lets the main agent rewrite/summarize the result in its own voice and decide what to send.
• In topic/forum sessions, cron delivery is forced to direct-send, so the result bypasses that rewrite/handoff behavior.

This is a problem for users who want:

• isolated execution
• main-agent judgment/rewrite before posting
• consistent behavior across DM and topic/group sessions
continue to chat with the cron output

Current behavior is especially confusing because subagent/announce fixes for group/topic sessions exist, but cron delivery still hardcodes direct delivery for thread/topic targets.

Relevant current code path:
src/cron/isolated-agent/delivery-dispatch.ts

Current logic:

const useDirectDelivery =
params.deliveryPayloadHasStructuredContent || params.resolvedDelivery.threadId != null;

And the comment explicitly says:

Forum/topic targets should also use direct delivery.

That hardcoded branch makes this impossible to configure today without a source patch.

Proposed solution

Add an explicit config or cron-job-level option to control how text-only cron completions are delivered for thread/topic targets.

Possible API shapes:

Option A — per-job cron option:

{
  "delivery": {
    "mode": "announce",
    "channel": "telegram",
    "to": "-1003508166716:topic:1",
    "threadDeliveryMode": "announce-agent-turn"
  }
}

Option B — top-level cron/job option:

{
  "sessionTarget": "isolated",
  "payload": { "kind": "agentTurn", "message": "..." },
  "wakeMode": "now",
  "delivery": {
    "mode": "announce",
    "channel": "telegram",
    "to": "-1003508166716:topic:1"
  },
  "completionRouteMode": "agent-turn"
}

Option C — global config default with per-job override:

{
  "agents": {
  "defaults": {
    "cron": {
      "topicTextDeliveryMode": "direct" | "announce-agent-turn"
      }
    }
  }
}

Desired semantics:

• Keep current direct-send behavior as the default for backward compatibility.
• Allow users to opt in to “announce/main-agent-turn” behavior for topic/forum targets.
• Only apply this to text-only cron completions.
• Structured payloads (media/files/cards/etc.) can still use direct delivery.
• If announce/agent-turn fails, fallback behavior should be explicit and configurable:
• fail closed
• fallback to direct send
• or best-effort

This would make topic/forum cron behavior match DM behavior when users explicitly want that.

Alternatives considered

• Sending cron output to DM instead of the topic: works, but defeats the point of routing the workflow to the group/topic.
• Using a separate helper cron/systemEvent to force a later main-session turn: works as a hack, but adds complexity and timing fragility.
• Hardcoding style instructions into cron prompts: only treats the symptom and does not restore the missing main-agent rewrite/handoff behavior.
• Patching local source: works, but users on trunk/Nix/module setups should not need custom forks for this.

Impact

Affected:
• users running isolated cron jobs to Telegram forum topics / threaded group targets
• likely other channels with thread/topic semantics, not just Telegram

Severity:
• medium to high depending on workflow
• not a total blocker, but it breaks a very useful pattern: “run isolated, then let the main agent decide how to present it”

Frequency:
• always, for topic/forum cron targets under current code

Consequence:
• cron output in topics bypasses main-agent rewrite/judgment
• inconsistent behavior between DM and topic sessions
• more robotic/raw channel output
• users must choose between correct routing and better delivery behavior
• forces ugly workarounds or local patches

Evidence/examples

Observed current code on trunk:

• latest checked main commit still contains:

const useDirectDelivery =
params.deliveryPayloadHasStructuredContent || params.resolvedDelivery.threadId != null;

and the comment:

// Forum/topic targets should also use direct delivery. Announce flow can be swallowed by ANNOUNCE_SKIP/NO_REPLY in the target agent turn, which silently drops cron output for topic-bound sessions.

That explains the current behavior, but it also means there is no config path to opt into DM-like behavior for topic targets.

Additional information

• issue #34160 / follow-up work around group/topic announce-triggered main turns
• cron delivery still appears to have a separate topic-specific direct-delivery override

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.enhancementNew feature or requestimpact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions