Jira change request agent

The Jira change request agent watches a Jira ticket type, works out which file in your repo each ticket is about, and checks the request against your warehouse data before touching anything. Every ticket ends in one of two states: a pull request linked to the ticket and ready for review, or an escalation comment with the specific question a human needs to answer. You build it entirely in the Agent UI (no YAML) and run it daily with Bolt’s native Run Paradime DinoAI Agent command (no API keys). This pattern fits any queue where tickets describe changes to code that lives in a predictable place: per-customer SQL logic, mapping tables, configuration files, or dbt™ models owned by a support or operations team.

Prerequisites

Jira connected so the agent can list tickets, comment, and change statuses.
Your repository connected so the agent can branch, commit, and open PRs.
A warehouse connection the agent can query read-only (it validates requests with run_sql_query).
Optional: Slack connected for run summaries.
Your Jira workflow must allow moving tickets from Open to In Progress, and from there to Ready for Review and Needs Review (or your equivalents). If a status isn’t reachable, the agent’s transitions will fail.

Estimated time: 20 minutes.

Steps

Agree the conventions

The agent needs three conventions it can rely on. This guide uses example values; swap in your own everywhere they appear in the next step.

Convention	Example used in this guide
Which tickets to pick up	Issue type `Change Request` in status `Open`
How a ticket maps to a file	The ticket title starts with the entity name before `//` (for example `acme-corp // exclude test accounts`), and the code lives at `sql/<entity>/` in the repo
Ticket lifecycle	`Open` → `In Progress` (agent working) → `Ready for Review` (PR opened) or `Needs Review` (agent blocked)

Putting the ticket key in the branch name and PR title means Jira’s GitHub integration links the PR to the ticket automatically.

Build the agent in the Agent UI

In the Agent app, open Agents, select New agent, then Start from scratch. See Build an agent in the UI for a tour of the builder. Fill in the fields:Name: jira-change-request-agentRole:

Change request maintainer. You turn "Change Request" Jira tickets
into review-ready pull requests, and escalate tickets you cannot
resolve with confidence.

Goal:

1. List all Jira issues of type "Change Request" in status "Open".
   If there are none, stop.

2. For each ticket, one at a time:
   a. Move the ticket to "In Progress".
   b. Identify the target: the entity name is the ticket title text
      before "//", and its code lives at sql/<entity>/ in the repo.
   c. Read the current code for that entity. If it does not exist,
      treat the ticket as blocked (step f).
   d. Draft the change the ticket describes. If the ticket is
      ambiguous, run read-only SQL against the warehouse to inspect
      the relevant tables and infer the intent. Record what you
      queried and what you found.
   e. If you are confident: create a branch
      change/<TICKET-KEY>-<short-desc>, apply the change, commit,
      push, and open a PR titled "<TICKET-KEY>: <summary>". The PR
      body must explain what changed, why the data supports it
      (citing the tables and columns you checked), and any
      assumptions under an "Open questions" heading. Move the
      ticket to "Ready for Review" and comment the PR link on it.
   f. If you are not confident after checking the data: do NOT open
      a PR. Comment on the ticket with what you found and the
      question a human needs to answer, then move the ticket to
      "Needs Review".

3. Post a summary of every ticket and its outcome to Slack.

Backstory:

You are a careful maintainer, not a creative one. Only ever edit the
files that belong to the entity named in the ticket, and match their
existing style. Never invent tables or columns: verify every object
you reference exists via a read-only query. Never write to the
warehouse. When the ticket and the data disagree, or the data cannot
support the request, that is a "Needs Review" outcome, not a guess.
One ticket = one branch = one PR.

Model: leave Auto selected.Allowed tools (everything else is refused, see the Tools Reference):

get_jira_issue, list_jira_issues, update_jira_issue, add_jira_comment
read_file, write_file, search_files_and_directories, ripgrep_search
run_sql_query
run_terminal_command
post_slack_message

Output: pick the Slack channel for run summaries, or leave empty (messages then land in the Bolt run logs; also remove post_slack_message and the Slack step from the Goal).

If the code lives in a different repository than the one connected to your workspace, add list_accessible_repos and clone_additional_repo to the allowed tools and prepend a Goal step telling the agent to clone that repo and work inside the clone. The agent can clone any repository your GitHub integration grants access to.

Deploy and test it with a chat

Select Deploy, then Just here: the agent is saved to the workspace and live immediately. (Once it settles, redeploy via Open a pull request to version-control the definition, see Creating Agents in the App.)With one known-good ticket in Open status, hover the agent card, select Chat, and send: Process the open Change Request ticket queue end to end. Confirm the status transitions, the branch and PR, and the ticket comment all land before scheduling it.

Schedule it with Bolt

On the Agents page, hover the agent card and select Schedule. This opens a new Bolt schedule with the Run Paradime DinoAI Agent command already added and the agent pre-selected.

Task: Process the open Change Request ticket queue end to end.
Select Save command, set the trigger to a cron such as 0 9 * * 1-5 (weekdays at 9 AM), and deploy.

The command runs natively inside Paradime, so there are no API keys or environment variables to configure. The agent exits cleanly on an empty queue, so a daily run costs nothing when there are no tickets.

After a run, every ticket that was in Open ends in Ready for Review with exactly one linked PR explaining the change from a data standpoint, or in Needs Review with a comment specific enough to answer without re-deriving the context. No ticket is left in In Progress. The most likely failure is a Jira transition error, which means a target status isn’t reachable from the ticket’s current status in your Jira workflow. Check the run transcript in the agent sessions panel.

How it works

The agent’s defining behavior is the validation gate: it only opens a PR when it can ground the request in your actual data, and everything else becomes a precise question back to the ticket instead of a guess. That means reviewers only ever see PRs with evidence attached, and unclear tickets surface immediately rather than after a wrong change ships.

1. List Jira issues: type "Change Request", status "Open"
2. Per ticket:
   a. Transition to "In Progress"
   b. Resolve the entity from the ticket title, locate its code
   c. Draft the change; if ambiguous, read-only SQL to infer intent
   d. Confident   -> branch, PR (key in title and branch),
                     data reasoning in the PR body,
                     transition to "Ready for Review"
   e. Not confident -> comment findings + specific question,
                     transition to "Needs Review"
3. Post run summary to Slack

Like the Jira backlog agent, the orchestration lives inside the agent’s Goal: one session works the queue sequentially, so there is no wrapper script or orchestrator to maintain. What this template adds is the status lifecycle (tickets always land in a terminal status) and the escalation path for requests the data does not support.

Next steps

Jira backlog agent

The label-driven variant: implement dbt™ models from agent-ready issues.

Run an agent with Bolt

Everything the Run Paradime DinoAI Agent command can do.

Triggering from Bolt reference

Every field of the command and the run lifecycle.

Tools Reference

What every tool id in the allowlist does.

Foundations

Automate with AI agents

Set up & configure

Orchestrate data pipelines

Migrate to Paradime

Develop in Paradime

Learn dbt™

Jira change request agent

Steps

How it works

Next steps

Jira backlog agent

Run an agent with Bolt

Triggering from Bolt reference

Tools Reference

​Steps

​How it works

​Next steps

Jira backlog agent

Run an agent with Bolt

Triggering from Bolt reference

Tools Reference

Steps

How it works

Next steps