Skip to content

Building AI Products & Workflows · Unit economics and UX patterns for AI features · lesson 15 of 18 · 13 min

Designing agentic product features users can trust

When your product acts on the user's behalf

More products now include features where AI takes actions for users: booking, sending, updating records, filing, purchasing, operating other software (including browser and computer-use agents). This raises the design stakes. A wrong suggestion costs a few seconds; a wrong action can cost money, relationships or data. This lesson covers the product patterns that make agentic features trustworthy.

The delegation contract

Every agentic feature is a delegation from a user to software. Make the contract explicit:

  1. Scope: what the agent may do (actions, systems, data) and what it may never do.
  2. Authority: whose permissions it uses. It should act with the user's delegated, scoped permissions, never broader.
  3. Limits: amounts, volumes, recipients, time windows.
  4. Checkpoints: which actions need confirmation, and how.
  5. Visibility: how the user sees what happened and why.
  6. Reversibility: how actions are undone, and what cannot be.

Core patterns

Plan, then act. For multi-step tasks, show a plan first ("I'll check availability for 3 suppliers, request quotes from those under budget, and draft a summary for you"), let the user edit it, then execute. Plans surface misunderstandings before they cost anything.

Tiered confirmation. Reading and drafting: no confirmation. Reversible low-impact actions: batch confirmation or undo window. Irreversible or high-impact actions (payments, external messages, deletions, legal commitments): explicit confirmation showing exact details.

Autonomy settings the user controls. Let users choose "always ask", "ask for new recipients or amounts over X", or "act and notify", per action type. Default conservative; let trust be earned.

An activity log in plain language. "10:42 Sent quote request to Al Noor Supplies (you approved at 10:41). Reason: under your budget of SAR 20,000." With links to the underlying records.

Undo and recovery. Delay sends (a short undo window), soft-delete, keep previous versions of edited records, and make reversal a first-class action.

Interruptibility. Users can pause or stop a running task at any time and see where it stopped.

Graceful hand-back. When the agent is stuck or uncertain, it stops and asks, with context, instead of guessing.

Computer-use and browser agents

Agents that operate websites and desktop apps like a person (clicking, typing, reading screens) can automate work where no API exists. They are also slower, more error-prone and more exposed to injected content on pages. Current guidance from providers and practitioners: run them in isolated environments, restrict the sites and accounts they can reach, require confirmation for purchases, logins and submissions, and prefer APIs or MCP tools wherever they exist.

Worked example: a procurement assistant for SMEs

A B2B platform serving small businesses in KSA and the UAE adds an assistant that sources office supplies.

  • Scope: search approved suppliers, request quotes, draft purchase orders. Never pay; never accept terms.
  • Authority: acts with the buyer's account permissions; cannot see other companies' data.
  • Limits: quote requests to at most five suppliers per task; purchase orders above the buyer's set threshold require manager approval.
  • Patterns: plan preview; tiered confirmation; activity log; 10-minute undo window on quote requests; a "stop" button on every running task.

In the pilot, the plan preview caught most misunderstandings (wrong delivery city, wrong quantity units) before any supplier was contacted, which the team measured by counting plan edits.

Hands-on: an action-plan contract and approval check

Define a plan schema your backend, UI and model all share, and enforce confirmation rules in code:

from typing import Literal
from pydantic import BaseModel, Field

class Step(BaseModel):
    action: Literal["search_suppliers", "request_quote", "draft_po", "send_message"]
    target: str = Field(description="Supplier or recipient name")
    details: dict
    reversible: bool
    impact: Literal["none", "low", "high"]
    reason: str

class Plan(BaseModel):
    goal: str
    steps: list[Step]
    assumptions: list[str]            # shown to the user to confirm or correct

CONFIRM_ALWAYS = {"send_message"}
MAX_QUOTES = 5

def requires_confirmation(step: Step, user_prefs: dict) -> bool:
    if step.action in CONFIRM_ALWAYS or step.impact == "high" or not step.reversible:
        return True
    return user_prefs.get(step.action, "always_ask") == "always_ask"

def validate_plan(plan: Plan) -> list[str]:
    problems = []
    if sum(s.action == "request_quote" for s in plan.steps) > MAX_QUOTES:
        problems.append(f"more than {MAX_QUOTES} quote requests")
    return problems

Generate the plan with structured outputs (see the workflow lesson), render assumptions prominently for the user to confirm, and execute steps only after the checks pass. Log each step with the approval that authorised it.

Go deeper

Go deeper: Computer-Use and Browser Agents: AI That Operates Software covers agents that operate websites and desktop apps, and Building Production AI Agents covers engineering agent loops, tools and safety.

Video lecture: Designing agentic product features users can trust

Lecture coming soon · 15 chapters · about 9 minutes. Read the full transcript below.

  1. Agentic product features
  2. Analogy: the house-sitter
  3. The delegation contract
  4. Plan-then-act + tiered confirmation
  5. More patterns
  6. Hand-back + computer-use agents
  7. Simple example: a calendar assistant
  8. Worked example: SME procurement assistant
  9. Business example (illustrative)
  10. Hands-on in the lesson
  11. Common mistakes
  12. How you'll know trust is calibrated
  13. Watch me do it: plan contract
  14. Recap
  15. Try this now (30 minutes)

Lecture transcript

Agentic product features

There's a big difference between an AI that suggests and an AI that does. A wrong suggestion costs you a few seconds. A wrong action, like an email to the wrong client, a duplicate payment or a deleted record, can cost money, relationships and trust. More and more products now include features where AI acts on the user's behalf. In this lesson you'll learn the delegation contract behind every agentic feature, the design patterns that make them trustworthy, and a plan schema you can enforce in code.

Analogy: the house-sitter

Here's an analogy. Giving an AI permission to act is like giving a house-sitter your keys. You tell them which rooms they can use, what they may spend on groceries, which deliveries to accept, and to call you before letting anyone in. You'd like a note of what happened each day. And you'd want to be able to take the keys back instantly. Agentic features need exactly that contract.

The delegation contract

Every agentic feature is a delegation from a person to software, so make the contract explicit. Scope: what it may do, and what it may never do. Authority: whose permissions it uses, which should be the user's delegated, scoped permissions, never broader. Limits: amounts, volumes, recipients and time windows. Checkpoints: which actions need confirmation. Visibility: how the user sees what happened and why. And reversibility: how actions are undone, and which can't be.

Plan-then-act + tiered confirmation

First pattern: plan, then act. For multi-step tasks, show the plan before doing anything. I'll check three suppliers, request quotes from those under your budget, and draft a summary. Let the user edit it. Plans surface misunderstandings while they're still free to fix. Second: tiered confirmation. Reading and drafting need none. Reversible, low-impact actions get batch confirmation or an undo window. Irreversible or high-impact actions, like payments, external messages, deletions and commitments, need explicit confirmation showing the exact details.

More patterns

Third: autonomy settings that users control. Let people choose always ask, ask only for new recipients or amounts over a threshold, or act and notify, per action type. Default to conservative and let trust be earned. Fourth: a plain-language activity log. Ten forty-two, sent quote request to Al Noor Supplies, approved by you at ten forty-one, because it's under your budget. With links to the records. Fifth: undo and recovery, like delayed sends, soft deletes and version history. And sixth: interruptibility, so users can pause or stop any running task and see exactly where it stopped.

Hand-back + computer-use agents

And one more: graceful hand-back. When the agent is stuck or unsure, it should stop and ask, with context, rather than guess. Agents that operate websites and desktop apps like a person, called computer-use or browser agents, can automate work where no API exists. But they're slower, more error-prone and exposed to instructions hidden in web pages. Run them in isolated environments, restrict which sites and accounts they can reach, require confirmation for purchases, logins and submissions, and prefer APIs or MCP tools whenever they exist.

Simple example: a calendar assistant

A simple example. A calendar assistant can schedule meetings for a busy consultant. Scope: book internal meetings and hold slots for clients. Authority: the consultant's calendar only. Limits: nothing before nine or after six, no more than three new meetings a day. Checkpoints: any external invite needs a tap to approve. Visibility: a daily summary of what it booked and why. Reversibility: every booking can be undone in one click.

Worked example: SME procurement assistant

Here's a worked example. A B2B platform for small businesses in Saudi Arabia and the UAE adds a procurement assistant. It may search approved suppliers, request quotes and draft purchase orders, but never pay or accept terms. It acts with the buyer's own permissions. It contacts at most five suppliers per task, and purchase orders over the buyer's threshold need a manager's approval. It shows a plan preview, uses tiered confirmation, logs every step, offers a ten-minute undo on quote requests and a stop button. In the pilot, plan edits caught most misunderstandings, like the wrong delivery city or quantity units, before any supplier was contacted.

Business example (illustrative)

Illustrative numbers for the procurement pilot. Over a month, forty buyers ran about three hundred tasks. Roughly one plan in six was edited before execution, mostly delivery city and units, and those edits prevented every one of those errors from reaching a supplier. Undo was used about a dozen times. Two managers raised their approval thresholds after the first fortnight, a sign of trust earned rather than assumed.

Hands-on in the lesson

In the hands-on section you'll define a plan schema shared by the model, backend and interface: a goal, steps with action, target, details, reversibility, impact and reason, and a list of assumptions shown to the user to confirm. Code decides which steps need confirmation, based on action type, impact, reversibility and the user's own settings, and rejects plans that exceed limits, like too many quote requests. Every executed step is logged with the approval that authorised it.

Common mistakes

Common mistakes. Using an admin or service account so the agent never lacks permission. Confirmation dialogs that say proceed? without showing the details. Asking for approval on everything, so people stop reading. No undo, even when it was technically easy. Logs written for engineers, not for users. And no way to stop a running task.

How you'll know trust is calibrated

How will you know users trust the feature appropriately? They loosen autonomy settings over time for routine actions, but keep approvals for high-impact ones. Plan edits catch mistakes early. Undo is used occasionally, not constantly. Support tickets about unexpected actions are rare. And when something goes wrong, the activity log lets the user understand what happened without contacting you.

Watch me do it: plan contract

Watch me do it. I open the plan contract. Step has an action from a fixed list, a target, details, whether it's reversible, an impact level and a reason. Plan has a goal, steps and assumptions, which the interface shows prominently. Next, requires confirmation: always for send message, always for high impact or irreversible steps, and otherwise it follows the user's own setting for that action, defaulting to always ask. Then validate plan rejects any plan with more than five quote requests. I generate a plan for twenty boxes of printer paper delivered to Riyadh. The assumptions list says delivery Jeddah. I correct it in the preview. Validation passes; the quote requests are reversible and low impact, and this buyer has set act and notify for them, so they run, while the purchase-order draft waits for confirmation. Every step is logged with the approval that authorised it.

Recap

To recap: agentic features are delegations. Make scope, authority, limits, checkpoints, visibility and reversibility explicit. Use plan-then-act, tiered confirmation, user-controlled autonomy, activity logs, undo, interruptibility and graceful hand-back. Treat computer-use agents with extra care. Your next step is to write the delegation contract for one agentic feature and sketch its plan preview and activity log. Next module: governance, adoption and scaling.

Try this now (30 minutes)

Try this now. Pick one feature where AI could act for users. Write its delegation contract in six lines: scope, authority, limits, checkpoints, visibility and reversibility. Then sketch two screens: the plan preview with editable steps and assumptions, and the activity log entry for one action. Show them to a potential user and ask what they'd want to change before trusting it.

Key takeaways

  • Agentic features are delegations: make scope, authority, limits, checkpoints, visibility and reversibility explicit.
  • Use plan-then-act, tiered confirmation, user-controlled autonomy settings, plain-language activity logs, undo and interruptibility.
  • Computer-use and browser agents need isolation, restricted reach and confirmation; prefer APIs or MCP tools where they exist.
  • Share a plan schema across model, backend and UI, and enforce confirmation rules in code.

Try it

Write the delegation contract (scope, authority, limits, checkpoints, visibility, reversibility) for one agentic feature, then sketch its plan preview and activity log screens.