We accidentally built our own version of Jira’s AI workflow

Atlassian’s new pitch for Jira is built around AI agents: you turn ideas into agent-ready tasks, assign them to a coding agent (theirs or anyone’s), watch what the agent did, and review it before anything lands. Their line is “Any agent. Any model. One team.”

Reading that page felt oddly familiar, because it’s our board. We’ve been running that exact workflow on a production build since spring, and we never planned it that way; we were just trying to ship.

We put AI coding agents on the delivery work early in the engagement, and every piece of what Atlassian now sells as a workflow arrived as a fix for a specific problem.

The agent needed work assigned to it, so it got a named account in our tracker, sitting in the assignee dropdown between two human engineers. Vague tickets came back as plausible nonsense, so we added a tag: no ticket reaches the agent until a human marks the specification complete enough to build against. Atlassian calls this “agent-ready tasks”, which is a better name than ours, though ours was on our board first. Generated code still needs a human to check it, so the board has a hard rule: nothing merges without review, and the agent has no path around that column.

The fourth fix is the one that mattered most. A ticket on its own was never enough context, so the agent works from the same documents the humans do: architectural decision records, a glossary held in the repo, house voice rules, acceptance checklists. Atlassian calls their version of that a Teamwork Graph. Ours is a folder of markdown files, written for people and useful to the agent for the same reason it’s useful to a new engineer – it says which decisions were already taken and why.

Nobody signed off on a platform along the way. They signed off on fixes, roughly one a week.

The number on Atlassian’s page worth taking seriously is this one: agents produce 44% better output, using 48% fewer tokens, when the task arrives with real context. That’s Atlassian’s own research about Atlassian’s product, so keep that in mind, and it happens to be the core of our whole argument. The bottleneck we keep running into is what you hand the model.

It also matches what we see on the board every week, which is duller than a study and harder to argue with. The tickets that come back clean are the ones where somebody did the thinking before the agent started, and the ones that come back plausible and wrong are the ones where nobody did. A gate and a review column exist to change which of those the workflow rewards.

Atlassian productising this is good news. When the biggest tracker vendor teaches the market that agents need specification, context and review, everyone who works this way benefits. If your organisation lives in Jira, their tooling will make the mechanics easier, and we mean that without irony.

The first of the two things the product can’t ship is the agent-ready task itself. The tooling gives you the tag, and it can’t write what’s behind the tag. What makes a specification complete enough to build against is falsifiable acceptance criteria, the decisions it must respect, and the things that must not change. That last part never comes from a tool, because the reasons live outside the repository. It’s like the handover notes for a house – the form has a box for which walls are load-bearing, and only someone who knows the building can fill it in. Someone who has watched a system like yours break has to write it down, and their 44% figure is a measurement of exactly this gap.

The second is portability, which is the accidental advantage of never having built a platform. Our workflow lives in documents and gates instead of software. The tracker happens to be ClickUp at the moment, because it fits the engagement, and it would run the same on Jira or Linear. The repos happen to be on GitHub, and nothing changes on GitLab. Whatever model ships next, the workflow doesn’t notice it, because it sits behind the same gate as the last one. We have nothing against anyone’s platform. We just never had the option of depending on one, because we work inside our clients’ stacks, whatever they are.

If you’re on Jira, buy the tooling – it’s the cheapest part of the equation. Then look at your backlog and ask how many tickets you could tag agent-ready today with a straight face. On our board, the first time we asked that question, the answer was uncomfortable, and fixing it improved the human engineering too.

We wrote up how the workflow runs in more detail, including the part where the agent started filing cleanup tickets we’d been walking past for months. And if you’re somewhere between a prototype and a system right now, that gap is where our Production Readiness Review starts – ping us.