AI Does Not Fix the Backlog: Govern the Queue Before You Automate the Work

Automation can increase throughput; it cannot decide what your organization owes first.

A backlog looks like a volume problem. Add an agent, process more items, and the pressure should fall. That logic is attractive because it begins with a visible pain and ends with a measurable promise. Yet the queue is not simply a pile of equivalent work. It contains different consequences, different evidence, different deadlines, and different people who absorb the cost when the wrong item moves first.

This week, NIST held a public webinar about an AI agent enrichment workflow being developed for the National Vulnerability Database. The event description is careful: the workflow is intended to aid enrichment, and the discussion covers architecture, implementation issues, and early results.¹That language matters. Aid is not ownership. Enrichment is not remediation. An agent can accelerate part of a lifecycle without inheriting authority over the entire lifecycle.

The presentation materials posted after the webinar make that boundary more concrete. NIST shows AI proposing, software validating and building structured artifacts, and analysts deciding when uncertainty remains. The same deck names managed context, preserved evidence, quality assurance, queue limits, retries, and replay as parts of the operating system, while statistical measures remain future work.²These are NIST-reported implementation details and early observations, not independent proof of performance.

The larger NVD record shows why priority must exist before acceleration. NIST reports that CVE submissions grew 263 percent from 2020 to 2025 and that nearly 42,000 CVEs were enriched in 2025. Even that record output could not keep pace. In April 2026, NIST published explicit criteria for which records would receive immediate enrichment, while other records would remain available but be classified as lowest priority.³The lesson is not that every business should imitate the NVD. It is that capacity limits become policy whether leaders name the policy or allow the queue to name it for them.

A queue is a decision system wearing the clothes of a list.

More Speed Makes the Hidden Policy More Powerful

Every operating queue already contains an admission rule, a priority rule, and an exit rule. They may live in a service agreement, a manager's judgment, a spreadsheet sort, or a sequence of inbox timestamps. Automation does not remove those rules. It executes them more frequently and with less natural friction.

That can be excellent when the rule is explicit and appropriate. It can also produce a polished version of the wrong result. A support agent may answer the easiest tickets while urgent exceptions age. A sales workflow may privilege complete profiles over high-intent prospects whose data is sparse. A compliance workflow may move a document because it is easy to classify while a difficult but consequential case waits for scarce expertise.

NIST's current request for information about the NVD asks separately about prioritization, dissemination, remediation, monitoring, standards, architecture, and data governance.⁴That separation is useful. It resists the idea that one optimization can stand in for the whole operating system.

Severity Is Not Priority

Describing a thing and deciding what to do about it are different acts. The Software Engineering Institute's SSVC work makes this distinction concrete in vulnerability management. Its decision trees are designed to help different stakeholders prioritize actions according to their context rather than rely on one universal score.⁵ A high severity can matter; priority also depends on exposure, mission, available options, timing, and the stakeholder responsible for acting.

The same distinction appears in ordinary business operations. Sentiment is not retention risk. Deal size is not collection priority. Message urgency is not decision authority. A model can estimate, summarize, and classify; the business must decide which evidence changes action.

This is where many agent projects become fragile. The team designs the happy path around a capability demo, then adds priority after volume appears. By then, the agent may already be creating the data used to justify its own next action. The queue is no longer merely being processed; it is being shaped by the processor.

Write a Queue Constitution

Before an AI system receives recurring authority over a business queue, define five things in language that an operator, engineer, and decision owner can all inspect:

1. Unit of work. Name the object moving through the system and the consequence attached to it. A ticket, invoice, application, alert, and customer promise are not interchangeable.
2. Admission evidence. State the minimum sources, freshness, identity, and completeness required before the item may enter automated work.
3. Priority owner. Name who defines the ordering logic, which factors are allowed, and which conditions force escalation or override.
4. Review capacity. Budget how many cases Humans can meaningfully inspect, what evidence they will see, and what happens when that capacity is exhausted.
5. Exit and exception. Define what completion means, which actions are reversible, how unresolved work remains visible, and who can reopen or retire a case.

I call this a constitution because it constrains power before individual cases arrive. It is not a prompt and not a private implementation disclosure. It is a public operating contract that keeps the model, the queue, and the accountable people inside the same decision boundary.

NIST's voluntary AI Risk Management Framework supports the underlying governance posture. It calls for risk-prioritized resources, clear roles, differentiated Human-AI responsibilities, documented oversight, and feedback mechanisms.⁶ NIST does not prescribe this five-part constitution or endorse VerShep; the structure is my interpretation of what a team needs before throughput can become trustworthy operations.

Human Review Is a Capacity, Not a Label

“Human in the loop” sounds reassuring because it names a person. It says nothing about whether that person has time, evidence, expertise, independence, or authority to change the result. If an agent creates 500 review items while the team can meaningfully inspect 50, the remaining 450 do not become safe because a Human-shaped box appears in the diagram.

A peer-reviewed experiment in PLOS ONE found that participants followed algorithmic recommendations closely and that Human adjustments did not reliably improve accuracy in the bounded task studied. The authors caution that a Human monitor may not provide the safeguard policymakers expect.⁸The study does not prove that Human review always fails. It shows why presence and effectiveness must be measured separately.

Review capacity therefore belongs inside the system design. High-consequence items may need protected capacity. Lower-consequence items may be sampled. Some work should pause when evidence is incomplete. Some should never be automated beyond drafting. When demand exceeds the agreed capacity, the system should expose the shortfall rather than hide it behind automatic completion.

Use Four Visible Queue States

Teams often track “open” and “closed” because those states are convenient for reporting. They are not sufficient for accountable AI-assisted work. A better operating surface exposes at least four states:

These states do not guarantee correctness. They make uncertainty, scarcity, and authority inspectable. That is a stronger foundation than a single completion percentage because it shows what the organization has actually decided and what remains unresolved.

Run the Pilot Against the Queue, Not the Demo

A useful pilot begins with a historical slice of real work. Reconstruct arrival volume, priority decisions, exceptions, reversals, and the time available for Human review. Then compare the proposed system against the decisions the organization was responsible for making, not merely against how fast text was generated.

Measure at least five outcomes:

• the share of items admitted with complete evidence;
• time to first responsible action by priority class;
• the rate and reason for Human escalation;
• the unresolved inventory that remains visible rather than automatically closed;
• the correction, reversal, or reopening rate after acceptance.

NIST's 2026 summary of public input on agent security reports broad concern that agent systems introduce novel threats and that established cybersecurity practices require adaptation.⁷That summary is not a controlled study and does not validate this pilot. It does reinforce the practical point: giving software more initiative changes the control problem, even when familiar security principles remain useful.

What This Architecture Cannot Promise

A Queue Constitution cannot eliminate bad evidence, unfair priorities, delayed Humans, or adversarial behavior. It is not a substitute for labor consultation, accessibility review, legal analysis, security testing, or domain expertise. The public NVD materials do not establish that NIST uses this model, and no source cited here proves a universal improvement from agentic automation.

What the constitution can do is force the consequential questions into the design before speed makes them harder to see. The model may help the work move. The organization remains responsible for deciding what deserves to move first, what must stop, and what completion actually means.