Red Hat’s Jira Automation Rebuild Turns Agent Autonomy Into a Reliability Problem

The common assumption behind most agentic AI projects is that more autonomy makes an agent more useful: give it a broad prompt, a wide toolset, and let it figure out the rest. A new Red Hat engineering blog post published today argues the opposite, and backs it up with a real internal system that broke until the team took autonomy away.

The post, written by Red Hat engineers Ioannis Angelakopoulos and Joseph Berry, walks through how they automated Jira ticket triage for their own team: pulling tickets out of the backlog, checking whether they have enough context to act on, and filling in the gaps from source control before a human ever looks at them. Their first version was a single prompt that tried to do everything. It didn’t survive contact with a real backlog. The version that replaced it is a modular, state-machine-style pipeline, and the lesson the authors draw from the rebuild is one worth taking seriously for anyone building agent workflows on top of real systems of record: narrower agents with less freedom turned out to be the more reliable design.

A Backlog That Needed Triage Before It Needed Answers

The problem the two engineers set out to solve is mundane in the way most real automation problems are: their team processes dozens of Jira tickets a week, and a meaningful share of them arrive without enough information to act on. Someone has to read each one, decide whether it references the right repository, has clear acceptance criteria, and links to the code it touches, then either move it forward or chase down the missing context. That triage work doesn’t require deep expertise, but it does require doing it consistently, every week, without dropping tickets. It is exactly the kind of repetitive, judgment-light task that gets pitched as a natural fit for an AI agent.

The First Attempt Was One Prompt Doing Everything

The initial implementation matches how a lot of teams still build their first agent: one prompt, handed the whole job. Query Jira, evaluate each ticket, chase down source control context, write a summary, update the ticket, repeat. According to the post, that design failed in ways that will sound familiar to anyone who has shipped a single-prompt agent against a non-trivial workload:

• Runtimes stretched out and the context window filled up as the agent tried to carry the entire backlog through one session.
• There was no way to track state across runs, so a session that died partway through left no record of what it had already done.
• A single failure could take down the whole batch, since one bad ticket or one API hiccup stopped the run before it reached the rest.
• Everything happened sequentially inside one session, which ruled out any parallelism across tickets.

None of that is a model-quality problem. It is an architecture problem: a single unbounded prompt has no natural place to stop, checkpoint, or fail gracefully. The fix the authors landed on wasn’t a better prompt. It was giving up on the single-prompt design entirely.

Rebuilding the Pipeline as a State Machine

The rebuilt system runs on Agor, a project from Preset, the data-visualization company behind Apache Superset, that describes itself as a “team command center for all things agentic.” Agor presents agent work as a Figma-style 2D board: branches show up as cards, and dropping a card into a region of the board, a zone, fires a templated prompt against that ticket in a fresh agent session. Under the hood, each unit of work is backed by an actual Git worktree, which is how the system carries metadata like ticket URLs, pull request references, and notes across zones without relying on any single session’s memory. Agor exposes its own control surface over the Model Context Protocol, so an agent session can fork itself, spawn a follow-up session, or schedule its own next run. Worth noting for anyone considering it: Agor is licensed under the Business Source License 1.1, which converts to the Apache License 2.0 on January 15, 2029, or four years after its first public release, whichever comes first, rather than under a permissive open-source license from day one.

Red Hat’s team mapped their ticket-triage workflow onto five zones, each one a narrow, single-purpose stage rather than a general-purpose agent:

Discover: Provision, Don’t Enrich

The Discover zone is deliberately scoped to do one thing: find new work and set it up. It runs three separate JQL queries covering active epics, current sprint tickets, and the backlog, parses any GitHub or GitLab URLs out of ticket descriptions and comments, and clones repositories it hasn’t registered before. It creates worktrees in batches of three with a verification step between batches rather than firing off the whole backlog at once, and it runs a periodic heartbeat check to catch drift, tickets that got resolved outside the pipeline, sprint rotations, reassignments. Critically, Discover does not try to enrich anything itself. That work stays downstream, in a separate zone with its own separate agent session.

Triage: A Narrow Routing Decision

Triage’s job is a single yes-or-no routing call: does this ticket have enough context to move forward? Well-defined tickets go straight to Ready. Everything else goes to Blocked. Because each ticket gets its own session, triage decisions run in parallel: the post describes five tickets triaging at once, something that was structurally impossible in the single-prompt version.

Enrich: Where the Context Actually Gets Filled In

Enrich is the zone that does the heavy lifting. It polls Blocked, pulls in CI pipeline status, open merge requests, and related issues, and writes the result back to Jira as a structured markdown summary with YAML frontmatter carrying the ticket key, type, status, linked repositories, CI status, and merge requests as machine-parseable metadata. The markdown body follows a fixed set of sections: description, context and analysis, detailed requirements, technical considerations, acceptance criteria, and dependencies. From there, a ticket either routes to Ready or falls back to Blocked if it still isn’t sufficient.

The Real Lesson: Less Autonomy, Not More

The finding the authors lead with is the one that cuts against how most people pitch agentic AI: “The biggest misconception about agentic workflows is that you should give agents maximum autonomy. In practice, the opposite is true.” Narrowing each zone’s scope and enforcing strict output formatting is what made the pipeline’s failure rate and consistency improve, not a bigger model or a longer prompt.

The mechanism behind that is a structured output contract. Every agent session in the pipeline is stateless: it starts fresh, with no memory of anything a previous session did. What makes the pipeline behave like it has continuity is that state lives outside any individual session, in worktree metadata and in which zone a ticket currently sits in. As the authors put it, the design is “stateless agents, stateful orchestration.” The YAML-frontmatter format that Enrich writes is the glue that makes that work: it’s what the authors call the thing that “makes the pipeline composable,” because each stage can trust the shape of what the previous stage handed it instead of having to re-interpret free text.

What Still Breaks: The Operational Scars

The post is unusually candid about what a production-adjacent agent pipeline still gets wrong, even after the redesign:

• Scheduling idempotency. A session that crashed before it could disable its own schedule left duplicate processing behind. The fix isn’t automatic; it requires external lock management or idempotency tokens, because the pipeline can’t assume a schedule got cleanly turned off.
• API capability gaps. Some automation features the pipeline needs, schedule management among them, aren’t exposed through standard APIs, which forced the team into workaround implementations rather than clean integrations.
• Permission model tension. Cron-scheduled sessions running unattended need broad automation permissions to do their job, which sits uncomfortably against the narrower, interactive approval patterns that make sense when a human is watching a session in real time.

None of these are exotic problems. They’re the same class of issue any team hits when it moves a script from “someone runs it by hand” to “it runs on its own on a schedule”: idempotency, permission scoping, and API surface gaps that only show up once something is unattended.

A Demonstration, Not a Product

Red Hat is explicit that Agor itself is not a Red Hat product and isn’t supported for production use. The post frames it as a demonstration of the zone-based design pattern, and points readers who want officially supported tooling toward Red Hat’s own OpenShift AI documentation and its agentic AI resources instead. That distinction matters: the pipeline described in the post is a real system this specific team runs against its own Jira board, built on a third-party tool under a source-available license, not a packaged product anyone else can install today.

What generalizes past this one team’s backlog is the pattern, not the tool. Treat an agent workflow as a state machine with narrow, single-purpose stages and a structured handoff contract between them, and the reliability problems that show up in almost every first-draft agent (context exhaustion, no checkpointing, one bad input taking down a whole run) mostly go away, regardless of which coding-agent CLI or orchestration board sits underneath. Sxz.io has covered the same tension from other angles recently: Red Hat’s own postmortem on a 6 AM incident made a similar case for why agent frameworks need a platform layer instead of ad hoc scripts, and reporting on how dev agencies run coding agents in production found the same pattern: the speed gains come from structure around the agent, not from giving the agent more rope.

For teams already drowning in the same kind of untriaged backlog, the practical takeaway isn’t “go install Agor.” It’s that the fix for an agent that’s unreliable at a real workload is very often to make it do less, not more, and to put the state somewhere the agent itself can’t forget it.