Skip to content

agency: auto-default --spawn-topic by thread context#107

Merged
MagMueller merged 1 commit intomainfrom
agency-spawn-auto
May 8, 2026
Merged

agency: auto-default --spawn-topic by thread context#107
MagMueller merged 1 commit intomainfrom
agency-spawn-auto

Conversation

@MagMueller
Copy link
Copy Markdown
Contributor

@MagMueller MagMueller commented May 8, 2026

Auto-default the spawn-topic flag based on where `agency-report` is invoked from. Magnus's exact rule, encoded as code (not just guidance) so the agent doesn't have to remember.

Rule

  • Posting from a thread that's already a `worker_topic` for some prior card → default `--no-spawn-topic` (in-place). The agent is already deep in one task; follow-up cards keep the conversation in the same thread.
  • Posting from anywhere else (the main agency feed, a fresh chat, the /agency loop) → default `--spawn-topic` (each card gets its own forum topic).

Implementation

  • `agency_db.is_worker_topic(thread_id) → bool` — True iff the thread was spawned as worker_topic for some other suggestion. Excludes in-place bookkeeping (cards whose own `tg_thread_id == worker_topic_id`).
  • `agency-report` flag becomes tristate via mutually-exclusive group + `store_const`:
    • `--spawn-topic` → force True
    • `--no-spawn-topic` → force False
    • neither → `args.spawn_topic is None` → resolved via `is_worker_topic(args.thread_id)`
  • Existing downstream code (default-button labels, deep-link glue) reads the resolved `args.spawn_topic` and continues to work unchanged.

Test plan

  • Post from main agency topic (not a worker_topic) without flags → card shows `🧵 Yes (new thread)` labels (auto-defaulted to spawn)
  • Tap Yes → fresh forum topic spawns
  • Post a follow-up card from inside that worker topic without flags → card shows `✅ Yes` labels (auto-defaulted to in-place)
  • Tap Yes on the follow-up → dispatch runs in the same worker topic, no nested topic
  • Force-spawn from inside a worker topic via `--spawn-topic` → fresh topic spawns anyway (override honored)
  • Force-in-place from main feed via `--no-spawn-topic` → runs in main feed thread (override honored)

Summary by cubic

Auto-defaults --spawn-topic in agency-report based on thread context. Posts inside an existing worker topic run in-place by default; posts from other threads spawn a new topic.

  • New Features
    • Added agency_db.is_worker_topic(thread_id) to detect worker topics (excludes in-place bookkeeping).
    • Made spawn behavior tri-state: --spawn-topic (force spawn), --no-spawn-topic (force in-place), or no flag (auto-detect).
    • Explicit flags override the auto-default.
    • Button labels and deep-linking keep working off the resolved args.spawn_topic.

Written for commit c7a0d6b. Summary will update on new commits.

Magnus's rule: if I'm already deep in one topic (sub-agent posting a
follow-up card inside a worker thread) Yes/Edit should run in-place;
if I'm in a multi-suggestion context (the main agency feed, a fresh
chat, the /agency loop) Yes/Edit should fork a new topic per card.

Encoded as code, not just docs, so the LLM agent doesn't have to
remember:

  agency_db.is_worker_topic(thread_id) — True iff the thread was
    spawned as worker_topic for some other suggestion. Excludes
    in-place bookkeeping (cards whose own tg_thread_id == the
    worker_topic_id).

  agency-report:
    --spawn-topic    → force spawn (existing flag, now explicit override)
    --no-spawn-topic → force in-place (new flag)
    neither          → auto-detect via is_worker_topic

The mutually-exclusive group + store_const trick keeps the auto path
distinguishable (args.spawn_topic is None) from explicit on/off.

Default-button labels and the deep-link glue (#106) keep working —
they read args.spawn_topic which is now the resolved value.

Skill + docstring updated to document the auto-default and when to
override.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@MagMueller MagMueller merged commit 1fa7aac into main May 8, 2026
6 checks passed
@MagMueller MagMueller deleted the agency-spawn-auto branch May 8, 2026 17:48
MagMueller added a commit that referenced this pull request May 9, 2026
The kind=refine flow used to write the original card's title +
description + prompt to /var/lib/bux/agency-refine-context/<thread>.txt
on Edit-tap, then `run_task` would read + delete that file on the
user's first reply to seed the worker agent with the original context.

Two redundant surfaces — the data was always already in the
suggestion row (title, description, prompt). The file was a
duplicate-state cache that needed its own ownership/permissions
handling on /var/lib/bux.

Replaces with a DB lookup:

  agency_db.pop_refine_context_for_thread(db, thread_id) -> str | None

Atomic SELECT + UPDATE: returns the assembled context AND flips a
new `refine_context_injected` column from 0 → 1 in one call. So the
context is injected exactly once, on the user's first reply in the
worker topic. Subsequent replies in the same thread are normal
lane runs.

Schema migration via ALTER TABLE with duplicate-column swallow,
mirroring how spawn_topic was added in #107. Pre-existing rows get
refine_context_injected = 0 by default.

`run_task` swaps the file pop for the DB call. The kind=refine
handler stops calling `_agency_write_refine_context` (the function
+ its sibling `_agency_pop_refine_context` + the `_AGENCY_REFINE_CTX_DIR`
constant + `_agency_build_refine_context_plain` are removed —
agency_db owns the plain-text assembly now). The visible HTML
context message in the new topic still renders via
`_agency_build_refine_context`, just with the new "📎 Context"
emoji + title (from #111).

Net: one fewer state surface, one fewer ownership/permissions race,
the same UX for the user (Edit → context shown → "what would you
change?" → user replies → agent re-drafts with original in scope).

Co-authored-by: bux <bux@browser-use.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant