agentplat▸control runs deployments agents metering + agent
← runs

run_c914764c20222cdb

AWAITING_APPROVAL retrigger →
jira-triage v1 · jira-triage-k8s · owner ingest:jira-new-ticket (api) · via jira-new-ticket · cloud-engineering

input

{
  "request": "Triage Jira ticket MZCLD-3720: Integrate Yardstick + Claude Agent so engineers can troubleshoot observability data conversationally",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3720"
  ],
  "sourceContext": {
    "issue": "MZCLD-3720"
  }
}

summary

MZCLD-3720 is an epic (status: Backlog, no comments yet) that formalizes and tracks a previously ad-hoc effort to connect Claude-based agent tooling with Yardstick (Grafana) observability data, so engineers can troubleshoot conversationally instead of manually navigating dashboards. It consolidates several in-flight/related tickets (MZCLD-2968, MZCLD-2836, MZCLD-3553, MZCLD-3561, MZCLD-3604) under one initiative with a concrete milestone: a Thundertalk demo on 2026-08-12. It explicitly excludes platform migration (MZCLD-3703) and productionizing the demo. The ticket is well-scoped for an epic but has no comments, no assignee/owner info surfaced, and no linked Confluence runbook/design doc was referenced to pull additional context from.

findings

  • none

proposed actions

jira.comment.postrisk low - informational/planning comment only, no ticket state changes proposed
MZCLD-3720
Triage note: This epic looks well-scoped and ready to move from Backlog into active planning. A few suggestions before kicking off:

1. Dependency check: MZCLD-3553 (Grafana 13.1.0 upgrade) is called out as a blocker for the newer plugin/API surface needed by MZCLD-3561 and MZCLD-3604 - worth confirming its status/timeline first, since it gates the rest of the epic given the 2026-08-12 Thundertalk demo deadline.
2. Consider linking MZCLD-2968 and MZCLD-2836 explicitly as 'relates to' / predecessor issues if not already linked, since they're the foundational work this epic builds on.
3. The 'agent-legible observability' spike mentioned in the description (labeling/metadata/query interface changes) doesn't appear to have its own ticket yet - recommend filing that as a tracked spike under this epic soon so it isn't lost, per the epic's own note that it may graduate into its own initiative.
4. Since productionizing the demo is explicitly out of scope, consider adding a brief 'definition of done' for the demo itself (what capability must be shown live) to keep scope tight leading up to 2026-08-12.

Happy to help break this into sprint-sized subtasks if useful.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3720"
    },
    "result": {
      "key": "MZCLD-3720",
      "summary": "Integrate Yardstick + Claude Agent so engineers can troubleshoot observability data conversationally",
      "status": "Backlog",
      "description_text": "Background Yardstick (Grafana) holds the metrics, logs, and alerts engineers need during an investigation, but reaching them is still a manual, human-driven loop: open a dashboard, guess the right panel, hand-edit a query. Meanwhile Cloud Engineering has been building Claude-based tooling in parallel \u2014 MCP access to Yardstick ( MZCLD-2968 ), Claude access to Yardstick dashboards ( MZCLD-2836 ), and a  /yardstick:grafana  skill. These have been landing as disconnected tickets. This epic makes the integration an explicit, tracked initiative. Goal Make Yardstick observability data directly usable by a Claude agent, so an engineer can ask a question about a service and get a real answer grounded in live metrics and logs \u2014 instead of navigating dashboards by hand. In scope Grafana 13.1.0 upgrade, which unlocks the newer plugin and API surface the agent work depends on ( MZCLD-3553 ) A troubleshooting panel / dialog exposed inside Grafana panels and dashboards ( MZCLD-3561 ) Updating the  /yardstick:grafana  Claude skill to cover the new 13.1 features ( MZCLD-3604 ) A working demo at Thundertalk on 2026-08-12 Where this leads The likely outcome of this work is a bigger question:  what needs to change about Observability Metrics and Logging so that they are first-class participants in an agentic workflow?  Today's metrics and logs were shaped for human readers \u2014 dashboard-first, label conventions applied unevenly, context living in people's heads rather than in the data. Making them agent-legible may mean changes to labelling, metadata, query interfaces, and documentation. That question is scoped as a spike under this epic and may well graduate into its own initiative. Out of scope Migrating existing Claude skills to another agent platform (see  MZCLD-3703 ), and productionizing the Thundertalk demo.",
      "comment_count": 0,
      "comments": []
    }
  }
]

usage

{
  "model": "claude-sonnet-5",
  "input_tokens": 3740,
  "output_tokens": 1819,
  "estimated_cost_usd": 0.038505
}

approvals

[]

log

launched k8s job run-run-c914764c20222cdb in ns/mzcld-demo-dev image=us-docker.pkg.dev/moz-fx-mzcld-demo-prod/mzcld-demo-prod/agentplat:latest
runner started
live reasoning model=claude-sonnet-5
awaiting approval for 1 action(s)