devinside.Marcin Borecki Ideas. Systems. Evidence.
← The notebook

Essays

Who Sets the Queue? Human Agency in AI-Managed Work

AI-managed work needs more than an approval button: people need a credible route to question the priorities and rules they are expected to follow.

Explore the mechanism ↓
Editorial ink and watercolor illustration for A queue is a policy people live inside

START WITH THE MECHANISM

Interactive companion and laboratory update: 12 November 2026. The editorial date places the topic on the timeline; this current explanation and its measured evidence retain their actual preparation and execution dates.

THE FULL INVESTIGATION

Who Sets the Queue? Human Agency in AI-Managed Work

Editorial context: 11 July 2025 · Prepared and updated: 12 November 2026
Dates and technology context

This is a retrospective editorial timeline. Topic context: 11 July 2025. First publicly available: 12 November 2026. Current text, visuals and laboratory revisions were prepared on 12 November 2026.

Current AI13/M21 laboratory links are later additions. Hypothetical queues must not become observed employer practices.

The most consequential decision in a working day may be made before anyone begins the task. It is the decision about which task appears first, which customer can wait, which exception deserves attention and which unfinished item will later count against the person doing the work.

An AI-enabled system can make those decisions easier to coordinate. It can also make them harder to question. The interface presents a queue, a recommendation or a score, while the choices that produced it remain elsewhere: in a policy, a configuration, a training objective or an assumption nobody now remembers accepting.

My argument is that human agency at work depends on more than having a person approve individual outputs. People need a meaningful way to understand and contest the rules shaping their actions, and someone must remain answerable for those rules. An employee can have discretion inside a task while having almost none over the conditions under which the task is assigned and judged.

This is an argument about the design of responsibility, not a claim that every automated workplace behaves badly. The scenarios below are hypothetical. They are intended to expose decisions worth examining before a convenient coordination tool becomes an authority that seems to have no owner.

A queue is a policy made operational

01 / See the idea

The queue distributes more than work

The queue distributes more than work. In the hypothetical support process, the system applies a policy that somebody owns. The worker and service recipient bear consequences that should remain visible when the policy is reviewed.

In the hypothetical support process, the system applies a policy that somebody owns. The worker and service recipient bear consequences that should remain visible when the policy is reviewed.

Interpretation and evidence
  • Identify who chooses the objective.
  • Do not treat an ordering as neutral by default.
  • Keep consequences connected to decision authority.
Original analytical argument and explicitly hypothetical scenarios.

Consider a hypothetical customer-support team. Its new assistant reads incoming requests, estimates urgency and places the cases in an order. Staff work from the top. The system also estimates how long each case should take and supplies a suggested response.

This could be helpful. It might make urgent cases easier to notice, reduce repeated sorting and give a new employee a useful starting point. The problem is not that software participates in coordination. The problem begins when the order is treated as neutral because a system produced it.

Every ordering makes choices. Urgency might mean potential harm to a customer, likelihood of cancellation, a contractual deadline or the age of a request. Those priorities can conflict. A queue optimized for one can disadvantage another without containing a software defect.

The team therefore needs to know what the order is for. A label such as priority score is too vague if it conceals a tradeoff the organization has never discussed. The person facing a distressed customer should not have to reverse-engineer that tradeoff from a sequence of surprising assignments.

This does not require exposing every mathematical detail to every worker. A useful explanation can identify the objective, the information considered, the important limits and the route for questioning a result. The aim is practical understanding: enough to recognize when the system's ordering does not fit the case.

The queue becomes accountable when the organization can explain why it exists in this form and who can revise the policy it expresses. Without that ownership, a change in software can quietly become a change in how people are expected to work.

Responsibility can remain with the person while control moves away

Now extend the hypothetical case. A support worker is held responsible for resolving requests promptly, but cannot change their order. The assistant places several complicated cases late because they resemble low-value routine requests. The worker recognizes the pattern but has no accepted way to intervene.

When a case escalates, the worker is asked why it was not handled earlier. They can point to the queue, but the organization still expects personal responsibility. Control and accountability have separated.

This mismatch can exist without malicious intent. The system may have been introduced to reduce administrative work, and the performance measure may predate it. Yet the combination changes the person's practical position. They are answerable for a result while the conditions determining it are increasingly set elsewhere.

A meaningful response begins by identifying which decisions the worker can actually make. Can they reorder a case? Request another person's judgment? Correct the facts used by the assistant? Explain a departure from the suggested duration? If each option technically exists but creates an automatic penalty, the formal permission may have little practical value.

Agency is therefore not simply a count of available buttons. It concerns the relationship between information, permissible action and consequence. A person can be allowed to speak while having no effective way to change what happens.

The organization should examine that relationship before assigning responsibility. Otherwise, the language of empowerment can coexist with a workflow that systematically removes the conditions under which responsible action is possible.

Oversight and agency ask different questions

Human oversight asks whether a person can inspect an automated recommendation and intervene appropriately. That is an important question, but it does not exhaust the question of agency.

Suppose a supervisor reviews the queue before the shift begins. They have the information and authority to correct an individual mistake. The workers may still have no way to question the definition of urgency, the workload assumptions or the criteria used to evaluate their performance.

The system has oversight, yet its rules may remain difficult for the affected people to contest. These are related design problems with different objects. One concerns the handling of a recommendation. The other concerns participation in the conditions under which work is organized.

The distinction prevents two mistakes. The first is assuming that an approval screen makes the whole arrangement accountable. The second is expecting a single interface control to resolve every question of workplace authority.

An operational reviewer may need a clear decision, evidence and a stop mechanism. A worker challenging the rules may need access to a different process: an explanation of the policy, representation in its revision, or a person who can hear an objection beyond one case.

The earlier essay on the human in the loop examines the first problem. Here the focus is the second. A well-designed review job can contribute to a fairer arrangement, but it cannot substitute for deciding who has a voice in the objectives that review is meant to enforce.

Explain the reason that matters to the decision

An explanation can be technically accurate and practically useless. Telling the worker that a case received a score of 0.83 does not explain why another case should precede it. A list of influential features may still leave the governing policy unclear.

The relevant question is what the person needs to understand in order to act responsibly. If the queue prioritizes a contractual response deadline, say so. If it infers urgency from incomplete text, make that limitation visible. If some information is unavailable for legitimate reasons, explain the resulting uncertainty rather than presenting the decision as fully informed.

In the hypothetical team, a useful case explanation might state that the request was placed first because its declared service deadline is near, while the assistant has not established the severity of the customer's underlying problem. That gives the worker a specific condition to check.

It also separates a factual correction from a policy disagreement. A wrong deadline can be corrected as data. A disagreement about whether commercial value should outweigh waiting time concerns the rule. Sending both through the same generic feedback box can make neither easy to resolve.

Research on human-AI interaction has produced design guidance for making AI-enabled systems more usable and understandable. The Microsoft Research guidelines are a relevant resource for interaction design, but their evaluation is not proof that any particular workplace arrangement distributes power fairly. Guidelines for Human-AI Interaction.

The broader organizational question remains ours to answer: what kind of explanation allows a person to challenge the right part of the decision?

An appeal must be able to change something

02 / See the idea

Feedback and an effective appeal differ

Feedback and an effective appeal differ. Both routes can collect useful information, but only a route with authority can change the relevant outcome. This is a conceptual comparison, not a measured workplace result.

Both routes can collect useful information, but only a route with authority can change the relevant outcome. This is a conceptual comparison, not a measured workplace result.

Interpretation and evidence
  • Name the object of the appeal.
  • Identify a recipient with real authority.
  • Make the possible effect and time boundary clear.
Original analytical argument and explicitly hypothetical scenarios.

A meaningful appeal needs an object, a recipient and a possible effect. The object might be a factual input, an individual assignment or the policy behind many assignments. The recipient must have authority over that object. The effect must extend beyond recording that somebody was unhappy.

Consider two hypothetical appeal mechanisms. In the first, the worker marks a case incorrectly prioritized. The system records feedback for possible future improvement, but the current case stays in place and the worker remains accountable for its delay. In the second, the worker identifies a specific missing condition, the case can be paused or reordered, and an authorized person decides whether the policy needs revision.

Both mechanisms collect information. Only the second necessarily provides a route to changing the immediate outcome. The first may still be useful for product improvement, but it should not be presented as equivalent protection for the person handling the case.

An appeal also needs a time scale appropriate to the consequence. A review that arrives after an irreversible decision may improve future policy while offering little help in the current situation. The organization should be clear about that distinction.

This does not mean every appeal must succeed. A shared workflow cannot function if every individual preference automatically overrides collective priorities. It means the objection receives an intelligible decision from someone able to address it, with a reason connected to the issue raised.

A rejected appeal can preserve agency better than a permanently ignored one, provided the process is credible and the decision itself can be understood. The person learns what governs the work rather than encountering an opaque refusal disguised as a software limitation.

Keep the record of disagreement useful

03 / Watch the mechanism

A disagreement has a route to a decision

A disagreement has a route to a decision. The motion follows a hypothetical appeal through review and explanation. It does not imply that every appeal succeeds; the point is that an accountable decision returns to the affected person.
Enlarge diagram

Static view. Play to see how the mechanism unfolds.

The motion follows a hypothetical appeal through review and explanation. It does not imply that every appeal succeeds; the point is that an accountable decision returns to the affected person.

Interpretation and evidence
  • Acknowledge and resolve are different states.
  • Keep the reason attached to the case.
  • Use recurring exceptions to question the rule.
Original analytical argument and explicitly hypothetical scenarios.

When a worker departs from a recommendation, the record should help the organization understand the decision. It should not merely become another field that can be used against the worker without context.

In the support example, a short note could identify the missing fact, the action taken and the authority under which it was taken. The note need not contain a transcript of every thought or a detailed account of personal behavior. Its purpose is to preserve the reason for a consequential exception.

Over time, repeated exceptions may indicate a problem with the policy, the data or the way cases are described. That is a possibility to investigate, not an automatic conclusion. The system should make the pattern available to the people who can revise the relevant rule.

There is a difficult incentive question here. If every deviation is treated as suspicious, people may stop documenting the reasons that would help improve the process. If deviations have no review at all, inconsistent decisions can accumulate without explanation. A useful design needs proportionate scrutiny and a clear distinction between disagreement, error and misconduct.

NIST's AI Risk Management Framework emphasizes organizational governance and clear responsibility for AI-related risks. It provides a useful background for assigning ownership, while leaving the specific workplace process to be designed and justified. It is not a guarantee of fairness or a replacement for the relevant institutional obligations. NIST AI RMF 1.0.

The practical standard is whether the record supports learning and accountability for the rule as well as for the individual action. A system that records only the worker's deviation can make the policy appear infallible by construction.

The strongest case for automation deserves to be taken seriously

There is a substantial argument for automated coordination. Human managers can be inconsistent, forgetful or influenced by whoever speaks most forcefully. A visible queue can make some decisions more consistent and reduce the burden of repeatedly negotiating routine work.

The assistant might also help a worker identify an urgent case they would otherwise miss. It can reduce repetitive sorting and make a complicated workload easier to navigate. Rejecting those benefits because automation participates in authority would be an unnecessarily narrow view of human agency.

The important comparison is with the actual alternative, not an idealized workplace in which every manual decision is transparent and fair. A documented automated policy with a functioning appeal may give people more useful influence than an undocumented managerial preference.

However, consistency does not settle whether the objective is appropriate. A system can consistently apply a questionable rule. Nor does making a rule explicit remove the need to decide who may challenge it.

The strongest design combines useful automation with visible ownership of the objective and credible routes for correction. Routine cases can move efficiently, while consequential exceptions have a place to go. The worker need not renegotiate every assignment, and the system need not become an authority beyond discussion.

That is a more demanding ambition than simply maximizing the number of automated decisions. It asks whether automation improves people's ability to perform responsible work within an understandable organization.

Different people need different kinds of control

04 / See the idea

Different people need different influence

Different people need different influence. One override button cannot settle every interest in the workflow. The hypothetical map separates local discretion, shared coordination and the consequences experienced by the recipient.

One override button cannot settle every interest in the workflow. The hypothetical map separates local discretion, shared coordination and the consequences experienced by the recipient.

Interpretation and evidence
  • Match the route to the decision level.
  • Do not let local overrides hide system-wide costs.
  • Keep policy review separate from factual correction.
Original analytical argument and explicitly hypothetical scenarios.

The worker, the manager and the recipient of the service do not have identical interests. A worker may need manageable load and discretion over a difficult case. A manager may need consistency across the team. A customer may need the organization to recognize harm that its priority categories fail to capture.

An effective design should not pretend that one control satisfies all three. Letting a worker reorder their own queue may help with a specific case while shifting delay to another worker. Letting a manager override every recommendation may restore discretion while recreating the inconsistency automation was meant to reduce.

The organization needs to identify the level at which each decision belongs. Local exceptions can have bounded authority. Recurring conflicts may need a policy review. Changes affecting several teams may require a broader discussion of resources and commitments.

This separation also helps avoid excessive friction. Not every spelling correction should become a governance meeting. Not every policy disagreement should be treated as a minor data fix. The route should fit the object and consequence of the objection.

For the hypothetical queue, a worker might correct a factual deadline directly, ask a supervisor to reorder a consequential case, and submit a recurring category problem for policy review. Those are three different forms of influence. Naming them makes the practical meaning of agency clearer than a general promise that humans remain in control.

Technical evidence can test a mechanism, not legitimize a rule

A software test can show that an appeal reaches the intended queue, that a paused action does not execute, or that a recorded explanation remains attached to the case. Those are valuable properties. They do not prove that the policy is fair or that workers feel able to use the process.

The publication's action-reservation laboratory illustrates the narrower engineering discipline. It preserves an uncertain operation until evidence can establish the receiver's outcome. Its local fixture tests explicit state transitions; it does not evaluate a workplace or a real payment organization.

The relevance is that a label should correspond to an actual mechanism. In an appeal process, paused should mean that the relevant consequence is paused. Referred should identify a recipient with authority. Resolved should include a decision that addresses the objection.

But the organization still has to justify who receives that authority and which concerns the process accepts. Technical correctness can make a chosen policy reliable without making the policy legitimate.

This boundary protects engineering from being asked to certify a question it cannot answer alone. It also protects people from having a social disagreement dismissed because the software passed its tests.

Evaluate the route for disagreement, not the worker's willingness to use it

A low number of appeals can mean that the system works well. It can also mean that people do not know how to appeal, do not expect a response or believe that raising an objection will harm them. The count alone cannot distinguish those explanations.

The evaluation should therefore examine the process rather than turn participation into another employee score. Can a representative objection reach the right decision-maker? Is the relevant evidence available? Does a response explain the decision? Can the original case be corrected when the appeal succeeds?

These questions can initially be explored with hypothetical cases and a walkthrough of the actual process. That is a limited exercise, not proof of how people will behave under pressure. Its purpose is to reveal obvious gaps before the organization interprets the absence of complaints as consent.

The same care applies to response time. A rapid acknowledgement is not a rapid resolution. An appeal marked closed may have been answered administratively without addressing its substance. The status should identify what changed, what did not and why.

There is also a boundary around information collection. Understanding a disputed allocation does not require recording every private conversation or turning the employee's entire working day into a dataset. The organization should ask what evidence the decision actually needs and avoid collecting unrelated material simply because its systems make that possible.

Finally, the mechanism itself should be open to revision. If the same objection repeatedly fails to fit the available categories, the categories may be part of the problem. If different reviewers give incompatible explanations, the policy may need clarification. These are hypotheses to investigate, not automatic reasons to accept every appeal.

The objective is a process in which disagreement can reveal something the organization needs to know. An appeal system that exists only to demonstrate compliance with its own procedure risks measuring its paperwork while missing the decision it was meant to improve.

Begin with the decision people cannot currently influence

A practical review of an AI-managed workflow can begin with one ordinary case and one difficult exception. Follow who supplied the facts, who selected the objective, who can change the result and who bears the consequence if it is wrong.

Then ask what an affected person can do when they believe the system has misunderstood the situation. Can they identify the reason? Correct the relevant fact? Reach someone with authority? Obtain a response before the consequence becomes fixed? Understand why the objection was accepted or rejected?

These questions do not require a large new bureaucracy. They require a clear account of decisions the organization is already making. The resulting changes might be small: a visible policy owner, a separate route for factual corrections, a pause with real effect or a review of repeated exceptions.

The final test is whether responsibility and influence have moved together. If the worker remains answerable for the outcome while losing every credible route to affect its conditions, the system has transferred control without acknowledging the transfer.

AI can make coordination more useful. It should not make organizational choices seem inevitable merely because they arrive through a screen. The queue is still an expression of human priorities, and people should be able to discover who owns those priorities and how they can be questioned.

Sources and editorial evidence

Download the source notes and visual explanations. This essay contains no new workplace measurements.

THE AUTHOR

Marcin Borecki

Developer, entrepreneur and business angel. Writing about AI, software, data and the evidence behind technical decisions.

About the author →