Red Hat breaks Jira triage into stateful, per-ticket agent workflows

Red Hat engineers have described an agentic workflow that discovers Jira tickets, checks whether they are actionable, enriches them with source-control context and produces structured summaries. The notable part is not the Jira integration itself. It is the architecture they reached after a single, all-purpose prompt proved too slow, brittle and difficult to resume.

According to Red Hat’s engineering post, the pipeline now handles dozens of tickets each week and cuts triage from hours to minutes. Those are the authors’ operational results, not an independently reproduced benchmark.

From one prompt to a state machine

The design divides work into Discover, Triage, Blocked, Enrich and Ready zones. Each zone launches an agent with a narrow prompt, a defined tool set and explicit routing rules. A scheduled Discover agent queries Jira, maps tickets to repositories and creates work in batches. Separate per-ticket sessions then decide whether a ticket has enough context or needs enrichment from CI status, merge requests and related issues.

Each ticket is also backed by an isolated Git worktree in its target repository. The worktree’s metadata and board position carry state between otherwise stateless agent sessions. That lets several tickets move in parallel without one failed ticket collapsing the entire batch.

The output contract matters as much as the orchestration. Enrichment produces YAML frontmatter for machine-readable fields plus standardized Markdown sections for requirements, dependencies and technical analysis. Downstream agents and human reviewers therefore consume a predictable artifact rather than unconstrained prose.

The reliability lessons are the real payload

Red Hat’s authors say narrowing agent scope improved output and reduced failures. They also document unresolved engineering problems: scheduled sessions can overlap, a crashed agent may fail to disable its next run, and some schedule controls required direct database work because the framework’s API did not expose them. They point to idempotency tokens or external locks as stronger—but more complex—ways to prevent duplicate processing.

The post also highlights the permission tradeoff in unattended automation. Scheduled agents must run without interactive approval prompts, which broadens what a mistaken prompt can do. Externalized state, strict output schemas, narrow permissions and reconciliation heartbeats are therefore part of the production design, not optional polish.

What platform teams should take from it

The reusable pattern is stateless agents with stateful orchestration: persist progress outside the model, give each stage one responsibility, and make transitions observable. Teams evaluating an agent framework should also verify that scheduling, locking, permissions and recovery are available through supported APIs before relying on it for unattended work.

The demonstration uses Agor, which the authors explicitly say is neither a Red Hat product nor part of the supported OpenShift AI stack. Red Hat positions OpenShift AI as the platform on which similar agents can be hosted and operated; a promised follow-up is expected to cover the implementation details, including MCP tool wiring and scheduling.