Autonomous Agent vs Assistive Agent

An autonomous agent can progress through an assigned task without a person directing every step. An assistive agent supports a person who retains more immediate control over the work. Neither description tells you which actions are permitted. A system can autonomously prepare a read-only analysis while remaining unable to place an order; an interactive assistant can execute a consequential action after explicit approval.

The right design allocates decision rights action by action. This guide is for an operations owner deciding how much work to delegate. Its illustrative example is a replenishment proposal assistant that combines approved inventory facts and an existing replenishment policy. The agent helps assemble and explain a proposal; it does not replace demand forecasting, inventory optimisation or purchasing authority.

Separate initiation, discretion and execution

Initiation answers what starts the task: a user request, a schedule or an authorised event. Discretion answers which steps the system may choose. Execution answers what it may change. These dimensions can vary independently.

A scheduled report can follow a fixed workflow with no agentic choice. An interactive assistant can dynamically investigate a question. A background agent can be permitted only to read and draft. Therefore, “runs automatically” is not a complete description of autonomy or risk.

Microsoft describes autonomous agents using event triggers, instructions and defined boundaries. The practical implication is to specify those boundaries rather than equating autonomy with unrestricted authority. See the primary guidance.

Build a decision-rights ledger

For each operation, record the purpose, trigger, inputs, permitted action, decision owner and evidence of completion. Add a rule for when the system must stop. This ledger is more useful than assigning the whole product a single autonomy level.

In the replenishment example, reading current stock, retrieving an approved policy, drafting a proposal, reserving stock and submitting a purchase order are different operations. Each has a different consequence and may require a different authority. Do not grant the last operation merely because the first three were successful in a pilot.

Illustrative decision rights for a replenishment proposal assistant

Operation	Proposed delegation	Required boundary
Read permitted inventory records	Proceed within the assigned case	Enforce location and role access
Retrieve the approved replenishment policy	Proceed with source verification	Use the applicable version and units
Prepare a proposal	Proceed and label it as a draft	Show assumptions and evidence; preserve unknowns
Change a replenishment parameter	Keep with the authorised owner	Separate approval and controlled system update
Submit an order	Outside the initial scope	A later capability needs its own authority and acceptance evidence
Handle conflicting stock information	Pause and route for review	Do not invent a reconciled balance

This is a proposed design, not a statement of a universal purchasing rule. The organisation must decide its actual authority model. Some may permit more automation under established controls; others may keep all commitments with people.

Choose assistive work when the objective is still being formed

A planner investigating an unusual demand pattern may need to ask exploratory questions, compare explanations and change the problem definition. An assistive agent can help gather evidence while the planner steers. Delegating a vaguely defined “optimise stock” objective would conceal unresolved assumptions about service levels, cost and constraints.

Assistance is also useful when important context is available only to the person. The user may know that a location is closing or a promotion has changed. The system should capture relevant approved facts explicitly rather than relying on an unrecorded conversation or inferring them from unrelated data.

Do not treat the human's presence as a complete control. The interface must show evidence, assumptions and the consequence of approval. If the person cannot realistically inspect what matters, the design may create nominal oversight without effective judgement. See human oversight for agents.

Delegate bounded work when the assignment is stable

Autonomous progress is more useful when the objective, sources, allowed tools and stop conditions are clear. For example, the assistant can prepare a proposal for an assigned set of items using the approved policy, then queue it for review. The reviewer receives a completed evidence pack rather than supervising every lookup.

Define what counts as a complete pack. It may need the inventory snapshot, policy version, relevant calculation from the authorised system, exceptions and unresolved questions. The agent should explain or organise those outputs without substituting its own arithmetic or optimisation for the established calculation.

Set execution limits and a meaningful stop state. If evidence remains unavailable after the permitted attempts, the task should become an exception with a clear owner. Endless searching is not useful autonomy. The planning guide explains how to bound adaptive investigation.

Approval must attach to a specific proposal

A reviewer should see the exact items, quantities, source context and action being approved. Store the proposal version and approval record together. If a material field changes, determine whether the approval remains valid; do not quietly apply it to a different action.

Consider an approved draft whose stock snapshot becomes stale before execution. The application should revalidate the conditions required by the business rule. If the result changes materially, it should return for review or follow an explicitly authorised policy. The model's confidence does not resolve the mismatch.

Separate approving a recommendation from authorising a system action. A planner may agree that a proposal is worth considering while lacking purchasing authority. The identity and command layer must enforce that distinction. The guardrails guide covers controls outside the model.

Assess reversibility and detectability

Ask how an error would be discovered and what recovery would require. A private draft can often be corrected before anyone relies on it. A message sent externally cannot be unsent in the same sense. A transaction may require a compensating business process rather than a technical rollback.

Read-only work also needs boundaries. Reading a restricted record or exposing confidential information can be consequential without any write operation. Evaluate data access, disclosure and downstream reliance alongside transaction effects. “No write tools” is a useful constraint, not a complete risk assessment.

Where recovery depends on another system or person, include that dependency in the operating model. Do not count an action as easily reversible merely because a cancel button exists. Check the actual cancellation conditions and what happens when part of the process has already completed.

Expand autonomy through evidence

Start with the proposed operating boundary and evaluate it on representative cases. Observe the quality of drafts, correctness of tool use, escalation behaviour and human review burden. A successful demonstration of information gathering does not prove readiness for financial commitments.

For each proposed expansion, identify the new failure modes and the evidence needed to address them. Moving from draft preparation to submitting an approved command adds state validation, duplicate protection, receipt handling and incident recovery. Moving to unattended submission changes the authority and monitoring requirements again.

Use explicit release decisions rather than assuming that elapsed time in production earns more permissions. The testing framework explains how to examine complete outcomes and critical failures separately.

Make intervention practical

Users and operators need to know what is running, what has been completed and what can still be cancelled. A stop control should have defined semantics: stop new tasks, pause the current run or disable a particular action. These are different operational effects.

Decide how to handle work already in flight. Disabling a tool does not necessarily undo a request accepted by another system. Preserve the relevant operation identifiers and reconcile results. The orchestration guide covers this distinction between stopping execution and restoring business state.

Also provide a route to resume after review. The person should not need to recreate the whole case, but the system must recheck material conditions that may have changed. Record who resumed the task and under which approved version.

Choose the boundary that improves the actual work

Autonomy also differs from the way a person works with the system. A copilot can execute permitted actions, while an agent can require frequent human decisions. Use the agent versus copilot comparison to separate the working relationship from the authority granted to each action.

Assistance can be the right long-term design, especially for expert judgement and changing objectives. Autonomy can be useful for well-bounded preparation or execution with appropriate controls. A hybrid can let the system progress independently while preserving human decisions where they matter.

Open for AI's AI agent development can be scoped around those decision rights. To discuss the appropriate autonomy for your workflow, bring a list of read, draft and commit actions, the people authorised to approve them and an example of an error that would require recovery. That makes delegation a concrete design decision.