Microsoft Power Platform · Agent Feed
Agent Feed maker experience
Making it easier for app creators to bring AI agents into everyday workflows — a clear way to discover, configure, connect, and manage which agents contribute to an app.
Overview
As AI agents became more integrated into business applications, app creators needed a clear way to understand which agents were available, determine how they could be used, and connect the right agents to an application.
I designed the maker experience supporting Agent Feed — a human-agent collaboration surface where people review, validate, and complete tasks surfaced by AI agents. My focus was simplifying how makers discover, configure, and manage these AI capabilities, and building an information architecture that could scale as more agent experiences got added.
Agent experiences touch multiple parts of the Microsoft ecosystem, so maintaining consistency required close collaboration across product areas. I shared and iterated on designs with partner teams to align navigation patterns, pane behavior, creation flows, terminology, and management interactions — reviewing how the design could scale as more AI-powered capabilities appeared within applications.
The design challenge
Adding AI agents to an application introduced a new set of concepts into an already complex creation environment. The interface needed to help makers answer a few fundamental questions: What agents are available? Which are connected to my application? Which can contribute work to the Agent Feed? Where do I go to create, configure, or manage them?
Early design reviews questioned whether a maker would even know where to go to add a suggested action. That discoverability gap — not a missing control, but a missing mental model — set the direction for the rest of the work.
Designing around maker intent
Instead of organizing the experience around the underlying AI technology, I organized it around what a maker is actually trying to accomplish — separating the actions available to them from the technical concepts powering those actions.
-
1
Create — start creating or adding an AI capability, from one entry point rather than several scattered ones.
-
2
Configure — understand what's already available and make changes, with status visible before a maker attempts an action.
-
3
Connect — determine which agents participate in the application experience.
-
4
Manage — return later to modify the configuration, without relearning where anything lives.
Instead of treating each area as an isolated feature, I explored ways for the interface to communicate the relationship between the command used to create something and the objects already displayed below it:
1
What can I create?
One creation menu for every AI capability, instead of scattered entry points.
2
What already exists?
Status visible up front — not published, published, or needs setup — before a maker attempts an action.
3
What can I manage?
Return anytime to check status or make changes, without relearning where anything lives.
Create, configure, and manage — in the feed
The maker side of Agent Feed: one creation menu for every AI capability, an empty state that teaches rather than just sits blank, and configuration status a maker can see before they try to use it.
1. Create — one menu for every kind of AI capability, instead of scattered entry points.
2. An empty feed explains what it's for and points to the next step, instead of reading as a dead end.
3. Configure — status is visible up front, with a direct path to finish setup.
4. Manage — once published, a maker can return anytime to check status or make changes.
Designing empty states as guidance
A maker encountering Agent Feed for the first time might not have anything configured yet. Rather than let an empty section read as missing content, I used it to explain what the area was for and direct the person toward an appropriate next step — treating the empty state as part of onboarding, not an absence of data.
Designing for AI without hiding complexity
Agents can have requirements that determine whether they can be connected to an application. I documented ways to surface that eligibility information and prevent unavailable actions up front — designing for explanation rather than failure, instead of letting someone attempt an action and discover later that it couldn't be completed.
Complex systems do not always require complex interfaces. The interface should expose complexity when it helps someone make a better decision.
A clearer maker experience for discovering and managing agents — treating AI capabilities as participants in a shared human-agent workflow, not isolated features.