Part 1: Why agentic workflows must differ from human workflows
If you've built a Jira board that works, the first instinct on adding an agent to your team is a reasonable one: the process is fine, just point the agent at the same columns and let it get on with it. Refinement, ready for dev, in progress, in review, done. Same board, same rules. What could go wrong?
Rather a lot, as it turns out. Not because the board is broken, but because the board was never doing most of the work.
The invisible substrate
If any of that felt uncomfortably familiar, good. That's the substrate.
A human Jira workflow that "works" is almost always propped up by a substrate of things that aren't written anywhere. It's how the team knows that a Do the thing ticket, with a shrug emoticon for a description, is not really ready — even if someone can point to a five-second coffee chat and call it requirements. The team supplies the missing detail from memory, context, and the confidence that someone will ask the obvious question later.
It's how a ticket blocked for three sprints can still be treated as nearly unblocked because "Barry is looking at it", despite nobody having actually met Barry. It's how Code Review can mean a Slack message and a fire emoji, while In Testing means "deployed to production, but I haven't looked at it yet". The status names appear to describe a process; the team's shared understanding quietly supplies the definitions.
It's also how a BA can end up writing requirements after the developer is already in Code Review, perhaps while playing a Nintendo Switch, and everyone treats copied commit messages as a reasonable substitute for acceptance criteria. That isn't merely organisational comedy. It is a team deciding, in real time, what "specified", "reviewed", and "tested" are allowed to mean, then relying on everyone else to remember the decision.
The workflow is a scaffold. The substrate is the team's shared, mostly-implicit understanding of what each status actually means today, who owns each transition, what counts as good enough, and what to do when something's off. The scaffold moves the ticket across a screen. The substrate does everything else.
For a human team, that's fine — they keep chugging. A team of five people who've worked together for a year can operate a board with short, vague status names and no written definitions because the definitions live in their heads and get updated in real time in Slack. The board is the UI for the substrate; the substrate performs the actual work.
An agent has none of this and every place the substrate was quietly doing the work becomes a place the workflow can silently fail.
What breaks the moment an agent walks in
Teams calibrate "ready" through conversation. Agents only read the page. Teams may use a fluid definition, adjusting as work changes. Even with a clear Definition of Ready, people like Sarah and Dave will compare notes: Sarah's sparse ticket may suffice while Dave’s detailed one sparks discussion about actual needs. Humans can adjust; an agent only reads what's written. If the page doesn't state what "ready" means or how much flexibility exists, the agent will invent its own standard, confidently and incorrectly.
"Barry's handling it" is a handoff. Agents have never heard of Barry. An agent sees only the workflow and the content available to it. If a transition does not explicitly identify the next owner, the required action, and the signal that should trigger it, work can sit in Blocked indefinitely, or disappear into an assumed handoff that never happened.
Status names drift to mean whatever the team quietly agreed. Agents never get that memo. An agent cannot safely infer that Code Review means a Slack message and a fire emoji, or that In Testing means deployed but not yet examined. If a status name and its actual obligation diverge, an agent may take a plausible action based on the wrong state.
"We'll sort the spec out after" works for humans, not agents. A development agent must not proceed until the required specification, readiness evidence, and other prerequisites exist; the workflow needs a gate that structurally prevents progress rather than relying on someone to notice the shortcut.
These aren't unusual failure modes. They are the default ways a human-shaped workflow can fail the moment an agent is expected to participate. The workflow didn't get worse. The team's shared understanding didn't disappear. It just stayed implicit — and became invisible to the one new team member that couldn't ask for clarification.
The reframe: status as contract
The way out isn't to lecture the agent into behaving more like a human. It's to move the substrate into the workflow itself, and let the board stop pretending to be flexible.
In an agentic workflow the status stops being a hint about what's going on and becomes the contract for what is legitimate work here. Awaiting refinement doesn't mean "this might get worked on soonish"; it means "a refinement agent may work this item; nobody else may do anything to it yet". Awaiting readiness evaluation doesn't mean "the ticket looks about done"; it means "a readiness reviewer may work this item, and specifically may not write code for it". Awaiting development doesn't mean "someone should probably pick this up"; it means "a development agent may claim this and start writing code, and a readiness marker on the item is the evidence that this is allowed".
Every status has one job: it tells the next actor what they may and may not do. And the answer to "what may I do here?" comes from the status alone — not from the assignee, not from the description, not from the comment that triggered the agent, and not from the prompt.
That last one is the point of the whole series. In a substrate-driven workflow, the prompt is the primary signal — the agent's whole world is the words it was handed, and it does what they say. In a status-driven workflow, the status overrides the prompt. When the prompt and the status disagree, the status wins, and the agent stops. Assignment is not authorisation; a detailed prompt is not a specification. Taken to its logical conclusion: in a mature status-driven workflow, the prompt becomes optional. The contracts already define what the agent can do, and for routine scenarios, there is nothing left for a prompt to add.
That shift is what makes an agentic workflow safe, but it does come with a genuine upfront cost. New statuses take design work. Onboarding a new phase means writing the contract before you can use it. There's less room for the ad-hoc exceptions that human teams resolve in a quick conversation or standup. That's real, and worth calling out. But human workflows aren't actually cheaper. They trade that upfront design cost for ongoing friction, course-correction, and shared context that lives in people's heads rather than the system. The "definition of ready", the team interaction contracts, the documented process norms... these are the human equivalent of status contracts. They just tend to be overlooked and quietly treated as process noise. The reframe doesn't introduce rigidity. It makes the rigidity that was always there visible, and deliberate.
The refinement stage: from labels to statuses
Refinement is the stage where a raw backlog item is shaped into a clear, actionable task — acceptance criteria written, ambiguities resolved. Whether it's actually ready is a separate question, answered by a separate agent.
A concrete way to see the shift: this project used to run refinement as a label. A ticket in Backlog with a needs-refinement label was the refinement agent's queue. The agent picked one up, shaped it, added acceptance criteria, replaced the label with refined, and left it in Backlog for someone to notice.
That worked, sort of. It also produced a class of quiet failure that took a while to spot. The label was a hint: a human could see it and understand what state the item was in. An agent could too, as long as it thought to look. But nothing about Backlog the status required anyone to look. Items sat with mixed labels; labels drifted; a second agent occasionally started working the item before the first had finished, because the label hadn't been updated yet and the ticket looked available. A human would have caught it; the substrate would have caught it. There was no substrate.
On 21 August 2026 we converted refinement from a label-driven stage into a claim-based stage with statuses of its own. Awaiting Refinement, In Refinement, and a specific transition to claim the item. The label went away. The substrate wasn't reinstated; instead the workflow started carrying the state itself. An item in Awaiting Refinement is the analyst's inbox. An item in In Refinement is actively being shaped, by exactly one agent, right now. If a second agent arrives, the status tells it, before it reads a word of the item, that the work here is already claimed.
Nothing about the content of refinement changed. The agent still reads the item, still adds acceptance criteria, still respects the same three tiers of authority (we'll get to those in a later article). What changed is that the workflow now says, structurally, who may do what, and the label the human eye used to interpret is gone, because there's nothing left for it to compensate for.
This is the shape of the whole exercise. You don't get to a working agentic workflow by adding rules on top of a human-shaped board. You get there by walking through the board and asking, of every column, what were the humans doing here that the board wasn't? — and moving those things, one at a time, into the workflow itself.
Two paths. One of them works.
The exercise of walking every column and asking what the humans were doing that the board wasn't is also the diagnostic for what goes wrong when you skip it.
There are, roughly, two ways to add agents to a Jira workflow, and the difference between them is where the substrate lives.
The first is to hand the agent your existing board and a rich prompt, and hope the prompt carries enough of the substrate to get you through. It won't. The prompt is arbitrary text from whoever last invoked the agent; the workflow is system state that every actor can read. On any invocation path where the two disagree, one of them has to win — and the failure mode of "the prompt wins" is that a well-written mention on a ticket that isn't ready produces a PR eight minutes later against a spec that doesn't exist. That has happened here more than once, and the whole design of this series builds outward from why.
The second way is to take the reframe seriously. If the status is the contract, then the consequences of path one are predictable: you've handed the agent a board full of hints and asked it to infer the rest. It will. Confidently. The consequences of path two are also predictable: an agent that hits a status it can't act from stops, says so, and waits. That's not a failure. That's the workflow doing its job.
The rest of this series is about building the second kind.
What the rest of the series does
None of these are new agile ideas. Author-reviewer separation, standardised handoffs, explicit readiness bars — human teams have been reinventing these for decades and mostly getting away with skipping them. For an agentic team you don't get to skip them. The substrate is gone; the workflow is all that's left.
Here's what the remaining ten articles get into, one mechanism at a time:
-
Status supremacy — why "status wins" is the operative rule, and what happens when a well-behaved agent enforces it against a well-written prompt.
-
The intake gate — how you make the substrate-check happen on every path an agent can be invoked on, not just the one that carries instructions.
-
Skills as roles — how analyst, reviewer, developer, and auditor stop being cultural labels and become discrete skill files with their own authority and exit conditions.
-
The three-tier authority model — how an agent decides, per question, whether to act silently, decide-and-record, or escalate.
-
Don't mark your own homework — why the author of a spec cannot also be its auditor, and how the workflow enforces that separation.
-
Documentation as contract — how comments stop being conversation and become critical state.
-
Code-colocated docs vs. Confluence — why the docs an agent needs to act on live next to the code, and Confluence stays primarily for humans.
-
The commitment boundary — where humans stay sovereign, and how the workflow makes that line visible rather than assumed.
-
Bulk-loading a backlog with an agent — what it looks like once all of the above is in place, at scale.
-
Anomalies and downstream catches — the failure modes worth designing for, and the one class of act you still design against.
That's a lot more prescriptive than most human boards, and if you've spent years trimming your workflow down to as few statuses as possible, it will feel like a step backwards. It isn't. It's the same information the humans were already carrying, but now it's written down, in the one place that every actor, human or otherwise, has to consult before doing anything.
Try this before the next article
Open your team's Jira board and pick a single status. Any of them. Now write, in one sentence, the answer to this question:
"Who may do what to an item in this status, and by what evidence do they know they may?"
If you can't answer it in one sentence, that's where your substrate is living. Which is fine — for a human team. The moment the next actor to touch that item is an agent, it isn't fine anymore.
Next: Status supremacy — why the workflow beats the prompt. A ticket that gets built and merged while its spec is still being written, a readiness review that arrives thirteen minutes too late, and the principle that would have prevented both of them.
Was this helpful?
Thanks!
Ben Spillane
2 comments