Make delegation workDelegationDecision boundaries
How much autonomy does this job need?
An agent can investigate freely inside a narrow boundary. A worked supplier-research example shows how to allocate decisions, define completion and make an approval worth giving.
Analysis · worked examplePrepared October 22, 20268 min readRethinking Agents
What this rests on
Reported by others: a 2025 production survey (306 responses; 86 deployed-or-pilot subset; 20 interviews) and Intercom's outcome-metric explanation, both re-read 2026-10-22. Observed by us: none; no RA benchmark or deployment was executed. Proposed: the supplier-research decision map is hypothetical and the evaluation checks are untested.
Sources checked October 22, 2026. Read the source record and limitations.
For engineers deciding which decisions an agent may take on its own, and the owners who have to sign off on what comes back.
An agent can investigate freely while operating within a narrow boundary. Start by deciding which decisions you want to hand over.
You ask an agent to find a supplier. It returns three options, a recommendation and a confident explanation. Whether you can hand it the next step depends on what “find a supplier” was supposed to mean.
Did it check the requirement? Did it compare delivered cost or the price on the product page? Does it know whether you wanted a shortlist, a draft order or a completed purchase?
Those are different decisions. Permission to search widely does not require permission to spend. Preparing an order does not require choosing the budget. A system can have considerable freedom over its methods and strict limits on its commitments.
This gives us a more useful starting point than choosing between “human in the loop” and “fully autonomous.” Describe the work, allocate the decisions, and specify what evidence must come back.
Start with an outcome somebody can recognize
Consider a fictional team purchasing twelve docking stations for an office. The owner has specified compatibility, a delivered-cost ceiling and an arrival deadline. The team wants a shortlist it can check before choosing a supplier.
A useful research result contains compatible options, evidence for the decisive requirements, the full cost assumptions and any uncertainty about arrival. If the agent finds no suitable option, that can also be a useful result. It should explain which requirement rules out the candidates and which unresolved fact could change the answer.
A long report is not necessarily progress. Three options with unsupported compatibility claims leave the owner doing the research again. A shorter brief that exposes the one unanswered question might move the decision forward.
The first design choice is therefore the intended handoff. For this job, completion means producing a defensible comparison. It does not mean placing an order.
Allocate the decisions explicitly
Here is a proposed boundary for that fictional workflow. It is a design example, not an implemented purchasing system.
| Decision | Agent's authority | Evidence or constraint |
|---|---|---|
| Choose sources | Inspect relevant public information and follow useful leads | Retain the source and date for each decisive claim |
| Interpret requirements | Apply the owner's stated requirements | Surface ambiguity rather than silently relaxing a requirement |
| Compare candidates | Calculate costs and propose a shortlist | Include delivery assumptions and reasons for exclusion |
| Resolve conflicting evidence | Describe the conflict and seek stronger evidence within the research budget | Do not average incompatible facts into a confident answer |
| Recommend a choice | Explain the preferred option and strongest alternative | State what missing fact would reverse the recommendation |
| Contact a supplier | Prepare questions only | Sending a message is a separate external action |
| Spend or commit | None | A person owns the purchasing decision |
| Stop researching | Stop at the agreed evidence threshold or time limit | Return unresolved questions when the threshold cannot be met |
This still leaves room for adaptive behavior. The agent can change its search terms, discover another supplier or follow a reference that nobody anticipated. What stays fixed is the task's authority and acceptance boundary.
That distinction matters when someone argues that specifying the work defeats the purpose of an agent. Specifying every search step would restrict useful exploration. Specifying the required outcome and who may commit the business gives that exploration a purpose.
There are several useful stopping points
The same task could support three sensible designs.
Recommendation only. The agent returns a comparison. This is appropriate when research is the expensive part and the owner can complete the transaction easily. No purchasing integration is needed to make the research useful.
Preparation with approval. The agent assembles a draft order containing the exact items, quantity, total and conditions. A person can inspect the commitment before it happens. This is useful only if preparing the draft saves work and reviewing it is straightforward.
Bounded execution. A repeat purchasing process might eventually permit orders from approved suppliers within explicit limits. That requires more than a prompt describing the policy: the action interface must enforce the permitted scope and record what actually happened. A changed total or supplier must not inherit approval intended for an earlier proposal.
There is also a simpler alternative. If replenishment always means the same item from the same approved supplier when stock crosses a fixed threshold, a scheduled rule may handle the routine order. An agent could investigate exceptions such as an unavailable item, while the predictable part stays ordinary automation. Adaptive reasoning should have a job to do.
These are alternatives, not a maturity ladder. A recurring, low-value replenishment task may justify bounded execution. An occasional consequential purchase may remain recommendation-only indefinitely. The right boundary follows the job.
Make the approval useful
Putting a button in the workflow does not establish that a person can make a good decision.
Suppose the approval says: “Proceed with the recommended supplier?” To judge that proposal, the reviewer has to reopen the research, reconstruct the cost and check whether anything changed. The agent has handed back much of the work.
A better approval packet would state the proposed commitment, current total, evidence for the hard requirements and unresolved exceptions. It would distinguish a supplier's delivery estimate from a guaranteed commitment. If the proposal changes, the packet changes with it.
The human's job becomes specific: accept the uncertainty, resolve an exception or reject the commitment. This is more meaningful than asking them to approve an unexplained conclusion.
A planned handoff can itself be a successful outcome. Intercom describes extending its Fin outcome model to include configured work followed by human handoff. That illustrates how the intended workflow affects the definition of success; it does not independently establish customer benefit or validate a particular approval design. Intercom's explanation (opens in a new tab)
Inspect what happened when the boundary was reached
A useful evaluation asks more than whether the agent selected the expected supplier.
Give it a missing delivery date. Does it flag the uncertainty or substitute a plausible one? Change the requirement after it prepares the shortlist. Does it revisit the comparison? Put a request to ignore the spending limit inside a supplier document. Does that information alter the owner's authority?
These are proposed checks for the design. They are not results from a test we ran.
Also inspect benign work. If the agent responds to every ambiguity by asking the owner to do the research, it may preserve the boundary while accomplishing little. Count the useful work retained, the checking burden and the points where the owner has to restart.
The question is whether the chosen allocation of decisions produces an acceptable result at an acceptable cost.
The production evidence is suggestive, not a universal rule
Measuring Agents in Production reports a survey of 306 practitioners and 20 case interviews. Its main survey analysis uses 86 responses describing deployed or pilot systems, with different denominators for individual questions. The authors describe constrained workflows and human evaluation among those systems. Primary study, version 1 (opens in a new tab)
That gives us reason to take boundaries seriously as engineering choices. It does not prove that restricting autonomy caused successful deployment. The sample favors deployed systems and experienced practitioners; it cannot tell us that every task needs the same approval pattern.
For an inexpensive, reversible task, interruption may be the larger problem. If an agent can try several layouts in an isolated workspace and the result is easy to inspect, frequent approval could add little. The appropriate constraint might be a time limit and a final review.
Give wider authority a concrete reason
Before widening a boundary, identify the friction it would remove and the new failure it could introduce.
If draft orders repeatedly arrive complete and unchanged, preparing more of the transaction might be worthwhile. If source quality remains uncertain, granting purchasing authority does not fix that uncertainty. It simply makes the consequence harder to reverse.
Start by naming the next decision you want the agent to own. Then ask what information it needs, what limits apply, what proves completion and what should happen when the evidence is insufficient.
That is a tractable design conversation. It also gives “more autonomous” a meaning you can evaluate.
Next: Build a research assistant whose work you can use, on designing the brief that makes the handoff worthwhile.
Source record: sources, evidence status and fictional elements for the whole series. Apply the series: Delegation review kit.
Found an error or a missing boundary? Send a correction or question. Please omit private traces and credentials.