Jira and Azure DevOps in the agent era: what a board needs when half the team is AI
Jira and Azure DevOps are mature, configurable and excellent at what they were designed for: coordinating people. Put autonomous agents on the same board and four built-in assumptions start to leak — that a status change reflects reality, that fields are optional, that work costs only time, and that inaction is visible. This is what each of those needs to become instead.
There is nothing wrong with Jira or Azure DevOps. Both are mature, deeply configurable, and used successfully by enormous numbers of teams. Everything below assumes that, and asks a narrower question: which of their built-in assumptions stop holding when a meaningful share of the work is done by software rather than by people?
Four of them, in our experience. Each is entirely reasonable for a team of humans and quietly wrong for a team that includes agents.
Assumption 1: a status change reflects reality
On a human board, dragging a card to “Done” is a social act. Someone will notice if it is untrue, and there is a person who can be asked. That mechanism is not available to an agent, and the honest consequence is that a status change by an agent means nothing at all unless something outside the agent verifies it.
What it has to become: conditions that are calculated rather than asserted. In Turnado a transition carries conditions like acceptance_criteria_present, ci_green, review_approved, deployed_to_test and test_passed. Each is a plain function of the item’s state, evaluated outside the model. An agent may request a transition; whether it happens is not its call.
Assumption 2: fields are optional because people fill in what matters
Human teams tolerate thin tickets because a developer will walk over and ask. An agent will not walk over. It will infer, and the inference will be plausible and occasionally wrong in a way nobody notices until acceptance.
What it has to become: an item without acceptance criteria cannot leave the first status. Not as a nag, as a gate. And when an agent genuinely does not know something, the correct behaviour is to ask: a question posted on the ticket puts the item on Blocked, an answer takes it off, and the wait becomes a number on the dashboard rather than a feeling.
Assumption 3: work costs time, and time is what you track
Story points, velocity, capacity: an entire planning tradition rests on people-hours being the scarce resource. Agent work costs money per use, and it costs it in bursts that correlate weakly with how large the story looked.
What it has to become: two ceilings at planning time, not one. Capacity in points for the people, budget in euros for the agents, and the sprint proposal has to fit inside both. Every run is then recorded on the work item it was made for — model, duration, tokens, cost — so that “what did this feature cost” is a query rather than an estimate.
Assumption 4: if nothing happens, someone will notice
This is the subtlest one. On a human board, a card that has not moved in four days gets raised in stand-up. With agents there is no stand-up, and the failure mode of an autonomous system is not a crash — it is silence. Everything looks fine; nothing is happening.
What it has to become: inaction needs a first-class screen. Turnado’s queue says how many tasks can be picked up right now and, for everything that stays behind, groups the reason: waiting on a human, a status agents do not act on, the WIP limit, the budget ceiling. Naming the reason is the whole fix.
What not to change
Plenty carries over untouched, and a platform that ignores it is a platform nobody can adopt. Epics, features and stories are still the right hierarchy. Sprints still work. Estimates in points are still the least-bad currency for human capacity. Roles and permissions still matter — more, not less. The lesson of the last twenty years of project tooling did not stop being true because a new kind of actor arrived.
Do you have to migrate?
Not necessarily, and we would rather be useful than acquisitive about it. If your agents only suggest, and a person reviews everything before it lands, an existing tracker with disciplined workflow configuration will hold. The pressure appears when agents start acting: when work moves without a person having touched it, you need conditions that were calculated, permissions an agent cannot widen, and a record of what it cost. Those are hard to bolt on afterwards, because the guarantee has to sit under the integration point rather than beside it.
Can Jira or Azure DevOps be configured to do this?
Parts of it, yes — both have capable workflow engines, required fields and validators. The difference is where the guarantee lives. A rule an administrator can loosen and an API integration can bypass is a convention; a permission set applied in code after roles are resolved, with tests, is a guarantee. Which one you need depends on whether agents act or only suggest.
What is the single biggest gap for agent work?
Cost. Traditional planning has no place to put money spent per work item, so AI usage surfaces as one number on a monthly invoice with no way to attribute it. Attaching the amount to the ticket it was spent on changes what you can decide.
Does Turnado integrate with an existing tracker?
Turnado is the board rather than a layer on top of one, because a guarantee that lives above the integration point can be bypassed through it. What it does connect to is the surrounding delivery chain: Git hosting, CI/CD pipelines, and outgoing webhooks so other systems can follow along.