Part 2: Status supremacy: why the workflow beats the prompt
The last article ended on a claim: in an agentic workflow, when the prompt and the status disagree, the status wins and the agent stops. This one is about why.
It's the single most counter-intuitive rule in the series. Modern agents feel most competent when they're following a rich, specific prompt — that's when they answer confidently, cite their sources, and produce clean output. The instruction "distrust the prompt in front of you, and defer to a five-word enum on a Jira ticket" cuts against everything the agent is optimised for. Jira wins. And yet.
Two real failures made the case for me, both from this project's own board. Neither of them was the agent behaving badly. Both were the agent behaving reasonably, in a workflow that had left it no way to know it shouldn't.
CLIGUI-45: thirteen minutes too late (the reviewer was still reading)
The clearest one first. The ticket was in In Readiness Evaluation — the queue for the readiness reviewer, an independent auditor whose job is to say whether the specification is good enough to be worked on. The reviewer had claimed it. The reviewer was reading.
What happened next, straight from the work item’s change log:
|
Time (UTC) |
Event |
|
04:02 |
Item transitioned to |
|
05:14 |
PR #25 opened — the item fully implemented |
|
05:15 |
Comment: "Implemented and opened a PR… none of this workflow's available transitions map to 'implementation complete'" |
|
05:23 |
Item transitioned to |
|
05:27 |
Description edited — acceptance criteria added |
|
05:28 |
Readiness comment posted, item transitioned to |
A development agent, invoked with a prompt describing the item, built the entire piece of work and opened a pull request against main — while the ticket sat in a status that explicitly means "a readiness reviewer may work this item, and specifically may not write code for it". It then noticed, from inside its own completion comment, that the workflow had no transition it could use to mark the work complete. The reason it had no such transition is that from In Readiness Evaluation no such transition can exist — the item isn't in a "may be built" state at all.
The acceptance criteria that the reviewer's checklist said had to exist were added to the description four minutes before the reviewer signed off — well after the code that was supposed to implement them.
The agent did nothing wrong at any step. It was handed a prompt — not even a particularly detailed one — but that barely mattered: it also had an unrefined card in front of it, and it would make something of that regardless. The prompt implied the work should be done. The agent did the work. That is exactly what a good prompt-following agent is supposed to do.
Nothing in the invocation told the agent to check where the item was.
CLIGUI-40: eight minutes after assignment
Same shape, different entry path. An item sat in Awaiting Refinement — the requirements analyst's inbox. The item had a summary, some context in the description, and no acceptance criteria at all. Refinement is the phase whose entire job is to produce acceptance criteria; the ticket sitting in that status without any is the norm, not an anomaly.
Someone assigned the item to a development agent. Eight minutes later there was a pull request.
Eight minutes is not enough time to notice that the item was in a phase that hadn't happened yet. It isn't enough time to read the description carefully, to search the repo for prior art, to check whether the thing being asked for was even the right thing to build. The agent didn't need any of that time, because as far as it knew, being assigned was the same as being told to build.
Assignment was not authorisation. The workflow said so, structurally. The agent had no way to know.
The two failures have the same shape
Both agents behaved reasonably. Both had prompts that made sense read alone. Both produced work that looked, on inspection, roughly like the thing being asked for. In neither case was the model at fault.
A better model would have done the same thing faster.
What broke, in both cases, was the same assumption: that the prompt in front of the agent was authoritative about what should happen next. In a human workflow that assumption is defensible. A human who receives a well-written request from a colleague usually can assume the request has been signed off on somewhere else — the colleague wouldn't be asking if it hadn't. Prompts are proxies for social permission.
For an agent, that sign-off chain isn't visible. A request may have been rubber-stamped somewhere upstream, but the agent cannot tell the difference between that and a considered decision by the team. Anyone with comment permission on the item can invoke an agent by @mention. Anyone with edit permission can assign it. Anyone with a keyboard who's just a wee bit keen, can type 'please implement this' into an Agent panel. On a Monday morning, someone will. None of those actions represent a considered decision by the team; all of them look, from the agent's perspective, identical to a considered decision by the team.
The workflow, by contrast, does distinguish. The status is set by transitions, and transitions have rules. An item cannot be in Awaiting Development without having passed through readiness. An item in Awaiting Refinement has not been shaped yet, by definition. The status is not a hint about what someone probably wants; it's a fact about what the team's process has actually agreed to.
The prompt is arbitrary text from whoever could type. The status is system state. Where they disagree, the status wins.
One objection worth naming before moving on: what if the status itself is wrong? A human might have miscategorised the ticket; the workflow might have a bug. The agent's job is to enforce the workflow as it stands — correcting a wrong status is a human action, not an agent inference.
The principle, stated plainly
Every principle in the workflow design document underneath this project could be summarised as: make the workflow authoritative, and everything else follows. The first of them (principle P1 in the doc, worth stating once here) is the basic form of the rule this article is arguing for:
P1. Status is authoritative; the prompt is not. A mention is arbitrary text from anyone who can comment. The status is system state. Where they disagree, the status wins and the agent says so rather than complying.
Everything about the workflow's shape falls out of that one rule. The intake gate (next article) exists because P1 has to be enforced on every entry path — not just the ones that carry instructions. The three-tier authority model (article 5) exists because what the agent may decide has to be answerable from the workflow alone rather than from a judgement call. Marker comments (article 7) exist because P1 requires structural evidence rather than simple paragraph text. Every guardrail in every skill file in this project traces back to P1. All of it.
The rule is simple. Its enforcement is what the rest of the series is about.
The balancing rule: not all transitions are equal
If P1 were the only rule, an agentic workflow would grind to a halt — because every forward transition would need a human to fire it, on the grounds that agents can't be trusted to advance the state. That's not right either. The balancing principle in the design doc — call it P2 — is subtler:
P2. An agent may fire a forward transition when a downstream stage independently verifies its work.
Handoff for reviewis safe because review exists.FinaliseandCancelare human-only precisely because nothing follows them.
This is what keeps the workflow moving. A refinement agent can fire Handoff for readiness evaluation on its own, because the readiness reviewer will independently audit the work and can send it back. A development agent can fire Handoff for review on its own, because review will audit the code against the specification. A bad handoff costs a downstream actor's time; it doesn't cost correctness, because the downstream actor is looking.
The transitions that are human-only aren't human-only because a rule says so. They're human-only because no stage follows them. Once an item is finalised, or cancelled, there's nobody to catch a mistake. So finalise and cancel are commitments — and commitments belong to humans. (Article 9, on the commitment boundary, is entirely about that class of decision.)
The nice property of stating the principle this way is that it tells you what to do when you add a new phase. If your new phase has an auditor downstream of it, its exit transition can be agent-fireable. If it doesn't, its exit transition can't. You don't have to argue about it; the principle answers.
What "status wins" looks like from inside the agent
The first thing to notice is that "the status wins" doesn't mean "the agent silently ignores the prompt". Silent refusal is worse than compliance, because the invoker can't tell what happened. If the agent decides the prompt disagrees with the status, its job is to say so, out loud, in the same comment it would otherwise have posted, and stop.
Something like:
This item is in Awaiting Refinement. From this status the legitimate work is refinement — shaping the specification and adding acceptance criteria. The invocation asks for implementation, which is not legitimate here. If you meant to route this to development, the item first has to pass refinement and readiness evaluation. Not taking action.
Three things are doing work in that response. It names the status. It names the work the status permits. It refuses the requested work and says why, without editorialising and without an apology that implies room for negotiation. The invoker knows exactly what happened and what to do about it — either move the item through the missing phases, or if the invoker disagrees with the workflow's shape, that's a conversation for humans, not for the agent to have on their behalf.
The tone matters here more than it usually does in agent design. An apologetic refusal ("I'm sorry, I can't do that right now, would you like me to try…?") reads as the agent might come around; it's the workflow equivalent of a bouncer asking if you'd like to try a different door. Every downstream reader will interpret it that way. A structural refusal reads as the workflow said no, and the agent is a messenger — which is exactly what it is.
Designing the workflow so P1 can be enforced
A workflow can only be authoritative if it carries enough information to be authoritative. That sounds circular until you look at a real board and see how often the answer to "what does this status mean?" is "the team knows". For agents that isn't a workable answer. So a status-supreme workflow has a few structural properties that a convention-driven (the kind where the team just knows) one doesn't need:
Reckon your workflow is ready to be authoritative? Here's a few things to keep in mind.
-
Every status has a one-sentence, agent-readable answer to "Who can do what to an item in this status, and how do they know they're allowed to?" If the answer requires a paragraph, the status is doing too much and should be split. The clearest test I know of: can a new team member (or agent) read the status name alone and be right about it more than 80% of the time? If not, the name is misleading and humans are likely filling the gap (or leaping over it).
-
Claim-based work-in-progress statuses. The distinction between Awaiting X (queue) and In X (claimed, being worked) is not cosmetic; it's the difference between "the work is available" and "the work is happening, by exactly one actor". A workflow without that distinction cannot enforce single-owner claims without side-channels.
-
Handoff transitions that name the destination, not the action. Handoff for readiness evaluation forces the transition to encode what happens next. Ready — a common human-workflow verb — does not. Name transitions after what happens next, not after how the previous stage ended.
-
Match on ids, not names: the workflow will trip on its own renames. Agents read history, and history contains every previous name of every renamed status, still fossilised at the point the transition fired. A workflow that expects agents to match by name will discover this the hard way, and 'the hard way' in this context has a change log entry and a PR number.
None of these are exotic. They're what falls out of taking P1 seriously — the workflow has to carry, structurally, the information the agent will otherwise substitute a guess for.
What this asks of the invoker
There's one more implication worth naming, because it's easy to lose in the discussion of what the agent does. Status supremacy also constrains the human. It means an @mention on an unrefined ticket doesn't get anyone anywhere. It means an assignment to a development agent, on an item that hasn't passed readiness, will produce a polite refusal and nothing else. It means the shortcut of "please just implement this" no longer works, because the workflow itself has become the thing that decides what "this" is.
That's a feature. Every one of those refusals is a place where the human would otherwise have quietly recruited the agent to skip a step. Sometimes the step being skipped was genuinely unnecessary, in which case the workflow's shape is wrong and needs a conversation. But the conversation is between humans, about the workflow. There is no negotiation here: not between human and agent, not about a work item. Yes, the workflow will occasionally feel obstructive. That is entirely by design.
Try this before the next article
Pick a status on your board — any one — and try to write down, in a single sentence, its answer to:
"Who can do what to an item in this status, and how do they know they're allowed to?"
Most boards have at least one status where the honest answer is "the team just knows." That's fine for humans. The agent will have questions.
Next: The intake gate — making entry surfaces converge. How you make the "read status first" check happen on every path an agent can be invoked from, including the ones that carry no instructions at all — and why the first thing every phase's skill has to do is run it.
A note on how this was made
Every idea in my writing comes from real work — built, broken, and figured out before a single word is written. The writing is documentation, not speculation. I start with voice dictation: a raw thought dump of ideas, objectives, and what I've actually been working on. From there, I collaborate with AI to shape that into something readable — structuring drafts and editing through a custom Rovo agent, configured with carefully curated instructions to review and refine work against my preferences, personality, and style. Artwork is a separate creative process — concepts originate from my own ideas and are brought to life using a combination of Google Gemini, ChatGPT, and Photoshop. The ideas, the experience, the creative direction — those are mine. AI is how I move fast and bring them to life.
Before anything is published, every claim and every idea goes through multiple review cycles to make sure it accurately reflects the thoughts and experience I originally set out to convey. If something reads well, that's the process working. If something doesn't, that's on me.
Was this helpful?
Thanks!
Ben Spillane
3 comments