What happens when you stop thinking of AI agents as chatbots and start treating them as workers in a pipeline? This is the story of turning a sprawling Jira backlog into a self-orchestrating system, and the lessons learned along the way.TL;DRWe built an agentic workflow that automatically discovers Jira tickets, enriches them with context from source control, and produces structured summaries that make tickets actionable, all without human intervention. In practice, this pipeline processes dozens of tickets weekly and reduces triage time from hours to minutes, giving developers immediate context on actionable work. The journey took us from a single monolithic prompt (that barely worked) to a modular, zone-based pipeline where each ticket flows through independent agent sessions. This post covers the high-level design, the challenges of orchestrating AI agents at scale, and what we learned. A follow-up post will dive into the technical implementation details.The problem: Too many tickets, too little timeIf you’ve ever stared at a Jira board with dozens of open tickets, scattered across sprints, backlogs, and half-forgotten epics, you know the feeling. The mental overhead of context switching between tickets, understanding what each one requires, and figuring out which ones are even actionable is enormous. Multiply that by the number of repositories each ticket touches, and you’ve got a recipe for paralysis.We wanted to see if agentic engineering could handle the drudge work: pulling tickets from Jira, enriching them with context from source control, and producing structured summaries that a downstream agent (or human) could act on immediately. And doing all of this in a timely manner, without anyone babysitting a single session.The result is a modular, zone-based automation pipeline that treats each Jira ticket as an independent unit of work flowing through well-defined stages. We call it "Taming the Agent Beast," because wrangling AI agents into a reliable, repeatable workflow turned out to be the real challenge.Why not just a script?The obvious first instinct is to write a Python script that calls the Jira application programming interface (API), formats some markdown, and calls it a day. We considered that, and the limitations became clear fast:Context is king. A script can pull ticket fields, but it can’t reason about whether a ticket description is vague, whether the acceptance criteria make sense, or whether a continuous integration (CI) pipeline is failing in a way that’s relevant to the ticket.Enrichment requires judgment. Deciding which repository a ticket targets, mapping project paths from uniform resource locators (URLs) buried in comments, and assessing whether a ticket has enough information to act on all benefit from language model reasoning.The pipeline needs state. Tickets aren’t one-shot. They get discovered, triaged, blocked, enriched, and validated. A script handles 1 step; you need a workflow to manage the entire lifecycle.So instead of a script, we built a pipeline of agentic sessions coordinated through a board-based state machine.Key concepts: The building blocksBefore diving into the architecture, a few concepts are worth introducing:Agor is a framework for orchestrating AI agent sessions across repositories. It provides a board-based interface (think Kanban) where work items move through columns, and each column can trigger an agent session with a specific prompt and set of tools. We use Agor as the orchestration layer for this demonstration, but the design patterns described here, such as zone-based pipelines, structured output contracts, and stateful orchestration, are framework-agnostic. Red Hat doesn't bind you to a specific agentic framework; instead, it provides the foundation to run them. In an enterprise environment, you can deploy these patterns using Red Hat OpenShift AI, which gives you the means to host, scale, and operationalize any agents you choose.Zones are the columns on the board. Each zone represents a stage in the workflow (Discover, Triage, Ready, etc.) and has its own agent configuration: a dedicated prompt, a set of Model Context Protocol (MCP) tool integrations, and trigger rules that determine when sessions launch.Worktrees are the units of work. Each Jira ticket gets its own worktree, backed by a Git worktree in the target repository, moving between zones as it progresses through the pipeline. A worktree carries metadata (the Jira issue URL, the pull request (PR)/merge request (MR) URL, notes, custom context) and its zone position tells you exactly where the ticket is in the workflow. Think of it as a Kanban card that also happens to be a real, isolated Git working directory.The architecture: Zones as a state machineThe core idea is borrowed from Kanban: every ticket moves through zones, and each zone has a dedicated agent with a dedicated prompt. No agent tries to do everything. The Discover agent discovers. The Triage agent triages. And so on.The workflow