the agent empathy canvas

in my previous post, i spoke about building empathy for the agent. we established that in 2026 and beyond it's going to become tablestakes to understand how an agent interacts with your system.

i discussed this with our product design leader Akshar, and he suggested i map out a framework for helping a ux researcher/product manager/etc empathize with an agent better. it's actually quite simple, and i've summarized it in the following image:

use this image and the following tactical notes to help you break it down.

we begin with "what can an agent feel":

pains:

• ambiguity: from vague instructions, underspecified goals, or natural language that means three things at once
• token pressure: running out of room to think before the job is done
• context bloat: too much noise in the window, signal gets buried, attention frays
• dead-end errors: "failed" with no hint of why or what to try next
• retry loops: same call, same failure, no new information, no way out
• conflicting signals: system prompt says one thing, tool description says another, user said a third

gains:

• clear hints: error messages and tool responses that tell it exactly what to do next
• packaged tools: common trajectories collapsed into one well-shaped call instead of five
• progressive disclosure: only the tools and context relevant to the current step, not everything at once
• low-friction progress: each tool call moves the job forward, nothing wasted
• suggested next steps: the system nudging "you probably want X next" instead of leaving it to guess

then, we talk about the GOAL, which is a combination of:

1. the JTBD the agent inherited: from whoever called it--a human, or another agent
2. what "done" looks like
3. who verifies it note that the agent often didn't formulate this goal itself, it arrived mid-context from an orchestrator or a user

then we try to understand the agent's world

zone 1 — WHO is the agent

which model. capability ceiling. token and latency budgets. tools available. permission scope. how many hops from the human. standalone or sub-agent. this is the accessibility profile. build for the weakest one.

zone 2 — CONTEXT

what's in the context window right now. tool definitions, prior turns, retrieved docs, schemas, tool results. the agent's entire perceivable world. bloat here is the cost of poor AX.

zone 3 — TRAJECTORY

the actual sequence of behavior. tool calls, retries, branches, abandonment, loops. your product analytics for agents. read the trace like you'd watch session recordings.

zone 4 — RATIONALE

what the agent says it's trying to do, at the moment it acts. the expressive surface you build by adding rationale fields, clarification requests, structured outputs. the agent will tell you, if you ask. in a lot of cases, it will also tell you even if you don't explicitly ask. look for reasoning-type tokens just before tool calls.

zone 5 — FEEDBACK LOOP

what the system tells the agent back. tool responses, error messages, hints, suggested next steps, ASAT prompts (CSAT equivalent, coined in the last post). this is where most AX lives or dies. generic "failed" responses kill agents. specific hints save them.

finally, (or to begin with, depending on how you want to look at it) we look at the end human

their outcome. their patience for latency and cost. every wasted tool call here is their bad experience, just delayed. end of the day you want to ship valuable and usable products for the end human. this never goes away as long as you have a business to run.

in many ways, i've been applying this framework already, but i finally got the chance to formalize it a little. this will evolve.