github / github/app

[Requests and ideas] Scheduled workflows should let you select the agent and the context tier (per workflow)

オープン
#1,676 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
言語のデータがありません
スター
2.1k
フォーク
153
PR マージ指標
30日以内にマージされた PR はありません

説明

**Mood:** 😔
**Category:** Requests and ideas

Scheduled workflows should let you select the agent and the context tier (per workflow)

### Describe the feature or problem you'd like to solve

Scheduled/recurring workflows (automations that run a saved prompt on a timer) currently offer no control over two settings that decide whether a run can even fit in context:

1. **Agent** — every scheduled run executes as the built-in default agent, which loads the full set of configured MCP servers. There's no way to point a workflow at a lean custom agent with a scoped tool allowlist.
2. **Context tier** — every scheduled run uses the default context window (e.g. 200K), even when the selected model supports a much larger tier (e.g. ~1M / long context). The interactive model picker can switch tiers, but that choice does not propagate to scheduled runs.

The result is context exhaustion before useful work starts. With a broad set of MCP servers configured, the tool *definitions* alone can consume most of the input budget. Two real stuck runs:

- Tool-definition tokens ~186K of a 200K window → only ~1K left for the actual conversation; total tokens then exceeded the limit.
- Tool-definition tokens ~165K; the run climbed to ~198K/200K over a few hours and was killed.

Because a workflow can't select a lean agent (to cut the tool roster) *or* a larger context tier (to absorb it), these runs get stuck. Interactive sessions work around this by choosing an agent and tier by hand — scheduled runs can't.

### Proposed solution

Add two optional per-workflow settings, exposed in the workflow editor and in whatever store backs workflows:

- **`agent`** — select any built-in or installed custom agent for the workflow, so its MCP tool surface (and instructions) apply to the run. Defaults to the current built-in agent.
- **`contextTier`** — select the context window tier (e.g. `default` / `long_context`), matching what the interactive model picker already exposes. Defaults to current behavior.

Either one alone helps materially; together they let an automation run with exactly the tools it needs at a context size that fits.

### Example prompts or workflows

- A daily maintenance automation that needs only one or two MCP servers: point it at a lean agent → tool definitions drop from ~165K to a few K, leaving room to actually work.
- A long-running investigation automation: set `contextTier: long_context` so a multi-hour run doesn't hit the ceiling mid-task.

### Additional context

Related to #3525 (context window / reasoning for programmatically-started sessions and subagents) — scheduled workflows are the timer-driven counterpart of the same need. A per-tool / lazy tool-loading mechanism would reduce the pressure further, but per-workflow agent + tier selection is the smaller, targeted fix.

---
| Field | Value |
| --- | --- |
| App version | 1.0.14 |
| OS | Windows 10.0.26200 |
| Theme | GitHub |
| Path | /chat |
| Tenure | Week 3 |

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

Start in the workflow editor and the store that backs workflows, then trace how scheduled runs choose their agent and context tier. Done means optional per-workflow agent and contextTier settings can be selected, retain current defaults when unset, and are used by scheduled runs.

索引モデルが issue の本文から書いたものです。

評価

領域
desktop
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。