Give every step one accountable owner

Before choosing a model, an agent, or a workflow, write the request as a series of discrete steps. This makes hidden decisions visible. “Triage a claim” may contain reading a document, assigning a priority, looking up a policy, drafting a message, sending it, and escalating an exception. Those are not interchangeable tasks merely because they happen in one customer interaction.

Consider a hypothetical claims-intake workflow. A customer submission may arrive as free-form text, attachments, and incomplete details. The model can read it and turn the relevant material into a constrained record. A rules service can determine which queue applies. A live policy system can return the current coverage. The model can draft a handoff message. The email platform can send it. A senior adjuster can approve cases beyond a defined threshold.

That is not an argument for adding people or software to every line item. It is a way to prevent one component from silently absorbing work it is poorly suited to own. The model remains valuable precisely because it handles the ambiguous parts of the path. The surrounding workflow makes its result usable.

Language models are most useful where inputs are varied and interpretation is needed. Reading an inconsistent claim description, extracting a supplier name from an invoice, summarising a long record, or drafting a clear handoff are all tasks where language understanding adds value. There may be several acceptable phrasings or several plausible ways to structure a messy input.

That does not mean the output should be allowed to remain vague. The workflow should ask for the fields, categories, or permitted next actions that the following step needs. A constrained record is easier for a system to validate and easier for a person to inspect. The model supplies an interpretation; it does not become the organisation's final source of truth.

When the model is asked to act through a tool, the same distinction holds. It can identify the relevant request and select an allowed operation. The tool boundary should still define what may be read or changed. A model should not receive broad authority simply because it can express an instruction fluently.

Businesses already maintain systems for order status, policy coverage, approval thresholds, customer records, and transaction history. Those systems are not obstacles around an AI workflow. They are the components that make it possible to give an answer with authority.

A priority decision may sound like a language task, especially when it is described in a sentence. But if the organisation defines priority in a rules table or policy engine, the decision belongs there. The model can extract the relevant information and call the service. The existing system should apply the rule. The same boundary applies to current policy coverage, account status, and any other fact that changes over time.

Moving this work into the model has three costs. It uses model capacity for a lookup or rule that a simpler component can handle. It makes failures less traceable because an exact rule becomes a variable interpretation. And it risks presenting stale information with the same confidence as a live answer. A database or policy service is valuable because it has an accountable update path; a generated response does not replace that path.

This boundary also gives the team a useful way to diagnose incidents. If a priority is wrong, the team can inspect the extracted input, the rule that applied, and the system response separately. If coverage is missing, it is clear that the live record needs attention rather than a more elaborate prompt. Clear ownership turns a vague failure into a specific question for the component that can answer it. It also makes future changes safer: the team can adjust one boundary without quietly redefining the others.

Human review is not a fallback for every uncertain output. It belongs where the organisation needs someone to make a judgment, own an exception, or approve a consequence that should not be automated. A human may decide whether an unusual claim merits a different route, approve a high-value action, or interpret a policy gap that no existing rule covers.

The important distinction is between drafting and deciding. A model can prepare a recommended response, explain the facts retrieved from a system, or organise the information a reviewer needs. The person decides whether to approve an action when that decision carries material responsibility. This preserves speed in routine work without pretending that accountability has been automated away.

Ownership also makes exception paths visible. If the model cannot extract a required field, if the policy system returns no current answer, or if an action exceeds a threshold, the workflow should name who sees that state and what they may do next. An escalation path is part of the design, not an admission that the automation failed.

For each step, ask three questions before assigning it. The answers reveal whether the model should own the work, support the work, or stay outside it.

1. Reversibility — If this step is wrong, can the result be undone without material harm?
2. Stakes — What does a wrong outcome cost the customer, the business, or the person responsible?
3. Accountability — Who must explain, approve, or correct the result when it is challenged?

A low-stakes, reversible drafting task is a strong candidate for model ownership. A step governed by a live rule or record belongs to the system that maintains it. A high-stakes exception may need a person to decide, even when the model prepared the information well. Some steps are intentionally collaborative: the model drafts, the system supplies the facts, and a person authorises the outcome.

The point is not to minimise the model's role. It is to use it where its strengths have a clear boundary. A workflow that allocates ownership early is cheaper to operate, easier to diagnose, and clearer to improve because every failure has somewhere to go.

Production AI does not require a single component to do everything. It requires the right component to do each thing. The model works with ambiguity. Existing systems protect the rules and facts that must hold. People own the decisions that demand accountable judgment.

Start with the work. Assign one owner per step. Then make the handoffs, validations, and escalation paths explicit. That is how a promising assistant becomes a workflow your team can rely on.