From a Jira ticket to an agent run
- date
- category
- AI Agents
- also in
- Automation · Engineering Practices
- reading
- 2 min / 371 words
Let's start with one real flow.
We have a role:
Implementer Agent
Its goal is simple:
take the task
|
v
understand the requirements
|
v
change the code
|
v
run the tests
|
v
open a PR
This is still one agent.
Tests, commit and PR are steps of its workflow, not separate agents.
A separate agent would only show up with a different role, e.g.:
Implementer Agent
Reviewer Agent
Release Agent
How does the agent know it should start?
It should not search Jira every minute and guess which ticket is its own.
An explicit event is better.
Example:
Jira issue
status: Ready for AI
|
v
Jira Automation / webhook
|
v
call to the Implementer Agent endpoint
The payload can look like this:
{
"issueKey": "PAY-123",
"repository": "org/payments-service",
"baseBranch": "main"
}
This splits two responsibilities:
event / trigger
-> when to start the agent
agent
-> what to do once started
What happens next
The agent receives PAY-123.
It does not need the whole ticket in the payload.
It can call a Jira tool:
jira.get_issue("PAY-123")
and fetch:
- description,
- acceptance criteria,
- labels,
- dependencies,
- comments.
Flow:
PAY-123
|
v
Jira tool
|
v
full task description
|
v
Implementer Agent
Where we configure it
Jira
A rule:
WHEN:
issue moved to "Ready for AI"
THEN:
send webhook
Event layer
Passes the payload to the agent endpoint.
It can be:
- Jira Automation,
- a webhook,
- Azure Function / Logic App,
- AWS Lambda / EventBridge,
- GCP Eventarc / Cloud Run function.
Agent repo
Does not define when it should start.
It defines what to do after start:
1. fetch the ticket
2. prepare the workspace
3. implement the task
4. test
5. PR
Tools on the market
| Need | Azure | AWS | GCP | Independent |
|---|---|---|---|---|
| Event / routing | Event Grid, Functions, Logic Apps | EventBridge, Lambda | Eventarc, Cloud Run functions | Jira Automation, webhooks |
| Agent runtime | Microsoft Foundry Agent Service | Amazon Bedrock AgentCore Runtime | Vertex AI Agent Engine | your own runtime |
| Jira integration | MCP / API / tool gateway | MCP / AgentCore Gateway | MCP / Agent Gateway | Atlassian API / MCP |
What the organization level changes
With one agent you can wire up a webhook by hand.
With many teams it is worth standardizing:
- the status or label that starts the agent,
- the payload format,
- the ticket -> repo mapping,
- how agents are invoked,
- the identity of the caller.
That way different teams can use the same pattern instead of each building its own start mechanism.