Every engineering team has some version of the same ceremony. An engineer finishes a PR, goes back to Jira or Linear, finds the ticket, changes the status from "In Progress" to "In Review," pastes the PR link into the description, and finally moves it to "Done" after the merge. It takes about four minutes. If that engineer ships four tickets a week, that is 15 minutes per week on pure status bookkeeping. Across a team of ten, that is 2.5 hours of engineering time every week doing something a script could handle.
When we built Pylon's ticket integration, we did not start from "let's automate status updates." We started from a different problem: Pylon was opening PRs with branch names like pylon/job-4817 and PR bodies that said "Agent job 4817: patch dependency." That is technically accurate and completely useless to a reviewer who wants to understand what they are looking at.
Reading the ticket, not just the ID
The first thing we changed was how Pylon ingests ticket context at job start. When you create a Pylon job with a Jira issue key or Linear issue ID attached, Pylon does not just store the ID as metadata. It pulls the full ticket: title, description, acceptance criteria if present, labels, and any linked parent epic.
That content goes into the agent's planning context alongside the repository graph. So when Pylon decides what code to change and how to describe those changes, it is working from the same information a human engineer would have at the start of a sprint: what does this ticket actually ask for, in the product team's own words.
The practical effect is visible in branch names and PR titles. A ticket titled "Upgrade payment-service dependency to fix GHSA-2024-4421" produces a branch named pylon/upgrade-payment-service-dep-ghsa-2024-4421. The PR title matches the ticket title almost verbatim because that title is already the right description of the work. We do not try to be clever about generating names. We use what was already written.
State transitions: in progress when the job starts
When a Pylon job begins, we immediately move the linked ticket to "In Progress" (or the equivalent status in your workflow). This is not decoration. It signals to the rest of the team that work is actively happening, and it prevents a project manager from assigning the same ticket to a human engineer who then spends 30 minutes starting the same task.
One thing we are not doing here: we are not inventing a custom "Pylon running" status. That would require teams to modify their workflow configurations before they could use the integration, which creates friction. Instead, we map to whatever "In Progress" equivalent exists in your project's state machine. For Linear that usually means "In Progress." For Jira it depends on your board configuration, so we do a best-effort match against status categories (the "In Progress" category in Jira's data model, not the literal string).
We did consider creating a "Agent Running" status and decided against it. Project boards are already cluttered with custom statuses that nobody agrees on. Adding one more column that only makes sense if you know what Pylon is does not help anyone reading the board.
PR body as ticket artifact
The PR body that Pylon writes is structured to make the ticket connection explicit. The first section is always a link back to the source ticket with a one-line summary. Something like: "Closes PYMT-2204 / Upgrade payment-service stripe dependency from 12.3.1 to 12.9.0 to resolve GHSA-2024-4421."
Below that we include what changed (the file and module scope), why it changed (the vulnerability or requirement from the ticket), what tests were added or modified, and what the reviewer should focus on. That last section is the most important for getting PRs merged quickly. A reviewer who knows "the only risk here is the webhook signature verification path" can check that one thing and approve, rather than reading the entire diff looking for something wrong.
We pull the acceptance criteria from the ticket (when present) and add a checklist to the PR body. This is a small thing but it closes a loop that often stays open: the PM wrote acceptance criteria, but those criteria never made it into the PR review because nobody cross-referenced the ticket. Now the reviewer sees them inline.
Marking done on merge: the webhook side
When the PR merges, Pylon receives the merge webhook from GitHub or GitLab and fires a status update to the ticket system. The ticket moves to "Done" (or your workflow's equivalent closed state).
This is where we ran into edge cases. What if the PR merges but the engineer reverted the changes the next day? What if the PR was a partial fix and a follow-up ticket exists? We handle these by only marking the ticket done if the branch was a Pylon-originated branch on the original Pylon job. If someone manually closes a Pylon-linked ticket or reopens it, Pylon does not try to override that. Human judgment takes precedence over the automation once a human has intervened.
We also handle the case where the PR is closed without merging. If a Pylon PR is closed as unmerged (reviewer rejected it, or the job was superseded), we move the ticket back to the previous state it was in before Pylon started the job. We store that state at job creation time for exactly this reason.
Linear's data model versus Jira's data model
Building for both required us to maintain two separate integration adapters that speak very different APIs. Linear's GraphQL API is clean and predictable. State transitions are explicit objects with IDs. Status categories are well-typed. It was relatively straightforward to build.
Jira's REST API is a different story. The status transition API requires you to know the transition ID, not just the target status name. Transition IDs are per-project, per-workflow, and can change if an admin edits the workflow. We cache the transition map at integration setup time and refresh it when we encounter a transition failure. This has been the single largest source of support tickets in the Jira integration, and it is not something we can fully eliminate because it is a property of how Jira's data model works.
We are not saying Jira's approach is wrong. Workflow customization is one of the reasons large organizations prefer Jira. But building against that flexibility means our integration has to be more defensive than the Linear integration.
What this does not replace
Automated ticket status is not a substitute for sprint ceremonies. When Pylon marks 12 tickets done in a week, you still need someone to review those closed tickets and confirm they actually met the acceptance criteria. Pylon closes the technical work loop. It does not close the product judgment loop.
We built this integration because the four minutes of manual status updating was friction that accumulated across dozens of tickets per sprint. But we designed it to stay out of the way when human judgment is needed. The ticket closes when code merges. Whether that code was the right code to write is still a question for engineers and product managers to answer together in review.
If you run Jira or Linear and want to try the integration, it is available on the Team tier. The setup is about five minutes: connect your project management workspace, point Pylon to the project you want to link, and Pylon starts picking up ticket IDs when you create jobs. No custom workflow states required.