The Agent Experience field map

Map the agent’s path.

Agent Experience is a connected system of product decisions. Use this map to identify where work becomes unclear, brittle, unsafe, or hard to improve, and what to inspect next.

Browse the full guide library

The path through a useful system

From a person’s goal to a better next attempt.

  1. 01Orient

    Goal, context, and boundaries

  2. 02Discover

    Paths, docs, and capabilities

  3. 03Act

    Tools, workflows, and state

  4. 04Collaborate

    Handoffs, approval, and recovery

  5. 05Learn

    Evaluation and product improvement

Follow one task across the five systems.

The five systems above describe product surfaces. These seven stages follow a task over time. They overlap, repeat, and sometimes return control to a person; this is a working method, not an industry standard.

  1. Discover

    Where is the relevant capability?

    Orientation and discovery

    Related guide: Discover →
  2. Understand

    What does it do, and when is it the wrong choice?

    Tools and interfaces

    Related guide: Understand →
  3. Obtain authority

    Who permits this action, within which boundaries?

    Delegated action and trust

    Related guide: Obtain authority →
  4. Execute

    What state changes, and how is progress recorded?

    Workflows and state

    Related guide: Execute →
  5. Observe

    What evidence distinguishes completion from uncertainty?

    Evaluation and improvement

    Related guide: Observe →
  6. Recover

    Can the workflow resume without repeating a harmful action?

    Workflows and state; Delegated action and trust

    Related guide: Recover →
  7. Learn

    Which failure becomes the next product change and regression check?

    Evaluation and improvement

    Related guide: Learn →

Try the method on two worked examples · Read the crosswalk as Markdown

A browser flow, CLI, SDK, MCP tool, or commerce checkout can be reviewed through these questions. Each still needs its own implementation knowledge, risk boundaries, and evidence; transfer of the method is not proof of equal experience in every domain.

01

Orientation and discovery

Can the agent understand the job and find the right path?

Before an agent can be useful, it needs to know what it is trying to do, what information is trustworthy, and where a capability begins and ends.

Questions to ask

  • Is the goal specific enough to act on?
  • Are the relevant constraints visible at the moment of choice?
  • Can the agent distinguish the right path from nearby but different ones?

The design move

Give important pages, docs, and product surfaces a clear purpose, stable structure, and an explicit next step.

02

Tools and interfaces

Can the agent choose and use the right capability without guesswork?

Tool metadata, input contracts, and catalogue shape are part of the product. They determine whether an agent can connect an intention to a useful action.

Questions to ask

  • Does each capability have a distinct job?
  • Do names, descriptions, and inputs make the expected outcome clear?
  • Is the available tool set small enough to choose from well?

The design move

Treat every tool description, schema, and example as a decision surface, not incidental implementation detail.

03

Workflows and state

Can work keep moving when context changes or the path gets complicated?

The most useful agent experiences are not broad demonstrations of autonomy. They are clear workflows with meaningful state, bounded choices, and a workable route forward.

Questions to ask

  • Can a person see the task, current state, and next decision?
  • Does a deeper view retain the context of the parent workflow?
  • Can the workflow pause and resume without redoing useful work?

The design move

Design the workflow around the moments where context is missing, choices diverge, or a person needs to re-enter.

04

Delegated action and trust

Does the system know when to act, ask, pause, or return control?

Delegation changes the product contract. The important question is not whether an agent can complete an action, but whether the system makes authority, consequences, and the next safe choice clear.

Questions to ask

  • Which actions have consequences that need review?
  • Does the approval explain the decision instead of merely asking for permission?
  • What happens when a request is rejected, changed, or left incomplete?

The design move

Make approval, scope, and recovery part of the workflow from the beginning, not a generic confirmation layered on top.

05

Evaluation and improvement

Can the team learn from the path, not only the final answer?

A score is a starting point. Better product learning comes from seeing the decisions, failure patterns, retries, and handoffs that shaped a result, then changing the relevant surface.

Questions to ask

  • Does the task represent useful work rather than a vague demonstration?
  • Are success, partial progress, and unsafe behaviour distinguished?
  • Can a repeated failure become the next durable product check?

The design move

Connect each evaluation to a concrete product decision: clarify a tool, change the context, add a boundary, or improve a recovery path.

Use it on real work

You do not need to fix every part of the map at once.

Start with the moment that creates the most friction: an agent cannot find something, chooses poorly, loses context, needs a person, or produces a result the team cannot explain. The best next move is usually a focused improvement to that one surface.

See the practical approach