Three layers and one handoff keep an AI triage sweep from writing into the approved queue. We needed a triage process to work through a large backlog while a small team depended on the downstream queue. The boundary was simple. Automation could create a suggestion, but it could not move a record into a state readers took as approved work. A separately authorized human decision was the handoff to an actionable state.

That boundary was necessary but not sufficient. The workflow service had to enforce it, provenance and audit logging had to back it, and the queue views people used had to reinforce it.

The backlog, and how a sweep could poison it

We run a large backlog with a small team. Tickets carry years of context: half-finished customer features, partial fixes, forks where the real work moved to a different ticket. Triage by title and date is how you delete a customer’s real, half-finished request and never know you did it. So we wanted an AI in the loop, scoring, recommending and drafting across the whole pile, continuously.

The failure mode was easy to see. A triage sweep could write a recommendation into the same state a team member read as approved work. The queue would then hold human-vetted decisions and machine suggestions that looked identical.

A prompt may improve behavior, but it cannot be a reliable authorization boundary. The protection belongs in identity and workflow controls. The automation account should lack permission to perform approval or routing transitions. The interface should separate suggestions from reviewed work even if another control fails.

Three layers, one handoff

  • Layer 1: constrained automation creates suggestions and supporting rationale under a least-privilege service identity.
  • Layer 2: an editorial review layer validates evidence, records a human decision, and performs any approved transition.
  • Layer 3: downstream stakeholder views consume only approved, appropriately authorized state and stay read-only where possible.

The handoff runs through exactly one motion:

Automation creates → Suggested
Authorized reviewer evaluates evidence
Authorized reviewer records → Approved / Rejected / Needs more evidence
Downstream queue consumes → Approved state only

There is no shortcut around the authorization boundary. If an automation account can perform an actionable transition, that is a control gap and we treat it as a defect. We test the permission boundary, log transition attempts, and alert on violations.

The queue is a combination of state, authorization, provenance and the view that consumes it. It is more than a field or a notification. An assignee, a message or a recommendation can give context, but none of them counts as recorded approval.

Suggestions carry provenance and no authority

The workflow used a defined state vocabulary, but the control did not depend on a UI field name. The backend accepted only the permitted transition for the automation identity. The available states, roles and allowed transitions were managed as part of the workflow configuration and tested against the service contract.

Automation could attach advisory data: rationale, sources, a non-authoritative score, known uncertainty and generation metadata. Those fields made review faster, but they carried no authority. A reviewer still had to inspect the evidence and record an explicit decision.

Downstream views consumed only records that had reached the approved state through the authorized transition. The suggestion view stayed separate, so a team member could never mistake unreviewed automation output for a cleared queue item.

Why this holds up when a prompt wouldn’t

Adding a new downstream audience or role did not expand the automation principal’s authority. Roles and queues could change through workflow configuration and authorized views, while the automation contract stayed limited to suggestions and evidence.

That is safer than encoding routing rules in prompts or letting the model pick actionable destinations. The model assists with classification and drafting. A governed workflow and a human reviewer own routing and approval.

The same pattern applies beyond ticket triage. An assistant can draft a documentation update, a policy note or a follow-up task as a suggestion. An editor or accountable owner reviews the evidence and controls the transition. Capability can grow without handing automation authority over consequential actions.

The check to run

Look at the account your AI uses and ask whether it can move a record into a state your team treats as approved work. If it can, that is a control gap and a defect. Keep suggestions in a separate state and view, log transition attempts, and let only a separately authorized human decision hand work to the downstream queue.