Skip to content

PATTERN Cited by 1 source

Jira status transition triggers agent workflow

Intent

Use a Jira workflow status transition as the trigger for an AI agent run, with the transition's automation passing a custom system prompt to the agent. Status changes carry both "approval to start" (a human moved the work item to the agent lane) and "how to do this kind of work" (the per-procedure prompt encoded in the transition automation).

Canonical articulation

"To ensure accountability and code quality we've designed a human-in-the-loop system. An engineer can review the work items created, then delegate the work to an agent by updating the status — triggering a workflow that passes a custom system prompt to the agent with cleanup instructions." (Source: sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in)

The implementation surface is Atlassian's documented Add an agent to workflow transitions feature — Jira-Cloud-native agent integration on transition events.

Shape

   Work item created (cron or alert pipeline)
              │
              ▼
   Status: Open / Awaiting Review
              │
              │  ── ENGINEER reviews work item
              │     decides this is real work
              │     transitions status
              ▼
   Status: In Progress / Delegated to Agent
              │
              │  ── TRANSITION AUTOMATION fires:
              │       1. Read work item fields
              │       2. Compose custom system prompt for this procedure
              │       3. Invoke agent with prompt + work item context
              ▼
   Agent runs (investigation + diagnosis + draft PR or comment)
              │
              ▼
   Status: Awaiting Review (agent transitions on success)
              │
              ▼
   Engineer reviews draft PR; merges
              │
              ▼
   Status: Done

Three things the transition carries

  1. Human approval / gate. The transition itself is the engineer's "this is real KTLO work, give it to an agent" signal. Without the manual transition, no agent runs.
  2. Custom system prompt. Each transition automation can inject a different system prompt — flag-cleanup transitions carry cleanup instructions; flaky-test transitions carry triage-or-fix instructions; vulnerability-fix transitions would carry remediation instructions.
  3. Workflow-state contract. The agent's status transitions on completion (Awaiting Review or Done) are visible in the same Jira UI the human uses, so the work item's lifecycle stays one state machine — not split across Jira and a separate agent dashboard.

Why a status transition (vs. a webhook or button)?

Trigger mechanism Pros Cons Atlassian's choice
Webhook on field-change Fully automated No human gate; no obvious "approve" moment Rejected — needs human review
Custom button on work item Explicit human action Diverges from the workflow state machine; reviewers see "button pressed" not "status: in progress" Not used
Status transition Reuses existing workflow UX; engineer's mental model is unchanged; per-transition prompt customisation; visible in the work item history Requires workflow editing Chosen

The status-transition mechanic preserves the work item as the single source of truth for lifecycle state, which composes cleanly with reporting / SLAs / dashboards built on Jira workflows.

Per-transition system prompt customisation

A single Jira project can have multiple transitions wired to different agent prompts — the prompt is part of the transition config, not the project config. Atlassian's flaky-test workflow hints at multiple stages:

  • Triage transition — "verify whether the issue is real using a custom prompt. If it looks like a false positive, the agent can stop and summarise that outcome, commenting on the original Jira work item."
  • Fix transition — implicit; once triage classifies the issue as reproducible, the agent (or workflow) advances to a fix stage with a different prompt and skill dispatch.

This multi-transition / multi-stage decomposition is what makes the agent's exits bounded (concepts/agent-as-first-pass-investigator) — each transition has its own prompt and its own allowed exit options.

Composes with

Operational outcome

"We built a system in Jira to automate the bulk of this work. So far, it's responsible for more than 500 merged PRs in the past 70 days." (Source: sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in)

≈ 7 merged PRs/day on the Jira repo from the stale-feature-flag cleanup workflow alone — every one of those PRs began with a status transition.

Caveats

  • Engineer must remember to transition. If the work-item backlog is large, transitions become the bottleneck. Atlassian doesn't disclose how engineers prioritise the transition queue.
  • Transition automation is a single point of compromise. If the system prompt encoded in the transition is poisoned (e.g. by a compromised admin), every subsequent agent run executes the poisoned prompt. Prompt-injection-via-comment is a related risk worth modeling.
  • Agent failures don't always advance state. When the agent errors out mid-run, the work item can sit in "In Progress" forever. Operational hygiene (timeout, watchdog, alarm on stuck transitions) is needed but not described.
  • Custom prompts drift over time. When the per-codebase cleanup conventions change, the workflow transition prompt must be updated; this is governance work the post does not describe.

Sibling on other ticketing substrates

Adjacent implementations on non-Jira substrates:

  • GitHub Actions on issue label — adding a claude or cursor-agent label triggers a workflow that runs the agent.
  • Linear webhook → Cursor / Devin — issue status change invokes an agent.
  • GitLab pipeline triggered by issue update — same shape.

The status-transition-as-trigger discipline generalises; the work-item-as-prompt + transition-as-trigger pair is the wiki-canonical shape, demonstrated first-party at Atlassian.

Seen in

  • sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in — canonical wiki source. "An engineer can review the work items created, then delegate the work to an agent by updating the status – triggering a workflow that passes a custom system prompt to the agent with cleanup instructions." Used in production for stale-feature-flag cleanup (500+ merged PRs in 70 days) and flaky-test triage / fix (≈80% reduction in eng hours; ≈ 1 eng-week saved per month).
Last updated · 542 distilled / 1,571 read