An automated triage process needed to examine a large backlog while a small team depended on the downstream queue. The essential boundary was simple: automation could create a suggestion, but it could not transition a record into a state that readers interpreted as approved work. A separately authorized human decision was the handoff to an actionable state.

That boundary was necessary, but not sufficient by itself. It needed to be enforced by the workflow service, accompanied by provenance and audit logging, and reinforced by the queue views people used.

The setup that makes this dangerous

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. Triaging that by title and date is how you delete a customer’s real, half-finished request and never know you did it. So I wanted an AI in the loop, scoring and recommending and drafting, across the whole pile, continuously.

The failure mode was straightforward: a triage sweep could write a recommendation into the same state a team member read as approved work. The queue would then contain a mixture of human-vetted decisions and machine suggestions that looked identical.

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

Three layers, one load-bearing handoff

The model is three layers:

  • 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 remain 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 that should be treated as a defect and monitored accordingly. Test the permission boundary, log transition attempts, and alert on violations.

The queue is not simply a field or a notification. It is the combination of state, authorization, provenance, and the view that consumes it. An assignee, message, or recommendation can provide context; none should be mistaken for recorded approval.

Suggestions need provenance, not implied 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 such as rationale, sources, a non-authoritative score, known uncertainty, and generation metadata. Those fields made review more efficient, but they did not carry authority. A reviewer still needed 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 remained distinct so that a team member could never mistake unreviewed automation output for a cleared queue item.

Why this scales when a prompt wouldn’t

The property that mattered was that adding a new downstream audience or role did not expand the automation principal’s authority. Roles and queues could evolve through workflow configuration and authorized views, while the automation contract remained limited to suggestions and evidence.

That is safer than encoding routing rules in prompts or allowing the model to select actionable destinations. The model can assist with classification and drafting; a governed workflow and human reviewer own routing and approval.

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