Summary
In workflows/agentic-token-optimizer.md, the Phase 1 self-targeting guard can never fire, so the optimizer can (and in practice does) select itself or its sibling audit as the workflow to optimize.
The bug
Phase 1 — Select Target (line ~164):
- Exclude workflows with "Token" in the name to avoid self-targeting.
But the two monitoring workflows are not named with "Token":
agentic-token-optimizer.md H1 (line ~113): # Agentic Workflow AIC Usage Optimizer
agentic-token-audit.md H1 (line ~78): # Daily Agentic Workflow AIC Usage Audit
gh aw logs reports workflow_name as the display name (the H1), e.g. "Agentic Workflow AIC Usage Optimizer". Neither display name contains the substring "Token", so the exclusion rule matches nothing and the monitoring family is never excluded from candidate selection. The string "token" only appears in the workflow id / tracker-id (agentic-token-optimizer, agentic-token-audit), which the guard does not check.
Impact
In any repo where the monitoring family is the most reliable source of non-zero AIC in the analysis window — which is common, because (a) gh aw logs only recovers ~24h of telemetry (per-run artifacts expire after 1 day) and (b) high-frequency event-driven workflows skip their agent on most runs and report 0 AIC — the sort_by(total_ai_credits) ranking puts the always-on scheduled Optimizer/Audit on top. With the guard broken, the optimizer then selects itself (or, once the audit is excluded by the 14-day dedup, its sibling), producing "optimize the optimizer" issues instead of analyzing genuinely expensive workflows.
We hit this repeatedly in a production monorepo: every optimizer run targeted the monitoring family until we worked around it.
Suggested fix
Key the self-exclusion off the workflow id / tracker-id (which do contain token) or off the actual display-name pattern, rather than the substring "Token" in the display name. For example:
- Exclude the AIC monitoring family — the `agentic-token-optimizer` and `agentic-token-audit`
workflows (display names "Agentic Workflow AIC Usage Optimizer" /
"Daily Agentic Workflow AIC Usage Audit") — to avoid self-targeting.
A more robust approach would also pre-filter the monitoring family deterministically in the Aggregate top workflows frontmatter step (by workflow_path matching agentic-token-(optimizer|audit)), so selection can't regress even if the prompt-level rule is missed.
Environment
- Source pinned at
githubnext/agentic-ops@c31cadc6b436d75014a8e2ad34dcfd4c5c079256; bug also confirmed present on the current default branch.
- gh-aw compiler v0.79.x.
Summary
In
workflows/agentic-token-optimizer.md, the Phase 1 self-targeting guard can never fire, so the optimizer can (and in practice does) select itself or its sibling audit as the workflow to optimize.The bug
Phase 1 — Select Target (line ~164):
But the two monitoring workflows are not named with "Token":
agentic-token-optimizer.mdH1 (line ~113):# Agentic Workflow AIC Usage Optimizeragentic-token-audit.mdH1 (line ~78):# Daily Agentic Workflow AIC Usage Auditgh aw logsreportsworkflow_nameas the display name (the H1), e.g."Agentic Workflow AIC Usage Optimizer". Neither display name contains the substring "Token", so the exclusion rule matches nothing and the monitoring family is never excluded from candidate selection. The string "token" only appears in the workflow id /tracker-id(agentic-token-optimizer,agentic-token-audit), which the guard does not check.Impact
In any repo where the monitoring family is the most reliable source of non-zero AIC in the analysis window — which is common, because (a)
gh aw logsonly recovers ~24h of telemetry (per-run artifacts expire after 1 day) and (b) high-frequency event-driven workflows skip their agent on most runs and report 0 AIC — thesort_by(total_ai_credits)ranking puts the always-on scheduled Optimizer/Audit on top. With the guard broken, the optimizer then selects itself (or, once the audit is excluded by the 14-day dedup, its sibling), producing "optimize the optimizer" issues instead of analyzing genuinely expensive workflows.We hit this repeatedly in a production monorepo: every optimizer run targeted the monitoring family until we worked around it.
Suggested fix
Key the self-exclusion off the workflow id /
tracker-id(which do containtoken) or off the actual display-name pattern, rather than the substring "Token" in the display name. For example:A more robust approach would also pre-filter the monitoring family deterministically in the
Aggregate top workflowsfrontmatter step (byworkflow_pathmatchingagentic-token-(optimizer|audit)), so selection can't regress even if the prompt-level rule is missed.Environment
githubnext/agentic-ops@c31cadc6b436d75014a8e2ad34dcfd4c5c079256; bug also confirmed present on the current default branch.