Summary

This is a design clarification request before proposing a larger AGY continuity patch.

The current AGY adapter intentionally behaves as a stateless print bridge:

1. each main turn starts a new agy -p <prompt> process;
2. native AGY resume is excluded by providerSupportsResume = cli !== 'agy';
3. cli-jaw reconstructs continuity by prepending DB-backed recent history (currently bounded to 8,000 characters);
4. the changing task/history block is currently placed before the operational/system context.

This behavior is explicit in src/agent/spawn.ts and src/agent/args.ts, so this issue is not claiming that it is accidental. I would like to understand the original tradeoffs and whether guarded opt-in alternatives are acceptable.

Relevant design history

• 0c96983f — fix(agy): front-load user task in prompts
  • changed AGY from operational-context-first to task-first;
  • added a regression test requiring the task to precede operational context.
• be57343e — fix(agy): avoid stale resume context leakage
  • disabled AGY native resume because it could replay prior stdout or continue stale mid-turn planner state;
  • retained cli-jaw DB history as the safer continuity mechanism.
• Bug: agy transcript watcher pins stale conversation after brain rotation/compaction #245 later fixed stale current-turn transcript selection after brain rotation/compaction. That issue is related operational context, but it was filed after native resume had already been disabled and therefore does not appear to be the original reason for that decision.

Long-running AGY observations

In a long-running Telegram companion-agent workload, the stateless bridge can produce recurring continuity symptoms:

• AGY sometimes re-probes its workspace, capabilities, and instruction files as if starting a new task environment;
• previous tool state and decisions are not reliably carried across turns;
• context omitted by the bounded DB-history reconstruction is effectively lost;
• after AGY compaction or a fresh process boundary, AGY's default agent behavior can dominate injected persona/workflow instructions;
• repeated prompt reconstruction increases prompt size and makes continuity dependent on wrapper ordering.

These are operational observations, not proof that native resume alone fixes every case.

There is also a potential cache-efficiency tradeoff: Gemini recommends placing large common content at the beginning of the prompt and maintaining a stable prefix, while AGY currently receives changing task/history before the more stable operational context. Cache-hit behavior is not observable through the current AGY adapter, so this is a hypothesis rather than a confirmed billing claim.

Gemini context caching guidance:
https://ai.google.dev/gemini-api/docs/caching

Design questions

1. What concrete AGY failure or reproduction motivated 0c96983f to place the current task before operational context?
2. Is disabling native --conversation resume intended as a permanent AGY architecture decision, or was it a conservative mitigation for the stale replay/planner behavior observed at that time?
3. Would you accept opt-in AGY settings that preserve all existing defaults, for example:
   • perCli.agy.promptOrder: "context-first"
   • perCli.agy.nativeResume: "guarded"

Proposed guarded experiment

The default behavior would remain unchanged.

Optional context-first ordering

stable operational/system context
→ bounded recent history
→ current message

The current message remains last and explicit, while stable instructions become a reusable prefix.

A local opt-in implementation with compatibility-default task-first currently passes 37 focused AGY/steer tests and TypeScript validation:

GSL-R@93ca9d14

Optional guarded native resume

Use agy --conversation <id> -p <current-turn prompt> only when:

• the previous turn completed cleanly;
• model/project/resume identity still matches;
• no watchdog timeout, provider timeout, user interruption, or unresolved checkpoint occurred;
• no cli-jaw compaction/reset requested a fresh bootstrap.

Fallback behavior:

• on stale conversation, replay-only output, or conversation-not-found, clear the AGY bucket and retry once through the existing fresh DB-history path;
• never resume a side-effecting run after interruption without explicit evidence that continuing is safe;
• preserve the current transcript retargeting and replay-stripping guards.

Goal

Before implementing the native-resume experiment, I would like confirmation of the original task-first and resume-disable rationale, and whether a default-off guarded implementation would fit the intended AGY support direction.