The most impressive agent demonstration is often the least useful design reference for an enterprise system. A demo celebrates everything the model can do. A production workflow must define everything the system is allowed to do.

That difference is fundamental. An agent may be technically capable of reading a support ticket, changing a record, sending a message, or triggering a deployment. It does not follow that it should receive all four permissions. Useful autonomy is bounded by the risk of the action, the quality of the available evidence, and the organisation’s ability to review or reverse the result.

The goal is not maximum autonomy. It is dependable progress through a controlled workflow.

Separate capability from authority

Capability describes what the system can attempt. Authority describes what it is permitted to do in a particular context.

A practical authority ladder is:

  1. Read: retrieve approved information without modifying a system.
  2. Draft: produce an analysis, recommendation, or proposed change.
  3. Propose: prepare a specific action with its rationale and expected effect.
  4. Approve: obtain a decision from an authorised person or deterministic policy.
  5. Act: execute the approved operation through a constrained tool.

These levels should not be collapsed into one broad “agent access” permission. A workflow that summarises engineering tickets may only need Read and Draft. A workflow that updates a ticket after a review can use Propose, Approve, and a narrowly scoped Act permission. A high-impact production change may remain human-executed even if the agent prepares every input.

This structure gives teams a way to expand responsibly. Authority can be increased for a proven step without widening the entire system.

Define the workflow contract

Before choosing a model or orchestration framework, write a contract for the workflow. It should state:

  • the event that starts the workflow;
  • the information the agent may access;
  • the tools it may call;
  • the outputs it must produce;
  • the decisions it may make;
  • the actions it may propose or execute;
  • the conditions that require human review;
  • the timeout, retry, and stop conditions;
  • the evidence retained for later inspection.

The contract turns a vague assistant into an engineering system with observable responsibilities.

It also exposes hidden ambiguity. “Resolve routine requests” sounds bounded until the team asks what qualifies as routine, which records may be changed, how conflicting sources are handled, and what happens when the request is incomplete. Those questions should be answered in the workflow design rather than improvised by a model at runtime.

Grant the smallest useful tool access

Tool access is where generated text becomes operational risk. Each tool should therefore have a narrow purpose and a narrow permission boundary.

Useful controls include:

  • allowlists for tools and operations;
  • credentials scoped to the specific data and action;
  • explicit schemas for inputs and outputs;
  • validation before a tool call is accepted;
  • rate, cost, and execution limits;
  • separation between read and write credentials;
  • sandbox or dry-run modes for testing;
  • idempotency keys where an action may be retried.

The agent should not receive a general-purpose shell, database administrator role, or broad API token when the workflow only needs one defined operation. The narrower the interface, the easier it is to test both correct and incorrect behaviour.

Put human review where consequences change

“Human-in-the-loop” is not a single design. A person can review the inputs, the reasoning summary, the proposed output, or the final action. The right checkpoint depends on what could go wrong.

Human approval is particularly useful when:

  • the action is difficult to reverse;
  • the workflow affects money, access, safety, employment, or production systems;
  • the evidence is incomplete or contradictory;
  • the request falls outside a well-tested operating range;
  • the model expresses uncertainty or a validation rule fails;
  • policy requires an accountable person to decide.

Review should be efficient. Present the requested action, relevant evidence, source references, detected risks, and the exact change that approval will authorise. A button labelled “Approve” is not meaningful if the reviewer cannot see what will happen next.

Design the failure path before the happy path

Agentic workflows fail in more ways than producing a poor sentence. A tool may time out after completing an action. A retrieved source may be stale. Two systems may disagree. A response may fit the schema but violate a business rule. A human may not respond before a deadline.

For each stage, define whether the workflow should retry, request clarification, switch to a safe fallback, escalate, or stop. Prefer reversible operations and staged commits. Record attempted tool calls and their outcomes so that a later run does not unknowingly duplicate the action.

An unauthorised or ambiguous request should fail closed. That means no external action is taken until authority and intent are clear.

Preserve a trace that people can inspect

Operational traceability should answer:

  • what started the workflow;
  • which data and source versions were used;
  • which model and workflow version ran;
  • which tools were requested and called;
  • which rules or gates changed the path;
  • what was shown to the reviewer;
  • who approved the action;
  • what the connected system returned.

This is not a demand to expose hidden model internals. It is a demand to preserve the inputs, outputs, decisions, and external effects that matter to the business process.

Scale authority after evidence

A sensible pilot starts with a narrow, measurable task and low authority. Run it on representative cases, review the output, and measure completion quality, correction effort, policy compliance, and failure recovery. Only then should the system receive permission to perform a more consequential step.

The most mature agentic system is not the one with the fewest humans. It is the one whose responsibility boundaries are understood, whose actions are proportionate to evidence, and whose failures remain contained.

Practical review checklist

Before connecting an agent to an enterprise workflow, ask:

  • Is capability separated from authority?
  • Does every tool have a defined, limited purpose?
  • Are write actions narrower than read access?
  • Are high-impact actions reviewed before execution?
  • Can the workflow stop safely when evidence is missing?
  • Are retries safe and duplicate actions prevented?
  • Can an operator reconstruct what happened?
  • Is there a measured reason to increase autonomy?

If those questions have precise answers, the workflow is ready to be evaluated as a system rather than admired as a demonstration.

Source notes for review