Graduated autonomy levels
Autonomy is not binary. Enterprise agent systems use graduated levels ranging from draft-only assistance to fully autonomous operation, with clear boundaries for when each level is appropriate. The key principle is matching autonomy to task criticality: even a highly capable agent should require oversight for irreversible or high-stakes actions.
Autonomy levels for enterprise agents
| Level | Name | Agent can | Human role | Risk level |
|---|---|---|---|---|
| 0 | Draft only | Suggest text, plans, or structured outputs; never executes | Review, edit, and approve before any use | Low |
| 1 | Suggestion | Propose actions or tool calls with clear explanation | Explicitly accept or reject each suggestion | Low to medium |
| 2 | Supervised action | Execute only after human approval; may request guidance | Approve, edit, or reject before execution | Medium |
| 3 | Autonomous with escalation | Execute within policy bounds; escalates unclear or high-risk cases | Handle escalations; set policy and review audits | Medium to high |
| 4 | Fully autonomous | Execute within defined scope without per-action approval | Define scope, monitor outcomes, and intervene on signals | High |
Match autonomy to task criticality, not just capability
A sophisticated agent might be capable of autonomous patient messaging, but if the task involves sensitive communications, the system should still require approval or supervision. Autonomy levels are a governance choice, not just a technical capability.
Enterprise Agentic Architecture and Design Patterns
Salesforce Architect guide covering the Interaction Patterns (Greeter, Operator, Orchestrator, Listener, Workspace), autonomy levels, and agentic UX principles for enterprise deployments.
Read the Salesforce design patterns guideConfidence-based escalation logic
Systemic escalation ensures that when an agent faces ambiguity or risk beyond its threshold, it halts autonomous action and safely transfers context to a human operator.
Dynamic Escalation Flow
Loading diagram...
Context-Rich Handoffs
Escalation shouldn't be a blank slate. Best practices from Azure and AWS emphasize "Context-Rich Handoffs": the agent must provide the human operator with its reasoning chain, the specific tools it used, and the exact point of uncertainty. This prevents the human from having to restart the reasoning process from scratch.
Human-in-the-loop design patterns
Human-in-the-loop (HITL) design creates explicit approval boundaries where agents can propose but not commit without human review. These patterns are essential for any workflow with material consequences: clinical decisions, financial transactions, data modifications, or external submissions.
Human-in-the-loop approval flow
Loading diagram...
Human-in-the-loop patterns
| Pattern | When to use | Key mechanism | Example use case |
|---|---|---|---|
| Approval gate | Irreversible or high-stakes actions | Agent proposes; human must explicitly approve before execution | Chart writeback, prior auth submission, payment processing |
| Correction loop | Draft generation with refinement | Agent produces draft; human edits and agent learns from corrections | Clinical documentation, denial appeal letters, referral summaries |
| Shadow mode | Evaluation or comparison without side effects | Agent runs in parallel but actions are not executed | Comparing agents, training reviewers, testing new prompts |
| Override control | Autonomous execution with fallback | Agent proceeds unless human intervenes or signals exceed thresholds | Automated triage with manual override on confidence drop |
| Escalation boundary | Complex or ambiguous cases | Agent recognizes out-of-scope or low-confidence situations and requests human help | Complex prior auth, contradictory guidelines, novel presentations |
Escalation rules should be explicit and testable. Rather than relying on the model to intuit when to ask for help, define clear signals: confidence thresholds, missing data, conflicting evidence, or policy violations. These rules should be logged and observable so you can audit when and why escalations occur.
Interaction Patterns
Interaction patterns are foundational designs that focus on agentic engagement and user experience. These patterns manage the entry point for human users and coordinate the flow of conversation.
The Greeter pattern is a simple, easy-to-implement pattern that uses natural language to determine user intent, then routes the user to the appropriate human agent. It facilitates a seamless first contact for customers while maximizing intent resolution.
The Operator pattern builds on the Greeter by routing requests to the appropriate specialist agent or human, negotiating intent if needed.
The Orchestrator pattern manages an AI Agent swarm. It remains the first point of contact, passing utterances to one or more specialist agents and aggregating responses for the user.
The Listener/Feed pattern surfaces context and insights during the flow of a conversation. Triggered during each conversational turn, it finds and displays relevant information for an employee.
The Workspace pattern (Radar O'Reilly) manages a responsive single-pane-of-glass UX. It processes utterances to dynamically update portions of the UI with relevant content.
Agentic UX patterns
UX for agent interactions is fundamentally different from traditional UI. Users need to understand what the agent is doing, why it is making specific choices, and what will happen next. This requires transparency, clear controls, progressive disclosure of reasoning, and explicit feedback loops.
Agentic UX principles
| Principle | What it means | UX implementation |
|---|---|---|
| Transparency | Users can see what the agent is doing and why | Show plan, tool calls, reasoning summary, and confidence |
| Control | Users can intervene, adjust, or stop the agent | Approve/reject buttons, edit drafts, adjust parameters, abort |
| Trust building | Users understand agent capabilities and limitations | Clear scope statements, failure warnings, capability bounds |
| Progressive disclosure | Users can drill into details without overwhelming defaults | Summarized reasoning with expandable traces, collapsible steps |
| Feedback loops | Users can correct the agent and see the impact | Edit drafts with explanations, rate responses, provide rationale |
Showing reasoning chains and confidence indicators helps users assess whether to trust an agent's output. A reasoning summary might explain: "I searched for recent lab results, found three values above threshold, and flagged this as urgent." Confidence can be expressed as a percentage, a qualitative label (high/medium/low), or by highlighting uncertain elements. The goal is to give users enough context to make informed decisions about approval or escalation.
Users need to understand what the agent will do BEFORE it acts
For autonomous or supervised actions, the UI should preview the proposed action before execution. For example, before sending a patient message, show the full message content, recipient, and timing. Before updating a record, display the field changes and source. This preview-and-confirm pattern prevents surprises and supports meaningful human oversight.
Knowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.