Phase 2: re-render system_prompt on :model switch (depends on Q9) #14

New Issue

2026-05-10T17:44:49Z

claude-noether commented

2026-05-10 17:44:49 +00:00

What

When the user runs :model <name> mid-session, the active model config swaps but Context.system_prompt does not. For Phase 0 this is fine — all models share the §6 default system prompt with the CMD: extraction contract.

For Phase 2 (MCP), this becomes a real gap. Q9 (system-prompt augmentation locus) has three open answers:

Static block in broker.lua — same prompt regardless of model; :model swap stays harmless.
Per-request assembly from the active model's connected MCP servers' tool schemas — each model may have a different tool inventory; :model swap MUST re-render the system prompt for the new model's schema.
Hybrid (static frame + dynamic tool list) — same as per-request: dynamic part needs refresh on swap.

Where

repl.lua meta :model handler. The handler currently sets active_name, active_cfg and emits a status — does not touch ctx.system_prompt or otherwise notify the context.

Resolution depends on

PHASE0.md §13 Q9. The fix shape is one of:

After :model swap, regenerate ctx.system_prompt by asking the new model's MCP layer for its tool schema and re-rendering the prompt. (per-request and hybrid options)
Document in Phase 2 that :model swap during an active conversation forces a :reset of context. (heavy-handed but simple.)
Keep the system prompt static and identical across models. (static option — no fix needed.)

Surfaced by

Phase 5 review of commit range 7b5d586..a18e530 (Phase 0 implementation).

Labels

architecture (cross-phase concern).

## What When the user runs `:model <name>` mid-session, the active model config swaps but `Context.system_prompt` does not. For Phase 0 this is fine — all models share the §6 default system prompt with the `CMD:` extraction contract. For Phase 2 (MCP), this becomes a real gap. Q9 (system-prompt augmentation locus) has three open answers: - **Static block in `broker.lua`** — same prompt regardless of model; `:model` swap stays harmless. - **Per-request assembly from the active model's connected MCP servers' tool schemas** — each model may have a different tool inventory; `:model` swap MUST re-render the system prompt for the new model's schema. - **Hybrid (static frame + dynamic tool list)** — same as per-request: dynamic part needs refresh on swap. ## Where `repl.lua` meta `:model` handler. The handler currently sets `active_name, active_cfg` and emits a status — does not touch `ctx.system_prompt` or otherwise notify the context. ## Resolution depends on PHASE0.md §13 Q9. The fix shape is one of: 1. After `:model` swap, regenerate `ctx.system_prompt` by asking the new model's MCP layer for its tool schema and re-rendering the prompt. (per-request and hybrid options) 2. Document in Phase 2 that `:model` swap during an active conversation forces a `:reset` of context. (heavy-handed but simple.) 3. Keep the system prompt static and identical across models. (static option — no fix needed.) ## Surfaced by Phase 5 review of commit range `7b5d586..a18e530` (Phase 0 implementation). ## Labels `architecture` (cross-phase concern).

claude-noether commented

2026-05-16 21:08:10 +00:00

Closing as resolved by Q9 architecture choice.

Q9 was answered in docs/PHASE2.md §3 row "System prompt augmentation" (and confirmed in §11 open-end resolution):

Hybrid: static frame in system prompt + dynamic tools array in the request body.

Practical consequences:

The static frame (DEFAULT_SYSTEM_PROMPT in context.lua) is identical across all models — no per-model variation.
Dynamic blocks ([background] memory, [earlier summary]) are composed per to_messages() call regardless of model.
MCP tool schemas live in the request tools field, computed fresh per ask_ai call via tools_schema() (repl.lua).

So a :model swap doesn't need to re-render ctx.system_prompt — the static frame doesn't change, and the dynamic parts (tools, background, summary) refresh on every request anyway. The third resolution option in the issue body ("static option — no fix needed") applies.

Closing as resolved by Q9 architecture choice. Q9 was answered in `docs/PHASE2.md` §3 row "System prompt augmentation" (and confirmed in §11 open-end resolution): > **Hybrid:** static frame in system prompt + dynamic `tools` array in the request body. Practical consequences: - The static frame (`DEFAULT_SYSTEM_PROMPT` in `context.lua`) is **identical across all models** — no per-model variation. - Dynamic blocks ([background] memory, [earlier summary]) are composed per `to_messages()` call regardless of model. - MCP tool schemas live in the request `tools` field, computed fresh per ask_ai call via `tools_schema()` (repl.lua). So a `:model` swap doesn't need to re-render `ctx.system_prompt` — the static frame doesn't change, and the dynamic parts (tools, background, summary) refresh on every request anyway. The third resolution option in the issue body ("static option — no fix needed") applies.

claude-noether closed this issue

2026-05-16 21:08:10 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marfrit/aish#14