Every previous post built the worker: an agent loop with tools that runs isolated in a real repo, reproduces the bug with a test, and ships a pull request. What was missing is what starts it and what reports back when it finishes. This post is that wrapper: making a Jira ticket trigger the whole system without anyone pressing a button, processing it exactly once even if the trigger repeats, running it in an ephemeral workspace per ticket, and returning the result as a PR and a comment on the ticket itself. It’s where the series lands: the agent stops being something you run by hand and becomes a service that reacts to tickets.
TL;DR
- The trigger doesn’t run the agent: it only enqueues. A Jira webhook gives low latency but drops events; JQL polling is slow but loses nothing. Use the webhook to react fast and polling as the net that recovers what the webhook missed.
- The property that holds everything together is idempotency: process each ticket exactly once. You get it with persistent state in a database and an atomic claim, not with an in-memory flag that’s lost when the process restarts.
- Each ticket runs in its own ephemeral workspace (the worktree from the previous post) and the output is a PR plus a Jira comment with the link. A person still decides the merge.
What changes when you make it autonomous
Up to the previous post, the agent was a program you invoked: you handed it a goal, it ran in its worktree, opened the PR, and finished. Someone had to start it. Making it autonomous is removing that manual start: the system watches a source of work—a queue of Jira tickets—and, when one shows up marked as ready, it processes it on its own.
The change isn’t in the agent, which is still the same loop with the same tools. It’s in the three pieces around it: something that learns there’s work to do (the trigger), something that guarantees that work is done once and isn’t lost if the process crashes (the stateful queue), and something that returns the result to where the request was born (the Jira comment). The agent does the work; this post builds what connects it to a real input and a real output.
Before (manual) Now (autonomous)
you ──► runAgent(goal) Jira ticket ──► trigger ──► queue
│ │
▼ ▼
PR worker ──► agent ──► PR
│
▼
comment on Jira
Enter fullscreen mode Exit fullscreen mode
The word “autonomous” is scarier than it should be, and it also overpromises. It’s not that the agent decides what to do about the business; it’s that nobody has to copy the ticket text and launch the process by hand. The criterion of what gets done is still set by a person when they mark the ticket, and the criterion of what gets integrated is still set by whoever reviews the PR. Autonomous here means “no intervention in the middle,” not “no control.”
It’s worth being honest about what this system is not: it doesn’t plan, doesn’t prioritize, doesn’t coordinate some tasks with others, doesn’t remember anything from one ticket to the next, and doesn’t orchestrate dependencies between them. It’s a worker that reacts to a queue, one ticket at a time. Everything that follows is the infrastructure that makes that reaction reliable—so the work isn’t lost or duplicated—not an intelligence that decides on its own. If you expect planning or coordination, this isn’t that system; it’s the step before, and it’s the one almost everyone needs first.
Keep reading
That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:
Read the full post on ramonchancay.me →
Originally published at www.ramonchancay.me/blog/from-a-jira-ticket-to-a-pull-request.