Reduce repeated full-context injection for agent turns

[YusufLisawi]

Describe the bug

The Buzz ACP harness appears to inject the full Buzz base instructions, workspace/AGENTS guidance, and broad skill catalog into every agent turn, including simple follow-up messages. The ChatGPT context view shows thousands of repeated tokens per event.

This makes each turn unnecessarily heavy and can increase input cost, latency, and active-context pressure. It also risks reduced prompt-cache effectiveness when dynamic context is interleaved with the repeated static material.

Steps to reproduce

1. Start an agent session in a Buzz channel.
2. Send several short follow-up messages.
3. Open the associated agent context view in the ChatGPT app.
4. Inspect the context attached to each turn.
5. Observe that the full Buzz guide/instructions are injected repeatedly, rather than only the minimal relevant runtime context.

Expected behavior

Use a small, stable runtime prefix plus only the event/thread context required for the turn. Discover/load skills and detailed guides on demand instead of injecting a broad catalog and full operational guidance into every request. Keep stable content before dynamic content to preserve cache locality.

Actual behavior

Each turn appears to carry thousands of tokens of repeated Buzz guidance and instructions, even for lightweight interactions.

Version and platform

• Buzz version: unknown
• OS: macOS (exact version unknown)

Logs / additional context

This report is based on the agent context view in the ChatGPT app. No API token-usage or prompt-cache telemetry was available to confirm cache-hit rates, so the cost/cache impact is an observed risk rather than a measured value.

Suggested telemetry: input tokens, cached input tokens, cache-write tokens, output tokens, and prompt-compaction rate per turn.

[songshikang0111]

Additional Codex ACP evidence and implementation direction

I captured one session/prompt produced by Buzz for a local Codex agent. The JSON payload was 14,996 bytes and contained five text blocks:

• [Base]
• [System]
• [Agent Memory — core]
• [Context]
• [Buzz event]

No private channel/user/event identifiers are needed to reproduce the structural problem. Under ACP v1, session/prompt.params.prompt is the user message, so [System] is only a textual label in that payload; it is not delivered with system/developer precedence.

This matches Buzz's current compatibility path:

• queue.rs::format_prompt omits Base/System from the turn only when the negotiated protocol supports session-level system prompts.
• pool.rs::has_system_prompt_support and session_new_system_prompt use the session-level path for protocol v2, while legacy v1 gets the static material prepended again.
• The current Codex ACP compatibility path negotiates ACP v1, so it takes the repeated user-message path.

Suggested staged fix

1. Classify prompt material by lifetime. Treat Buzz Base, channel System/persona, and workspace guidance as session-static. Keep Context, Buzz event, reply target, and changed memory/canvas data turn-dynamic.
2. Negotiate persistent-instruction support at session creation. ACP v1 has no standard system-prompt field on session/new, so this should be an explicit Buzz/adapter capability or namespaced extension, not an assumed standard field.
3. Translate that capability in each adapter. For Codex, map the static Buzz instructions to Codex app-server's thread/start.developerInstructions (or the equivalent developer_instructions session config). Prefer additive developer instructions; do not replace Codex's built-in base instructions.
4. Retain today's per-turn injection only as a fallback for agents that do not acknowledge persistent instructions.
5. Handle compaction/session rotation explicitly. Reinstall static instructions when a new underlying thread/session is created, or when the adapter reports that persistent instructions were lost. This preserves the safety motivation behind the legacy reinjection behavior.
6. Add regression tests and telemetry. Record negotiated protocol/capability plus total, static, and dynamic prompt bytes. Test that capable sessions receive static instructions once, subsequent turns exclude them, and legacy sessions still receive the fallback.

The intended split would be approximately:

session creation: Base + System + workspace guidance
session/prompt:   Context + Buzz event + changed memory/canvas only

This is not a claim that the underlying model will never see the static instructions again—the adapter/runtime may retain, resend, or cache them internally. The concrete wins are eliminating repeated Buzz-owned user-message content, restoring the correct instruction authority for [System], and making the behavior measurable.

[PavelTajdus]

Additional evidence: repeated dynamic thread context

Moving Base/System to session creation will remove the largest static duplication, but the dynamic [Context] block can still resend an almost complete thread on every short follow-up.

In one real multi-turn Buzz session, one-line operational messages repeatedly carried 13 prior messages that were already present in the underlying ACP conversation. After the main task was complete, subsequent turns continued to resend detailed merge, test, and cleanup history. No private channel, user, or event identifiers are needed to reproduce this behavior.

Consider tracking which thread events have already been delivered to the underlying session:

• Normal turns: send only the triggering event, reply metadata, and newly added thread events.
• Compaction or session rotation: reinstall a compact thread summary plus any still-relevant open state, rather than replaying the full raw thread.
• Updated workspace guidance: deliver the changed guidance once with explicit replacement semantics, instead of leaving several full versions in active conversation history.

This is separate from the static Base/System fix: without thread-context deduplication, prompt size can continue growing with the conversation even after session-static instructions are handled correctly.