# Diagnostic Agent Time Budget

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "diagnostic-agent-time-budget-2026-08-10",
  "problems": [
    {
      "problemId": "diagnostic-agent-planning-consumes-pipeline-headroom",
      "summary": "High-context evidence acquisition spends about 80 to 90 seconds in agent planning beyond brief skill/reference loading, leaving insufficient headroom for useful provider acquisition and finalization inside the shared 20-minute pipeline.",
      "status": "optimized_unverified",
      "issueKeys": ["APID-29265", "APID-29232"],
      "sourceRefs": [
        "https://github.com/tidbcloud/aisupport/issues/606#problem:apid-29265-agent-planning-latency",
        "https://github.com/tidbcloud/aisupport/issues/606#problem:apid-29232-agent-planning-latency"
      ],
      "signalTextIncludesAny": [
        "agent planning consumes diagnostic deadline",
        "scenario finalization budget exhausted",
        "acquisition thread spends 80 to 90 seconds before provider execution"
      ],
      "observedThrough": "2026-08-10",
      "effectiveAt": "2026-08-10T06:17:00Z",
      "verifiedAt": null,
      "attemptedAction": "Raise the shared diagnostic/support/work deadline from 20 to 22 minutes, scenario cap from 15 to 16 minutes, and auth/bootstrap cap from 2.5 to 3 minutes while retaining the 25-minute worker and Bot assignment boundary and at least three minutes for writeback and terminal status.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/actions/runs/31361107651"
    }
  ]
}
-->

- Optimization ID: `diagnostic-agent-time-budget-2026-08-10`
- Owner: auto-oncall-services runner and deployment configuration
- Source reference: `APID-29265` and `APID-29232` staging acquisition traces
- Implementation status: merged and deployed to staging
- Effective status: `optimized_unverified`

## Bounded problem

The two recent acquisition traces spent 13–19 seconds reaching the required
skills and references, then about 80–90 seconds on high-context planning before
provider execution. Their complete acquisition turns consumed 174 and 196
seconds, while provider batches consumed 62 and 72 seconds. With roughly
200k–223k input tokens and high reasoning, that planning cost is long but
plausible rather than a stalled skill loader.

The current 20-minute shared pipeline can therefore squeeze a useful scenario
round or finalization even when the provider itself is healthy. This record
owns only time allocation. It does not change prompts, model reasoning effort,
provider retries, query concurrency, round quota, or diagnosis semantics.

## Candidate change

- Raise shared diagnostic pipeline, support analysis, and scenario work from
  20 to 22 minutes.
- Raise the scenario cap from 15 to 16 minutes and auth/bootstrap outer cap
  from 2.5 to 3 minutes.
- Keep provider query sub-deadline, synthesis, correction, and normalization
  caps unchanged.
- Keep worker analysis and Bot assignment at 25 minutes, leaving at least three
  minutes for Jira writeback and terminal status.

## Verification evidence

[aisupport PR 710](https://github.com/tidbcloud/aisupport/pull/710) passed all
703 TypeScript tests and merged the code and source deployment template.
[app-delivery PR 76646](https://github.com/tidbcloud/app-delivery/pull/76646)
synced only the staging ConfigMap change, and
[deployment run 31361107651](https://github.com/tidbcloud/aisupport/actions/runs/31361107651)
plus [app-delivery PR 76647](https://github.com/tidbcloud/app-delivery/pull/76647)
deployed the current main image after a concurrent older image bump was
detected and superseded.

The live Pod reports pipeline/support timeouts of 1,320,000 ms, auth/bootstrap
of 180,000 ms, scenario of 960,000 ms, and unchanged worker and Bot assignment
deadlines of 1,500,000 ms. It is Ready with zero restarts and `/readyz` returns
HTTP 200. Poller logs show successful polls, worker logs remain idle, the DB has
no queued, running, or retryable-failed jobs, and the active Jira poll cursor
continues to advance.

This evidence proves that the larger budget is active without widening the
25-minute boundary. No post-change near-timeout case has yet proved that the
extra two minutes changes an outcome, so the problem remains
`optimized_unverified`.

## Unresolved gaps

- This allocation does not make agent planning faster. Reducing skill/context
  size is a separate optimization and remains out of scope.
- Configuration evidence proves availability, not that a future near-timeout
  case will complete successfully.

## Next validation action

Observe the next applicable high-context diagnostic run and verify successful
publication and terminal-status writeback within 25 minutes.