[agentrx-optimizer] Daily Workflow Optimization - 2026-07-31

[github-actions]

Executive Summary

AgentRx's own pipeline (ir/static/dynamic/check/judge/report) could not execute in this sandbox — every stage requires an LLM endpoint (copilot, azure, or trapi), and none has usable credentials here (copilot → "No authentication information found"; azure → missing AGENT_VERIFY_ENDPOINT). Per the fallback guardrail, this report is built directly from mcp__agenticworkflows__audit telemetry plus a live reproduction of the failure this run, rather than from AgentRx-processed artifacts.

Top finding: the mcp__agenticworkflows__logs tool is the critical bottleneck step across recent runs of this very workflow. In the last fully-audited run (30518923828, 2026-07-30, success), logs was called 96 times — the single most-invoked tool by a wide margin — inside an 81-turn, 28.8-minute, 5.32M-token session. I independently reproduced the same tool malfunction live in today's run (30609669325): logs times out after 60s when called without a workflow_name filter, and returns total_runs=0 ("No runs found matching the specified criteria") when called with a workflow_name filter — even for workflows with confirmed completed runs (verified by fetching the same run directly via audit(run_id=...), which succeeded instantly).

AgentRx Evidence

• Critical step: tool_call:mcp__agenticworkflows__logs
• Failure category: unbounded retry against a broken/unreliable MCP tool (partially reducible to a deterministic precondition check)
• Frequency / impact: 96 of ~103 tool invocations in run 30518923828 (dominant tool by call count); drives the run's resource_heavy_for_domain (severity: high) and partially_reducible (agentic_fraction=0.50) assessments from mcp__agenticworkflows__audit
• Representative run IDs: 30518923828 (full audit, success, 28.8m/81 turns/5.32M tokens), 30609669325 (this run, live reproduction)

AgentRx Artifacts

AgentRx pipeline status: Not executed. ir stage failed on both copilot (default) and azure endpoints:

• copilot: [CopilotCLI] exit 1: Error: No authentication information found. (5/5 retry attempts exhausted)
• azure: Error: Missing required environment variables for --endpoint azure: AGENT_VERIFY_ENDPOINT
• trapi not attempted (Microsoft-internal endpoint, not reachable from this environment)

No check.json / judge.json / report artifacts exist as a result. The trajectory-builder, failure-pattern-classifier, and artifacts-summarizer sub-agents defined in .claude/agents/ were also not discoverable by the Agent tool this run (registry only exposed built-ins: claude, Explore, general-purpose, Plan, statusline-setup) — this is itself relevant to the workflow's sub_agent_strategy A/B experiment, since the sub_agents variant cannot currently execute as designed.

Manual violation classification (in place of failure-pattern-classifier, built from mcp__agenticworkflows__audit output for run 30518923828 and live reproduction in run 30609669325):

violation	evidence	fix_type	rationale
logs called 96× in one 81-turn run (dominant tool, ~59% of tool_types)	tool_usage: logs=96; run duration 28.8m, 5.32M tokens, most_used_tool: "logs (96 calls)"	improving retry/backoff strategy	No bound on retries against an unreliable tool inflated turns/tokens without limit
logs returns total_runs=0 for every workflow_name-filtered query, even for workflows with confirmed completed runs	6 distinct workflow_name values tried live (exact title, filename, other workflow titles); all returned empty while audit(run_id=...) succeeded instantly for the same runs	adding precondition checks before expensive tools	A single audit(run_id=...) sanity check against a known run would reveal the filter path is broken before spending turns on variations
logs times out at 60s when called without workflow_name (repo has 266 workflows)	4 timeouts across count=1–50 and multiple date windows, live in run 30609669325	adding precondition checks before expensive tools	Unfiltered scans across all repo workflows exceed the single-call time budget and should never be attempted
~50% of turns are data-gathering/retry loops rather than analysis	agentic_assessments: partially_reducible, agentic_fraction=0.50, turns=81	prompt tightening to reduce invalid tool invocations	Workflow instructions don't cap logs attempts or mandate falling back to audit(run_id) sooner

Known limitations: this analysis covers one fully-audited historical run plus live reproduction, not the "50 runs / 2 days" corpus the workflow ideally targets — the logs tool's own unreliability is precisely what prevented gathering that broader corpus.

Recommended Optimization

Change: In .github/workflows/daily-agentrx-trace-optimizer.md, add an explicit precondition/retry-cap rule to the data-gathering instructions:

1. Never call mcp__agenticworkflows__logs without a workflow_name filter (it will time out scanning all repo workflows).
2. Cap logs retries at 2 attempts total per workflow queried; on empty/timeout, immediately fall back to mcp__agenticworkflows__audit against any already-known run_id (e.g., from status or prior context) rather than trying further logs parameter variations.
3. Treat repeated empty results from logs as a tool-health signal worth surfacing via missing_tool, not a "no data" signal worth re-querying.

Why highest impact: logs retries alone consumed 96 of ~103 tool calls and an estimated majority of the 28.8-minute, 5.32M-token run cost in the one fully audited execution — by far the largest single line item in that run's cost profile. Capping retries and adding an audit-first fallback directly targets the step responsible for the resource_heavy_for_domain (high severity) and partially_reducible findings, without needing any fix to the underlying MCP server itself.

Where to implement: .github/workflows/daily-agentrx-trace-optimizer.md (the "Data and Tooling Requirements" section describing logs usage), recompiled via the gh-aw compile step. Separately, the logs tool's workflow_name matching bug (returns 0 runs for known-good workflows) and its unfiltered-scan timeout are worth a bug report against the agentic-workflows MCP server itself, outside this workflow's own files.

Validation Plan

• On the next scheduled run, check mcp__agenticworkflows__audit's tool_usage for this workflow: logs call count should drop sharply (target: ≤10, down from 96) and audit call count should rise correspondingly.
• Expect total run duration and token usage to drop substantially (baseline: 28.8m / 5.32M tokens) since the retry loop was the dominant cost driver.
• Confirm the resource_heavy_for_domain and partially_reducible assessments no longer trigger, or trigger at lower severity, in the next audit of this workflow's run.
• If logs still returns empty for known-good workflow_name values after the fallback is added, escalate as a standalone agentic-workflows MCP server bug (matching path issue), not a prompt issue.

References

• §30518923828 — fully audited baseline run (96× logs calls, 28.8m, 5.32M tokens)
• §30609669325 — this run, live reproduction of the logs failure mode

Generated by ⚡ Daily AgentRx Trace Optimizer · agent · 198 AIC · ⌖ 20.1 AIC · ⊞ 6.7K · ◷

• expires on Aug 6, 2026, 10:56 PM UTC-08:00