Jira backlog agent

The Jira backlog agent reads every open Jira issue labelled agent-ready, implements the dbt™ models each one needs with tests and YAML docs, opens a PR for each, and posts status updates to Slack. The orchestration lives inside the agent’s goal: one self-contained session lists the backlog, works each issue in turn, and posts a summary, so there is no orchestrator script, Python package, or environment-variable plumbing to maintain.

Prerequisites

Jira connected so the agent can call get_jira_issue and list_jira_issues. Pick Jira Cloud or Jira Data Center depending on your environment.
Slack connected (the agent posts status updates via post_slack_message).
Your repository connected so the agent can branch, commit, and call create_pull_request.
Familiarity with programmable agents and running an agent with Bolt.
Issues to automate must be open and carry the label agent-ready.

Estimated time: 15 minutes.

Steps

Create the agent

Build the agent in the Agent UI (start from the jira-backlog-agent template), or commit this file at .dinoai/agents/jira-backlog-agent.yml. This is the only file you need: it defines the agent’s role, goal, tools, and Slack output channel, and its goal does the looping over the backlog.

.dinoai/agents/jira-backlog-agent.yml

name: jira-backlog-agent
version: 1

role: >
  End-to-end agent that picks up every open "agent-ready" Jira issue and
  delivers a dbt model PR for each one.

goal: >
  1. List all open Jira issues labelled "agent-ready". If none, post to
     #agent-demo and stop. Otherwise post the list of keys you'll action.

  2. For each issue (one at a time): read it, explore the repo, create a
     branch (jira-<KEY>-<short-desc>-<5-char-rand>), implement the dbt
     changes, commit & push, open a PR, then post the PR link to
     #agent-demo.

  3. Post a final summary to #agent-demo with every issue key and its PR
     link (or a reason if it couldn't be completed).

backstory: >
  You are a self-contained analytics engineer — you never delegate.
  Before writing anything new, check the repo for existing models or
  sources that already cover the request. Reuse what exists; if it's a
  close but not exact match, flag it in the PR under "Open questions"
  rather than duplicating work. Never invent columns. Flag all other
  ambiguities in the PR under "Open questions" rather than guessing.

tools:
  mode: allowlist
  list:
    - get_jira_issue
    - list_jira_issues
    - read_file
    - write_file
    - replace_in_file
    - search_files_and_directories
    - ripgrep_search
    - run_sql_query
    - run_terminal_command
    - post_slack_message

slack:
  channel: "#agent-demo"

tools.mode: allowlist means the agent can call only the tools listed, which keeps each session focused and prevents unintended side effects. The get_jira_issue and list_jira_issues tools require the Jira integration, post_slack_message requires Slack, and create_pull_request requires Git. Update slack.channel (and the channel referenced in the goal) before committing if your team uses a different channel.

Commit the agent to your repo

Commit the YAML to the git branch your Bolt schedule runs against, alongside your dbt™ project. That single file is the entire footprint:

your-repo/
├── dbt_project.yml
└── .dinoai/
    └── agents/
        └── jira-backlog-agent.yml

The agent now appears in the Agent Name dropdown when you configure a Bolt command, populated from .dinoai/agents/*.yml on the configured branch.

Run it with Bolt

Trigger the agent from a Bolt schedule using the Run Paradime DinoAI Agent command. See Run an agent with Bolt for the full walkthrough. Because the agent loops over the backlog itself, the schedule is a single command with no wrapper, no poetry install, and no environment variables:

paradime dinoai --agent jira-backlog-agent --message "Process the agent-ready Jira backlog end to end."

On each run, Bolt invokes the agent, which lists the current agent-ready backlog and opens a PR for each open issue. You can also run this same command on demand from the CLI (or interactively with paradime dinoai --agent jira-backlog-agent) to confirm the backlog is picked up before scheduling it. See the DinoAI CLI reference.

Choose a schedule frequency

Pick the cadence that matches how often your team labels new issues as agent-ready:

Cadence	Cron expression	When it runs
Every day at 9 AM	`0 9 * * *`	Monday–Sunday, 9:00 AM
Weekdays at 9 AM	`0 9 * * 1-5`	Monday–Friday, 9:00 AM
Once a week (Monday 9 AM)	`0 9 * * 1`	Every Monday, 9:00 AM
Twice a week (Mon & Thu)	`0 9 * * 1,4`	Monday and Thursday, 9:00 AM
Every 6 hours	`0 /6 * *`	12 AM, 6 AM, 12 PM, 6 PM

For most teams, weekdays at 9 AM (0 9 * * 1-5) is a good default. The agent exits cleanly when there is nothing labelled agent-ready, so there is no cost to running it on days with an empty queue.

After a run, each open agent-ready issue has one PR that closes it, and the agent posts a final summary to #agent-demo listing every issue key with its PR link (or a reason it could not be completed). When there are no agent-ready issues, the agent posts a short note and stops. Review the PRs, resolve any Open questions the agent flagged, and merge.

How it works

The Linear version of this pattern needs an external Python orchestrator to fetch issues and fan out one agent session per ticket in parallel. The Jira agent does not: the orchestration lives inside the agent’s goal. A single session lists the agent-ready backlog and works through it sequentially, so the only thing you run is the agent itself. The trade-off is sequential versus parallel. One session processes tickets one at a time. For a typical daily backlog that is the simpler, cheaper choice, with no infrastructure, no secrets to manage, and nothing to keep in sync with your dbt™ project. If you later need true parallelism across a large backlog, fan out with the SDK (see the Linear backlog agent), but most teams will not need to. The agent works each issue in this order within one session:

1. Lists all open Jira issues labelled "agent-ready"
   → if none, posts to #agent-demo and stops
   → otherwise posts the list of issue keys it will action
2. For each issue, one at a time:
   a. Reads the ticket via get_jira_issue
   b. Explores the repo for existing models/sources that already cover it
   c. Creates a branch: jira-<KEY>-<short-desc>-<5-char-rand>
   d. Implements the dbt™ changes (models, tests, YAML docs)
   e. Commits, pushes, and opens a PR
   f. Posts the PR link to #agent-demo
3. Posts a final summary to #agent-demo — every issue key with its PR
   link, or a reason if it couldn't be completed

Next steps

Linear backlog agent

The same pattern, fanned out one session per Linear ticket.

GitHub Issues backlog agent

The same pattern for a GitHub backlog.

Run an agent with Bolt

Trigger agents from a Bolt schedule.

Programmable Agents reference

The agent YAML schema and tools.

Foundations

Automate with AI agents

Set up & configure

Orchestrate data pipelines

Migrate to Paradime

Develop in Paradime

Learn dbt™

Jira backlog agent

Steps

How it works

Next steps

Linear backlog agent

GitHub Issues backlog agent

Run an agent with Bolt

Programmable Agents reference

​Steps

​How it works

​Next steps

Linear backlog agent

GitHub Issues backlog agent

Run an agent with Bolt

Programmable Agents reference

Steps

How it works

Next steps