Where the Buck Stops: Designing AI Agents Around Decision Rights

Most small and midsize US firms do not struggle to find places where an AI agent could do something. They struggle to decide where it should act. The familiar approach is to assign an agent to a department: one for sales, one for support, perhaps another for finance. It looks tidy on a slide. It also tends to miss the work that actually slows the business down.

The bottlenecks usually sit between departments, at the points where someone must make a judgment. A customer asks for a nonstandard refund. A sales representative wants an exception to the discount policy. A support ticket needs engineering input before it can be closed. These are not departmental tasks so much as cross-functional decisions, and they are exactly where automation can either reduce friction or create a new layer of hidden process debt.

Start with decisions, not departments

An org chart describes reporting lines. It does not describe how work moves. To place an agent well, begin with a decision inventory: a short list of the recurring judgments that determine whether work proceeds, stops, or escalates.

For each decision, capture five things: the trigger, the inputs required, the person or role with authority, the exception path, and the evidence left behind. A regional distributor might list credit-limit overrides, rush-order approvals, and carrier substitutions. A dental group might list insurance pre-authorization exceptions and scheduling conflicts. A commercial insurer might list claim triage and reserve adjustments.

These entries should be written in plain language. “Approve refunds above $500” is more useful than “handle customer accommodations.” The goal is not a comprehensive business process model. It is a working map of where judgment is exercised and where an agent might safely participate.

Three lanes: act, recommend, escalate

Once the decisions are visible, sort them into three lanes. In the first lane, an agent may act autonomously. These are decisions with limited financial exposure, clear policy boundaries, and easily reversible outcomes. A password reset, a standard order-status reply, or a routine document classification may qualify. The test is not whether the agent can produce an answer. The test is whether the firm is comfortable living with the answer without review.

In the second lane, an agent recommends and a human approves. This is the right fit for many cross-functional decisions: the agent assembles context, proposes an action, and routes it to a named authority. The human sees the reasoning, the policy version, and the relevant records. Approval is recorded, not implied.

In the third lane, an agent may prepare material but cannot decide. These are decisions with legal, safety, employment, or significant financial consequences. The agent can summarize a file or draft a response, but a qualified person retains authority.

This sorting is more useful than a department-based rollout because it forces a firm to name the decision owner. An agent assigned to “sales” may touch pricing, contracting, and customer communication. Those are different decisions with different risk profiles. The lane assignment should follow the decision, not the team.

The exception path is the product

Many automation proposals focus on the happy path. The exception path is where trust is won or lost. If an agent cannot complete a task, what happens? Does it stop silently? Does it send a vague notification? Does it hand off to a queue that no one owns?

A workable exception path has four elements. First, a clear trigger: the agent must know when it is outside its authority. Second, a named destination: a person or role, not a general inbox. Third, sufficient context: the agent should pass along what it saw, what it attempted, and why it stopped. Fourth, a status: the human reviewer should be able to record a decision and return the work to the flow.

This is not elaborate engineering. It is process design. Yet it is often omitted because departmental pilots are measured on speed and volume rather than on what happens when the unexpected arrives. An agent that handles eighty percent of routine requests but drops the remaining twenty percent into an unowned queue has not reduced friction. It has moved the friction somewhere less visible.

Document the handoff before the workflow

Handoffs deserve the same care as interfaces in software. Before an agent is connected to a live process, write down what it will receive, what it may do, what it must not do, and what evidence it must leave. Include the approval identity, the policy version, and the timestamp. If the agent uses a model or ruleset that changes, the handoff record should make that visible.

This documentation need not be heavy. A one-page decision register can be enough for many firms. The register should list the decision, the lane, the authority, the escalation path, and the review cadence. It should be maintained by someone with operational authority, not treated as a one-time artifact for an implementation kickoff.

Process debt accumulates quietly when automated steps are added without corresponding clarity about authority. A firm may find that its agents are efficient at drafting, routing, and summarizing, while its managers are less certain about who approved what. The remedy is not more automation. It is a clearer map of decision rights.

A lightweight mapping exercise

A practical first step is a ninety-minute working session with the people who handle exceptions. Ask them to list the last ten decisions that required judgment. Group those decisions by trigger and outcome. Assign each to one of the three lanes. Identify the decision owner and the escalation destination.

Then choose one cross-functional decision for a pilot. Measure cycle time, exception rate, rework, and the number of handoffs. Do not measure only the volume of agent actions. A useful pilot shows whether the decision moved faster and whether the handoff remained legible to the people receiving it.

For small and midsize firms, governance should fit the scale of the business. A quarterly review of the decision register, a named owner for each lane assignment, and a simple log of changes are usually sufficient. The aim is not to replicate a large enterprise control function. It is to keep authority visible as automation spreads.

Agents do not read org charts, and they should not be asked to. They operate on inputs, rules, and permissions. The organization’s real structure is the set of decisions it makes every day. Map those decisions first, and the place for an agent becomes far easier to see.