Introducing Agent Experience (AX)
Toward an Agent-Native Way of Working
While digging into the new GitHub Copilot App — an agent-native desktop experience where work starts from real artifacts — issues, pull requests, repositories, sessions — and continues through planning, implementation, validation, review, and merge, I’ve started learning a bit more about the emerging concept of Agent Experience (AX).
AX is best understood as the experience of working with and around autonomous agents across time, tools, and artifacts, rather than merely the UX of a chat window or sidebar. In other words, AX begins when software stops being a momentary assistant and becomes part of the operating model of work itself.
What is an UX in the first place?
To understand why people are starting to talk about Agent Experience (AX), it helps to look at the progression from UX to Agent UX to AX.
Traditional UX, or User Experience, is about helping a person accomplish a task through software. The software is mostly reactive. The user clicks, types, navigates, and makes decisions; the application responds. A good UX minimizes friction.
Agent UX emerges when the software is no longer just an application, but an intelligent collaborator. The focus shifts from screens and workflows to conversations and interactions. How does the agent communicate? Does it ask useful clarifying questions? In other words, Agent AX focuses on how an individual agent is discovered, invoked, controlled, and trusted — questions such as transparency, control, multimodal interaction, explicit triggers, and the relationship between a chat surface and an artifact surface.
AX, however, begins when the interaction stops being a conversation and starts becoming a working relationship.
Consider a coding agent assigned to an issue on Monday morning. Over the next several hours — or even days — it explores the repository, creates a plan, modifies code, runs tests, opens a pull request, responds to review comments, and revisits the work when requirements change. At that point, the challenge is no longer whether the chat experience was pleasant. The challenge is whether the human can understand what happened while they were away, whether the agent’s decisions remain visible and auditable, whether context persists across sessions, and whether responsibility remains clear. AX is the discipline of designing that collaboration.
The distinction is subtle but important. UX asks, “Can I use this product?” Agent UX asks, “Can I effectively interact with this agent?” AX asks, “Can I effectively work with this agent over time?”
In that sense, UX optimizes interactions, Agent UX optimizes conversations, and AX optimizes collaboration. The moment agents become persistent participants in a workflow — capable of acting asynchronously, maintaining context, and owning portions of work — the design problem shifts from interface design to relationship design. That is the space AX seeks to address.
Why AX matters now
AX matters because the bottleneck in AI-assisted development has shifted. GitHub’s own rationale for the Copilot app is that agentic development made coding faster but also created disjointed workflows, scattered context, and more time spent reviewing agent-generated code. Internal enablement material in your environment makes the same point in operational language: once agents can generate code quickly, the hard part becomes managing work coherently across branches, workspaces, validation, review, CI, and merge. That bottleneck is not a model problem; it is an experience-design problem — and that is precisely what AX is meant to solve.
This matters beyond developer products too. Any product that embeds autonomous agents will eventually face the same question GitHub is facing in software engineering: what is the experience of delegating work to software that continues to act when the user is no longer staring at the prompt box?
A concrete end-to-end AX example in the GitHub Copilot app
Consider a realistic task in an e-commerce codebase: add loyalty-points expiry reminders, including a scheduled job, customer email templates, tests for suspended accounts, and a time-zone edge case found in review. The point of the scenario is not the feature itself; it is to show how the experience changes when the developer works inside an agent-native system instead of treating AI as a one-turn coding assistant.
Step 1: Work starts from a GitHub artifact, not a blank prompt
The developer opens My work in the GitHub Copilot app, finds the issue, and clicks Start a session.
GitHub’s docs say the app loads the issue context into a new session and automatically starts in Plan mode, while the product page describes the app as a GitHub-native desktop experience where sessions start from issues, pull requests, or prompts already in flight. This is the first AX shift: the unit of interaction is a tracked work item, not a free-floating chat request.
Step 2: The system proposes a path before it acts
In Plan mode, the agent proposes an implementation plan that the developer reviews before any code is changed. Public docs describe Plan mode as a mode where the agent creates a plan first and only executes after review and approval. Note that you can always edit the plan manually.
Step 3: The task becomes a persistent workspace
Once approved, the session runs in its own isolated workspace with its own branch, and the developer can choose whether it runs in a working tree, a local repository, or a cloud sandbox. GitHub’s cloud agent documentation adds that the agent can research the repository, make code changes, and run tests and linters in its own ephemeral environment. At this point the developer is no longer “using AI in the editor”; they are supervising an autonomous workstream with its own state and execution environment.
Step 4: The developer keeps moving while the agent works
Because the app supports multiple isolated sessions in parallel and GitHub’s blog places active sessions, issues, pull requests, and background automations in a single “My Work” view, the developer can switch to another task while the loyalty-reminder session keeps running. That is a defining AX moment: the product acknowledges that the human is now coordinating several streams of work over time rather than pairing synchronously with one assistant for one task.
Note that I can also see what other agents are doing in the context of My Work even if I triggered them from another UI — say, GitHub.com. For example, I can assign another issue to Claude Agent in GitHub.com and see the work in progress in my AX in the GitHub Copilot App.
Step 5: Preview and Pull Request
After implementation, you can have a view over the plan’s steps and code changes that have been made:
Now you might want to have a preview of your work before opening a PR. Within the app, you can run the changes locally:
Once you are happy with the result, the next step will be that of opening a Pull Request (PR).
GitHub’s PR management docs say the user can inspect the overview, see CI check results and review activity, switch to Files changed, and create a session directly from the PR to ask the agent for changes. The workflow has stayed continuous from issue to branch to PR without forcing the user to reconstruct context across browser tabs, chat history, and local branches.
Step 6: The work remains legible after the moment has passed
Later, the developer can return to the session history, use quick chats whose history is saved, or use /chronicle to summarize recent work across app and CLI sessions. GitHub’s blog also describes continuity across devices and over time as part of the new agent experience.
This is where AX separates most clearly from a one-off agent interaction: the task leaves behind a navigable trail of intent, execution, and review that can be resumed, queried, or explained rather than lost to a past conversation.
Conclusions
A final open question is whether AX eventually converges into a more unified work surface, regardless of role. As agents become persistent collaborators across development, architecture, marketing, and operations, we may see a single UI where work, agents, and decisions are visible end to end — while boundaries between roles, tools, and even distinct human–agent relationships become increasingly fluid. The challenge will be preserving clarity, accountability, and intent in that shared space, even as specialization happens more through agents than through separate applications.
References
- GitHub Copilot app: The agent-native desktop experience
https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/ - GitHub Copilot App — From issue to merge, in one app
https://github.com/features/ai/github-app - UX design for agents — Microsoft Design
https://microsoft.design/articles/ux-design-for-agents/ - Principles of Mixed-Initiative User Interfaces (Eric Horvitz, CHI ’99)
https://www.microsoft.com/en-us/research/publication/principles-mixed-initiative-user-interfaces/ - Working with agent sessions in the GitHub Copilot app
https://docs.github.com/en/copilot/how-tos/github-copilot-app/agent-sessions - Managing issues and pull requests with the GitHub Copilot app
https://docs.github.com/en/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
