Background
Recurring-job channels (kind:"channel" / origin:"job") are no longer listed in the web sidebar or the mobile home (both now show Messages + Topics only). That left job output delivered into a thread nobody can navigate to.
The first step (PR for branch Sheldenshi/kampala) makes new chat-created jobs bind to the conversation they were created in (the originating Topic, or the main agent chat) instead of minting a dedicated kind:"channel" thread. For a Topic-bound job the existing Topic→Chat activity mirror surfaces each fire in the parent Chat automatically, so forwardToChat is left unset (no double-post). Verified end-to-end in the webapp: topic-bound fires land in the topic and mirror once into chat; main-chat-bound (one-shot) fires land once in chat; no new channel sessions; no double-posts.
This issue tracks the remaining job-delivery cleanup that was deliberately left out of that PR.
Follow-ups
-
update_job delivery rebind still mints channels. update_job's deliverTo / rebindJobDelivery (src/jobs/index.ts) can still create a fresh kind:"channel" session on the "channel" path — re-introducing the invisible thread. Remove deliverTo from update_job (or redirect it to a forward-only toggle) and stop minting channels.
-
Legacy jobs + the store migration. Existing jobs (and the one-time src/state/store.ts migration) still bind to dedicated kind:"channel" sessions with forwardToChat. They keep working via finalize.ts's forward path, but they're invisible in the lists. Decide: migrate them onto a Topic, or surface them.
-
Context growth / contamination of topic-bound fires. A topic-bound job fires as mode:"chat" in that topic, so priorChatMessages (src/execution/chat-task.ts) replays the topic's history — including the setup conversation — into every fire under a soft token budget. Over many fires this bloats and the setup turns can steer the agent. Consider running job fires with a trimmed/standalone context rather than full topic replay.
-
Router funnels distinct job requests into one Topic. During testing, an "every 2 minutes, one weird animal fact" request was routed (existing-topic match) into the unrelated "Motivational Quote Reminder" topic, so the job delivers into a mismatched-named thread. Revisit topic routing for job-creation messages (e.g. prefer a fresh topic named for the job).
-
Agent phrasing still says "in its own job channel". Even with the create_job tool description rewritten, the model still confirms job creation with "…in its own job channel." Tune the create_job tool-result string / description (and the one-shot reminder copy) so the agent describes "this conversation / topic," not a channel.
-
Residual "channel" / "Recurring jobs" wording. Sweep remaining references (create_job result suffix, comments, docs, any UI strings) that still imply a separate recurring-jobs channel.
Background
Recurring-job channels (
kind:"channel"/origin:"job") are no longer listed in the web sidebar or the mobile home (both now show Messages + Topics only). That left job output delivered into a thread nobody can navigate to.The first step (PR for branch
Sheldenshi/kampala) makes new chat-created jobs bind to the conversation they were created in (the originating Topic, or the main agent chat) instead of minting a dedicatedkind:"channel"thread. For a Topic-bound job the existing Topic→Chat activity mirror surfaces each fire in the parent Chat automatically, soforwardToChatis left unset (no double-post). Verified end-to-end in the webapp: topic-bound fires land in the topic and mirror once into chat; main-chat-bound (one-shot) fires land once in chat; no new channel sessions; no double-posts.This issue tracks the remaining job-delivery cleanup that was deliberately left out of that PR.
Follow-ups
update_jobdelivery rebind still mints channels.update_job'sdeliverTo/rebindJobDelivery(src/jobs/index.ts) can still create a freshkind:"channel"session on the"channel"path — re-introducing the invisible thread. RemovedeliverTofromupdate_job(or redirect it to a forward-only toggle) and stop minting channels.Legacy jobs + the store migration. Existing jobs (and the one-time
src/state/store.tsmigration) still bind to dedicatedkind:"channel"sessions withforwardToChat. They keep working viafinalize.ts's forward path, but they're invisible in the lists. Decide: migrate them onto a Topic, or surface them.Context growth / contamination of topic-bound fires. A topic-bound job fires as
mode:"chat"in that topic, sopriorChatMessages(src/execution/chat-task.ts) replays the topic's history — including the setup conversation — into every fire under a soft token budget. Over many fires this bloats and the setup turns can steer the agent. Consider running job fires with a trimmed/standalone context rather than full topic replay.Router funnels distinct job requests into one Topic. During testing, an "every 2 minutes, one weird animal fact" request was routed (existing-topic match) into the unrelated "Motivational Quote Reminder" topic, so the job delivers into a mismatched-named thread. Revisit topic routing for job-creation messages (e.g. prefer a fresh topic named for the job).
Agent phrasing still says "in its own job channel". Even with the
create_jobtool description rewritten, the model still confirms job creation with "…in its own job channel." Tune thecreate_jobtool-result string / description (and the one-shot reminder copy) so the agent describes "this conversation / topic," not a channel.Residual "channel" / "Recurring jobs" wording. Sweep remaining references (create_job result suffix, comments, docs, any UI strings) that still imply a separate recurring-jobs channel.