[agentic-token-optimizer] Release workflow: prompt verbosity, failed-push retry waste, and sub-agent opportunity

[github-actions]

Target Workflow

Release (workflows/release.md) — the only active LLM-powered agentic workflow not bearing "Token" in its name and not excluded by stronger competing signals. All other candidates (Copilot cloud agent, Install Workflows, Agentic Maintenance, Copilot Setup Steps) were optimized within the last 1–7 days.

---

Analysis Period & Runs

All 3 available Release runs from the last 30 days were analyzed:

Run	Date	Effective Tokens	Turns	Conclusion
§25873066389	2026-05-14	772,435	3	✅ success
§26163733067	2026-05-20	2,454,827	9	✅ success
§26780840710	2026-06-01	1,059,887	4	✅ success

---

Token Profile

Metric	Value
Analysis window	2026-05-14 – 2026-06-01
Runs analyzed	3
Total effective tokens	4,287,149
Avg effective tokens/run	1,429,050
Avg turns/run	5.3
Turn range	3 – 9
Conclusions	3/3 success
Cache efficiency	Not applicable (each run is a distinct release event)

The 3× turn variance (3 vs 9) and 3× token variance (772 K vs 2.45 M) between runs is the primary waste signal.

---

Ranked Recommendations

1 — Eliminate failed git-push retries (≈ 500–800 ET saved per affected run)

Evidence: The 2026-05-20 run spent 5 of its 9 turns on CHANGELOG editing and two failed push attempts:

● Edit CHANGELOG.md +4
● Commit and push changelog update (shell)   ← failed (no credentials)
● Stop shell
● Try push with token (shell)                ← failed again
● Stop shell

Credentials are deliberately stripped before the agent runs (step 23: "Clean credentials"), so any git push will always fail. The two dead-end shell sessions and their surrounding LLM turns account for the bulk of the 1.4 M ET gap between this run and the May-14 baseline.

Action: Add a one-sentence guard to the prompt's push instruction:

Replace: "push the change back to the repository when semver_context.json contains a branch-like release_target"
With: "push the change back to the repository when semver_context.json contains a branch-like release_target; if the push fails on the first attempt, record the failure and proceed — do not retry"

Alternatively, add an explicit credential smoke-test to the Prepare release context setup step and surface a clear warning so the agent knows upfront whether pushing is possible.

Estimated savings: ~700 ET/run average (this pattern affected 1 of 3 observed runs; the fix prevents all retry turns).

---

2 — Consolidate overlapping writing-constraint sections (≈ 200 ET saved per run)

Evidence: The prompt body contains four back-to-back sections that partially repeat the same constraints:

• Selection rubric for whether a change belongs in the release notes
• Exclude internal-only changes unless they materially affect users
• Release-note anti-patterns to avoid
• Writing quality constraints

Several rules appear in multiple sections. For example, "do not rewrite commit subjects into bullets" is implied by the anti-patterns list and by the selection rubric. "Avoid vague filler" appears in quality constraints and can be inferred from the writing-quality guidance. The four sections together are approximately 400 tokens that could be distilled to ≈ 250 tokens without losing any distinct rule.

Action: Merge the four sections into a single ## Constraints section. Keep one entry per distinct rule; drop any bullet that merely restates a rule already present in another form.

Estimated savings: ~150–200 ET per run (consistent across all runs as prompt reduction).

---

3 — Document previous_release.json null-field semantics (≈ 100 ET saved per affected run)

Evidence: The 2026-05-20 run added an extra investigative bash call:

✓ $ cat /tmp/gh-aw/release-data/previous_release.json | python3 -c "import json,sys; 
    d=json.load(sys.stdin); print(d.get('tag_name'), ...)" 2>/dev/null
◆ The previous release JSON returns None for tag_name. So there's no previous release 
  with v0.2.0 tag noted. But the semver_context says previous_tag is v0.2.0.

The agent was confused by the discrepancy between previous_release.json (where tag_name was null because the release object structure differed from expectations) and semver_context.json. This triggered an extra turn.

Action: Add one sentence to the ## Data Available section under previous_release.json:

previous_release.json — the previous release object, or null if this is the first release. Note: tag_name may be null even when a previous release exists; treat semver_context.json as the authoritative version source.

Estimated savings: ~100 ET per affected run (~1 turn avoided).

---

4 — Inline sub-agent: commit categorization (≈ 200 ET saved per run)

Evidence: In all 3 runs the agent's first action is a bash block that reads commit_subjects.tsv, changed_files.txt, current_release.json, and semver_context.json. The agent then classifies each commit as user-facing vs internal before writing release notes. This classification step is purely extractive and does not depend on the final notes output.

Score:

Dimension	Score	Rationale
Independence	3/3	Reads only pre-staged files; no dependency on final release notes
Small-model adequacy	3/3	Classify each commit subject as user-facing/internal; format into a compact list
Parallelism	1/2	No other concurrent section exists, but the main agent starts with a clean summary
Size	2/2	Multiple files to read; structured output saves re-reading
Total	9/10	Strong candidate

Why a smaller model fits: The task is: read commit_subjects.tsv, filter commits where subject or changed files suggest user-visible impact, and return a 5–10 line structured summary. No synthesis or creative writing required.

Proposed change: Add before ## Data Available:

## agent: categorize-commits
model: small

Read `/tmp/gh-aw/release-data/commit_subjects.tsv` and `/tmp/gh-aw/release-data/changed_files.txt`.
For each commit, classify as `user-facing` or `internal` based on whether the change affects workflow behavior, configuration, outputs, or triggers that users depend on. Return a compact bullet list: one line per user-facing change in plain English (outcome first), and a one-line count of internal-only commits omitted.

The main agent prompt then references ${{ agent.categorize-commits }} in the ## Data Available section instead of re-reading the raw files directly.

Estimated savings: ~200 ET/run (smaller model + pre-processed context reduces main agent turns).

---

Caveats

• Only 3 runs exist for this workflow (it is manually triggered per release). Patterns are directional, not statistically robust.
• The failed-push finding is based on 1 of 3 runs; other runs may have had credentials available at different times.
• The sub-agent recommendation depends on the AWF runtime supporting ${{ agent.name }} output interpolation — verify before implementing.
• Prompt reduction savings are estimated from raw character counts; actual ET savings depend on tokenizer behavior.

References: §26163733067 · §26780840710 · §25873066389

Generated by Agentic Workflow Token Usage Optimizer · ● 21.3M · ◷

• expires on Jun 12, 2026, 3:40 PM UTC