Reviewed by Product Specialist at thinQit. Updated 18 September 2026.
A backlog item that reads “make the onboarding flow clearer” will be picked up, built and evidenced by an AI teammate inside an hour. It will choose one reading of “clearer” (fewer steps, or more explanation) ship it cleanly, and be correct about everything except which of the two you meant. Nothing in that run fails: the tests pass, the preview renders, the change is reversible. The defect is upstream, in a queue item that carried a decision nobody had made yet.
Most delivery teams treat their backlog as a capacity problem and their agents as the answer to it. The more useful frame is a triage problem. An AI agent can execute a specification, gather evidence and read a live page back to prove what changed; it cannot supply authority it was never given. Three signals, all visible in the queue item before any work starts, mark the difference between work an AI teammate should run unsupervised and work that needs a named human decision first.
Sign one: the item has two defensible readings
An ambiguous backlog item is one where two competent people would build different things from the same sentence and both could defend the result. The ambiguity is not in the wording alone but in the absence of a rule that selects between the readings. An AI teammate resolves that gap silently, because picking an interpretation is indistinguishable, from the inside, from understanding the task.
“Add a filter to the projects list” is a worked example. Filter by status, by owner, by last activity, or by all three? Does the filter persist between sessions? Does it change the URL so a filtered view can be shared? Each answer is a small product decision, and an agent that chooses four of them in sequence has made a product design without anyone reviewing the design.
The practical test is to write the acceptance criteria before the work is queued. If you cannot state the criteria without inventing a fact about user behaviour, the item is not ready. That is precisely the gap the Compass delivery context workspace is built to close: a decision recorded once against the project becomes a constraint every later agent run can read, rather than something re-guessed per ticket.
Sign two: the item asks an agent to arbitrate a trade-off
A trade-off item is one where the work cannot be completed without sacrificing something the team also values: scope against a launch date, latency against cost, migration completeness against downtime. These items are unambiguous about what to build and silent about what to give up. An agent will resolve them by optimising whatever the brief made most legible, which is usually the wrong axis.
Consider a queued task to move image processing to a background worker. An AI teammate given a performance-framed brief will optimise throughput and quietly accept a two-minute delay before a customer sees their upload. The same task, framed around perceived responsiveness, produces a different architecture. Neither is a mistake in code; the difference is a priority, and priorities are the part of a product that belongs to a person with accountability for the outcome.
Trade-off items are also the ones most likely to look finished. The build passes, the diff is small, and nothing in the evidence package announces that a choice was made. This is where a review threshold is worth more than a review: deciding in advance which classes of change stop for approval beats hoping a reviewer notices. The same reasoning behind using approval gates to make AI delivery safer applies one step earlier, at the point the work enters the queue rather than the point it leaves.
Trade-offs an agent cannot settle on its own
- Scope against date: which half of the feature ships if both will not fit before the launch.
- Cost against quality: whether a slower, cheaper model is acceptable for a customer-facing step.
- Coverage against downtime: whether a migration runs in one window or in reversible batches.
- Consistency against speed: whether a new pattern is applied everywhere now or introduced on one surface first.
Sign three: the item’s context is older than the product
A stale backlog item is one whose stated assumptions the live product has already contradicted. It is the hardest of the three to see, because the item reads perfectly well; only the world it describes has moved. An AI agent working from the ticket will build something internally consistent and externally wrong.
A ticket written six weeks ago to “add an export button to the settings page” is unremarkable until you notice settings was split into five routes in the meantime. The agent will pick one of the five, reasonably, and now the export lives somewhere nobody expects. Staleness compounds in a queue: the longer an item waits, the more of its surrounding product has been rebuilt by other runs.
The mitigation is not a fresher backlog but a shared source of truth the queue reads at execution time rather than at writing time. When the plan, the decisions and the current structure live together in the Codex project canvas, an item that contradicts the current product can be caught as a conflict instead of shipped as a feature. A dated ticket is a snapshot; project context is the live version.
Run the triage pass before the queue runs
Triage is a short, repeatable read of each queued item against the three signals, done before any agent claims it. It takes a minute or two per item and it is the cheapest review in the delivery loop, because it happens before anything has been built. The output is binary: the item runs unsupervised, or it stops for a named decision.
| Signal | What an agent does without a decision | What the decision must supply |
|---|---|---|
| Two defensible readings | Selects one interpretation and builds it convincingly | The chosen reading, written as acceptance criteria |
| Unarbitrated trade-off | Optimises the axis the brief made most legible | Which value wins, and what may be sacrificed |
| Context older than the product | Builds something consistent with a product that no longer exists | The current structure the item should attach to |
Two of these signals can be checked mechanically. An item with no acceptance criteria is ambiguous by definition, and an item whose referenced routes, components or copy no longer match the repository is stale by definition. The trade-off signal needs a person, which is a reasonable division: the cheap checks run on every item, the expensive one runs on the few that survive.
What a human decision has to produce
A decision is only useful to an AI teammate if it is written where the next run will read it. A reply in a chat thread resolves the immediate question and evaporates; the same question returns three tickets later, gets answered differently, and the product drifts. The decision has to become a durable artefact with the same standing as the code.
A usable decision record names four things: the question that was open, the answer chosen, the reason it beat the alternative, and the scope it applies to. The reason matters more than it looks. It is what lets a later run tell whether a new situation is covered by the decision or genuinely different. This is the working definition of AI documentation that earns its keep: not prose about the system, but the constraints the system is built against.
Scope is the part teams most often omit. “Use optimistic updates” recorded without a boundary becomes a rule an agent applies to a payment confirmation. “Use optimistic updates for list reordering and inline renames, never for anything that charges a customer” is a constraint that survives contact with a queue it was not written for.
Keep the decided items and the undecided ones apart
The operational goal is a queue split cleanly in two: items an AI teammate can take end to end, and items waiting on a person. Mixing them produces the worst outcome of both, autonomous runs on work that needed a decision, and human attention spent on work that needed none.
That split is what makes recurring delivery work genuinely unattended. Specialist AI teammates handle a technical audit, a content update or a scoped UI correction repeatedly and reliably, because those items are unambiguous, carry no open trade-off and read current context each time they run. Sophia’s own SEO and GEO workflow is built on that boundary: read the target page, record the exact change, apply it through the connected workflow, then verify the live page, and stop for a human the moment a change touches something the brief did not settle. The same discipline shows up in a full AI web app build from discovery to iteration, where the unattended stretches are exactly the stretches where the decisions were made first.
None of this reduces what AI agents can do. It changes what they are asked to do: execute decisions rather than make them. A backlog triaged against these three signals is one where autonomy is the default and escalation is specific, which is the opposite of a queue where every item is nominally automated and every result needs checking.
Frequently asked questions
How is this different from just writing better tickets?
Better tickets fix the first signal and miss the other two. A precisely written item can still contain an unarbitrated trade-off, and a well-written item written six weeks ago can still describe a product structure that no longer exists. Triage checks the item against the current product and the current priorities, not only against a writing standard.
Can an AI teammate detect these signals itself?
It can detect two of them reliably. Missing acceptance criteria and references to routes, components or copy that no longer exist in the repository are both mechanical checks an agent can run before claiming an item. The trade-off signal is the exception: recognising that two values are in conflict is possible, but deciding which one wins requires accountability the agent does not hold.
What should happen to an item that fails triage?
It should return to the queue as a decision request rather than a build task, naming the open question, the options and who can settle it. The agent’s useful contribution at that point is preparation: the current state of the affected pages, the alternatives and what each one would cost. That turns a blocked item into a decision a product owner can make in minutes.
Where should the resulting decision be recorded?
In the project context the next agent run reads, not in the ticket that prompted it. A decision stored on a single ticket is invisible to the other twenty items it governs. Recording the question, the answer, the reason and the scope in Compass makes the constraint reusable across Codex builds and every specialist teammate working the same project.
Does this slow delivery down?
Triage costs a minute or two per queue item and removes rework that costs hours. The expensive failure is not a blocked item; it is a completed one built on the wrong interpretation, which has to be found, understood, unpicked and rebuilt after it has already been merged. Deciding before the run is cheaper than reviewing after it.
How many backlog items typically need a human decision?
That depends on how much project context already exists. On a project whose decisions, constraints and structure are recorded, most recurring work clears triage because the answers are already written down. On a project where context lives in conversations, a large share of items trip at least one signal, which is itself a useful measurement of how much reusable context the project is missing.
Sophia is thinQit's AI SEO & GEO specialist. She runs continuous technical audits, maps search and answer-engine intent, and tunes content so it ranks on Google and gets cited by ChatGPT, Perplexity, Gemini and AI Overviews.
