1. Start with work rather than a persona

Calling a model a teammate does little to specify the relationship. It may suggest a helpful interaction style while leaving consequential questions unanswered. What information can it access? What can it change? Who checks the result? When does an interpretation become a commitment? Who responds when the work falls short?

Our position starts with a job and its outcome. The participants may include a customer, an operator, a domain expert, a model-backed operation, deterministic software, and an external service. Their contributions differ. Giving them a common label does not make their capabilities, authority, or responsibilities interchangeable.

We propose designing the relationship through observable work: inputs, artifacts, decisions, actions, dependencies, and recovery. This permits useful collaboration without requiring claims that the model understands responsibility as a person does. The product can coordinate contributions while an organization retains accountability for how that coordination is designed and used.

2. Separate five allocation questions

Information access concerns what a participant can know at a particular step. Execution concerns who performs a transformation or action. Judgment concerns who assesses whether a contribution is adequate. Authority concerns who may commit a change. Accountability concerns who must explain, maintain, and respond to the resulting behavior.

These dimensions can vary independently. A model may inspect customer messages and draft a reply without authority to send it. A service may apply an approved refund while having no discretion to choose the amount. A reviewer may assess policy compliance while a manager owns an exception decision. A developer may use generated code while retaining responsibility for accepting the design.

Capability therefore does not establish permission. Nor does access establish competence on the target cases. For each allocation, specify the information available, the intended output, the boundary of discretion, and the evidence that would support delegating that contribution. This is a design hypothesis until the complete workflow is examined.

3. Automation can differ across functions

Parasuraman, Sheridan, and Wickens propose distinguishing automation of information acquisition, analysis, decision selection, and action implementation, with different levels within each function. Their model also treats the consequences for human performance as part of the allocation question. This provides a useful conceptual foundation for avoiding one global autonomy setting.

Our extension for AI product work is to make the concrete artifacts and authority boundaries explicit. The same product might automatically retrieve records, ask a model to propose interpretations, require a domain review for exceptions, and use software to enforce final action conditions. Increasing automation in one part need not increase discretion everywhere.

This is not an empirical claim that this particular allocation is superior. It is a way to state alternatives precisely enough to compare them. One candidate may reduce routine reading while another reduces handoffs. The choice should reflect the job, observed capability, coordination cost, and consequence of error.

Supporting reading: [1] Parasuraman, Sheridan, and Wickens (2000). A Model for Types and Levels of Human Interaction with Automation.

4. Shared artifacts make the relationship inspectable

A conversation can communicate intent, but the operative state of the work should be recoverable. A proposal, selected evidence set, pending decision, approved change, and completed action have different meanings. Store and display those distinctions where they affect what happens next.

For example, a person might change a delivery address in a draft. The resulting state should make clear that the new address supersedes the earlier value and has not yet been submitted. A model’s acknowledgment in chat is insufficient evidence that every later tool call will use it. A shared artifact gives software and reviewers a concrete object to inspect.

Shared storage does not itself establish common understanding. Show the operative interpretation, relevant source, status, and consequences at the decision point. Participants should be able to challenge an inference without rewriting the whole conversation or accidentally approving the action. Preserve rejected and deferred proposals when they explain later choices.

5. Worked hypothetical case: a support escalation

Imagine a support team handling delayed deliveries. A model-backed assistant reads the customer’s message, retrieves order events and applicable policy, and prepares a proposed response. Some cases qualify for a routine refund; others require an exception decision. The purpose is to resolve the customer’s request with acceptable effort and consequences.

One allocation gives the assistant responsibility for assembling a review packet: the request, verified order state, relevant policy passages, unresolved conflicts, and a proposed action. The support agent checks the packet and chooses an allowed outcome. A separate service validates permissions and performs the approved action. A domain owner decides policy exceptions.

The packet must expose what was retrieved, inferred, and left uncertain. If the customer mentions a replacement already arranged by another agent, that constraint should remain visible through the proposal and action. This is a fictional design example. Whether it improves actual resolution depends on evidence about review, corrections, delays, and customer outcomes.

6. Make handoffs convey a decision need

A handoff should explain why another contribution is required. “Needs human review” is too vague when the recipient must reconstruct the case from scratch. “Two policies appear applicable; choose which governs this customer’s order before a refund can be proposed” identifies an uncertainty, an authority, and the next useful action.

Specify what happens while work is pending. Can the system gather more evidence? May it send a holding message? Can an approved routine path proceed? Who owns the queue and notices that a request has stalled? Handoffs create dependencies, and those dependencies belong in the product design.

Amershi and colleagues’ interaction guidelines include support for correction, disambiguation, explanations, and user controls. We use that guidance to motivate visible and steerable contributions. Their evaluation of the guidelines does not establish that our hypothetical support packet or handoff policy improves operational performance.

Supporting reading: [2] Amershi et al. (2019). Guidelines for Human-AI Interaction.

7. Give review the conditions it needs

An approval button does not by itself create effective review. The person needs relevant evidence, comprehensible differences, enough time, and authority to change or stop the work. Define what they are being asked to verify. Checking a policy exception differs from rereading every sentence for tone.

Avoid assigning a person responsibility for a property they cannot observe or influence. If the reviewer cannot see which account will receive the action, they cannot reliably verify account selection. If rejection simply restarts the same opaque generation, the workflow may impose review cost without enabling repair.

Test this arrangement with representative work. Observe what reviewers inspect, what they miss, which corrections recur, and whether another interface or boundary would reduce unnecessary effort. A review intervention can improve the current case while also revealing a policy to test later. Neither a click nor an edit automatically becomes a trustworthy training label.

8. Preserve ownership when an agent writes the code

The same allocation problem appears in software engineering. A coding agent can inspect files, propose a design, implement a patch, and run checks. The maintainers still need to relate the accepted change to the product’s invariants, architecture, operating constraints, and future evolution. A fluent explanation can assist that work without replacing it.

Our proposed acceptance condition is proportional understanding. An isolated disposable script may require knowledge of its contract and failure impact. Core product code requires the relevant owner to explain important state transitions, tradeoffs, dependencies, and recovery. The agent’s ability to continue implementing does not establish that the team can continue maintaining.

Use reviewable scope, canonical documentation, independent checks, and executable feedback to support this responsibility. When unfamiliar complexity accumulates faster than it can be examined, reduce scope or investigate before accepting dependent changes. Count preparation, intervention, review, and correction effort when assessing whether the agent improves accepted delivery.

9. A method for designing and revising allocation

Begin with real cases and the current alternative. Identify decisions where information, expertise, authority, or consequence changes. For each boundary, state candidate allocations and the assumptions they depend on. Keep the first implementation small enough to observe and revise.

The resulting record should explain how contributions meet, not just who receives a task label. Evaluate the whole job alongside local accuracy and speed. A faster analysis step may create a larger approval queue; a more detailed packet may reduce uncertainty while increasing reading burden. These are product design findings.

  • Name the job, intended outcome, and present sources of effort or error.
  • Identify the artifacts and decisions that connect participants.
  • Allocate information access, execution, judgment, authority, and ownership.
  • Define pending states, handoffs, correction, rejection, and recovery.
  • Test representative cases and consequential boundaries.
  • Revise the allocation using accepted outcomes and total effort.

10. Counterarguments: humans also fail and review can dominate

A reasonable objection is that human review can be slow and inconsistent. The proposal does not assume that humans are automatically accurate or require approval at every step. It requires a justified allocation. When software can enforce an exact constraint or an evaluated component can handle a bounded action, delegation may remove unnecessary work.

Another objection favors an end-to-end agent over decomposition. That can be a useful candidate. Compare accepted completion, failure consequences, recovery, and human effort rather than rejecting it by architecture alone. An explicit contract and trace can make an end-to-end implementation inspectable without splitting every decision into a service.

A further objection is that ownership language makes assistance too cautious. Ownership should enable useful discretion by defining the area within which it is supported. The problem is unexamined authority, not initiative itself. Evidence may justify expanding, shrinking, or rearranging the delegated work; it need not produce a one-way march toward greater autonomy.

11. Limitations and conclusion

This paper does not supply a universal human–AI division of labor or a theory of machine understanding. Allocation depends on the task, users, available information, operating conditions, and consequences. Additional state and handoff machinery can cost more than it provides, especially for short-lived, low-impact work. A record can become ceremonial if responsible people lack time or authority to act.

The method itself should therefore be tested. Does it expose an unsupported assumption, make a handoff easier to resolve, improve correction, or preserve maintainability? Does the resulting work improve enough to justify its coordination cost? Keep counterexamples and revise the mechanism when the answer is weak.

Our concluding position is that useful collaboration is designed through contributions and commitments. People, models, and software can perform different parts of a job while sharing inspectable artifacts and explicit boundaries. Accountable ownership gives the organization a place to integrate evidence, judgment, memory, and consequences as that allocation changes.