From Assistance to Agents: How Much Autonomy Should a Workflow Have?

The wrong question is, “Can we build an agent for this?” The better one is: “Which decision may this agent make — and when must it stop?”

It sounds like a small distinction. In practice, it separates a helpful digital colleague from a system that creates more coordination, risk and clean-up than it saves.

Autonomy is a gradient, not a feature switch

There are several useful steps between a chatbot and an autonomous workflow. An assistant summarises. A copilot suggests options. An agent can collect information, make a plan and take a bounded action. Only recurring, well-defined flows justify broader execution.

The right step is not determined by technical possibility. It is determined by the consequence of being wrong. A flawed summary needs a different treatment from a wrong change in a customer system, a purchase, or access to sensitive data. NIST’s Generative AI Profile therefore treats risk as a lifecycle question, not only a build-time question.

A practical ladder has four steps:

Inform: The agent researches, summarises or structures.
Recommend: The agent proposes a decision or action; a person decides.
Execute with approval: The agent prepares the action end to end; a named person approves it.
Execute within boundaries: The agent acts inside fixed limits for amount, data, time and systems, and escalates exceptions.

Most teams can create meaningful value before reaching step four. That is not a lack of courage. It is good process design.

Draw four boundaries before you build

1. Task boundary. What result does the agent own? “Support sales” is not a task. “Create a meeting brief from approved CRM data and save it as a draft” is.

2. Decision boundary. Which actions may it trigger on its own? Define positive permissions rather than a long list of prohibitions. An agent may propose a meeting, for example, but not book it; it may create a draft but not publish it.

3. Data boundary. Which sources, fields and identities may it use? External documents, websites and tool output are data — not trusted instructions. OWASP’s 2025 Top 10 for LLM Applications names prompt injection as a leading risk. The resulting design principle is simple: untrusted content must never be able to overwrite an agent’s permissions, goals or safety rules.

4. Escalation boundary. When must the agent pause? Good rules are observable: missing required data, conflicting sources, low confidence, an unusual amount, a new payee, or an attempt to act outside the mandate. “When it is critical” is not a rule.

Let risk choose the lane

Not every initiative needs the same process. Three operational lanes make a useful distinction:

Green: personal or team support using approved data and no irreversible action. Test quickly, label clearly and collect feedback.
Amber: cross-functional use, moderately sensitive information or integrated systems. Before wider release: a named owner, data access review, test cases and an approval step.
Red: material impact on people, money, rights, security or regulated decisions. Stronger testing, formal accountability, traceable evidence and a clear exit path.

This is not a legal classification. It is an operating shortcut. Microsoft’s current Copilot Studio governance guidance also recommends zoned environments, guardrails and controlled lifecycles. The platform can change. The pattern remains: the greater the consequence, the more explicit rights, tests and observability need to be.

Human checkpoints must enable a real decision

“Human in the loop” is empty when the human is reduced to clicking Approve. A useful checkpoint shows what the agent saw, which assumption it made, what action follows and which alternative exists. It must allow meaningful intervention: edit, reject, defer or escalate.

In defined high-risk contexts, the EU AI Act requires measures such as appropriate human oversight, logging and documented risk controls. Whether a specific case falls into that category is a legal question. The practical conclusion is still universal: the more consequential the action, the more visible human decision-making must remain.

Measure more than speed

An agent does not succeed because it executes many actions. It succeeds when it accelerates correct work reliably and pauses cleanly under uncertainty. Measure at least four things:

Outcome quality: Was the decision or action substantively useful?
Safe abstention: Did the agent escalate unclear cases correctly?
Reversible failure: How quickly can a wrong step be detected and corrected?
Rework: Does the flow truly save time, or does it move work into review and repair?

One good metric is unexpectedly human: Would the accountable person use the same agent again tomorrow — and why?

The next practical move

Take one existing agent or candidate and describe on one page its outcome, allowed actions, data sources, exclusions and escalation rules. Then test five normal cases, three incomplete cases and two deliberately problematic cases. If the team cannot describe the expected response unambiguously, the agent is not ready for more autonomy.

Useful agents are not the ones that can act everywhere. They are the ones whose mandate is clear enough for people to grant them room responsibly.

Deutsche Ausgabe: Von Assistenz zu Agenten: Wie viel Autonomie darf ein Workflow haben?

Sources and framing

Editorial note: This is an operating framework, not a legal assessment of a particular AI system.