Sigma Studio
From tools to helpers
A few years ago, it felt like every product added a chatbot, from banking apps to coffee machines. Now many users are tired of talking to their software. They don't want a chattier assistant. They want something that understands the goal and gets on with it, without being watched at every step.
That's what we mean by agentic UX. Users stop doing the steps themselves and start managing the outcome. This post covers the design, the engineering and the psychology behind that change.
How we got here: four stages of computing
Each stage of human-computer interaction has cut down the work between what a person wants and what the computer does.
1. Commands
In the command-line era, the user had to give every instruction, in the machine's own language. One typo and nothing worked. It took a lot of memory and focus.
2. Windows
Graphical interfaces added cursors, icons and menus, so you didn't have to remember commands. But every step was still manual. To send an email, you found the button, clicked it, typed the address and pressed send.
3. Chat
Chat interfaces let us talk to software in plain language for the first time. But chat brings its own problem: a long back-and-forth that is often slower than clicking a button.
4. Agents
Now the user can state a goal and let the software work out the steps. The software acts on the user's behalf, more like a helper than a tool.
What makes an agent different from a chatbot
A chatbot waits for your next message. An agent works toward your goal on its own.
Giving instructions vs. handing off a goal
- Instructions: "Open the spreadsheet, filter by Q3, find the Revenue column and work out the average."
- Hand-off: "Prepare a financial summary for Q3 and point out anything unusual."
With a hand-off, the software handles the how. The user focuses on the what and the why.
The user's role changes
The user moves from doing the work to overseeing it. They're no longer clicking through every step. They check in on the agent's progress and step in when needed.
So the design moves away from small interactions like clicks, drags and toggles. Instead, the user checks and approves the agent's work at key milestones.
Three things an agentic product needs
1. It understands intent
Most interfaces are built around the click. Agentic products are built around intent. The product needs to catch not only what the user says, but the business reason behind it.
That takes memory: the user's past choices, their brand voice, their company's rules. When someone says "make it look professional", the agent should know what professional means for that person.
2. It shows its work
The biggest barrier to handing off work is trust. When people give up control, they want to see what's happening.
Simple live status markers help a lot. They show what the agent is doing right now, what's next, and how sure it is. That gives users the confidence to step back.
3. The interface changes with the task
If the software does most of the work, fixed sidebars and menus matter less. Instead, you can show small task panels that appear only when the agent needs input, or when the user wants to look at a result.
The layer underneath: context
To act for a user, an agent needs more than a prompt. It needs a layer in between that turns what the user wants into structured data, such as JSON, that the system can act on, and turns results back into plain language.
We suggest mapping how the things in your product relate to each other, for example users, projects, supplies and deadlines. This is often called a knowledge graph. With it, the agent doesn't have to guess. It can see how a late shipment pushes back a project's delivery date.
Building it: the technical side
Agentic UX is an engineering problem as much as a design one. You need a setup that connects fixed code with an AI model whose answers change from run to run.
State for work that doesn't follow a fixed path
In a normal app, button A always leads to screen B. In an agentic product, the agent can produce many possible states as it goes, and the UI has to show any of them.
Agents also run tasks that take minutes or hours. Users should be able to leave the app, come back and find the agent's progress right where it was. That means keeping state on the server and pushing updates to the client, for example with WebSockets or Server-Sent Events.
Hiding the wait
Waiting hurts trust. While the agent is working, the UI should still respond right away.
One way is to show the shape of the answer before it's ready. If the agent is drafting a report, show the headings and placeholders straight away. The work takes the same time, but the wait feels shorter.
Another is to stream progress. As the agent finishes each sub-task, the screen updates. Instead of one final result screen, the user watches the work come together.
Design tokens keep generated screens consistent
If an AI puts together its own screens, it needs a strict set of design tokens and components to work with: buttons, inputs, cards. The AI arranges those parts for the task. Even a brand-new screen then looks like it belongs in the product.
Designing for trust
People won't hand important work to a black box. If you want people to actually use an agent, it has to explain itself.
Show the reasoning, not a spinner
Instead of a generic "Processing..." spinner, show a short, readable log of what the agent is doing. For example:
- Checking 500 LinkedIn profiles...
- Keeping only people with CTO titles...
- Reasoning: Audience B engages more than Audience A...
Not everyone wants that much detail. Keep the default log short and high level, and let people who want more open up the exact prompts and steps the agent used.
Confidence decides what happens next
Each result can come with a confidence score that sets what the agent does next. For example:
- High confidence (90-100%): the agent carries on by itself.
- Medium confidence (60-89%): the agent pauses and asks the user to review and approve.
- Low confidence (below 60%): the agent stops and asks for more detail, or hands the task back.
Rules like these keep a system safe. The agent never makes a high-stakes call on its own when it isn't sure.
A four-step plan for founders
You don't have to switch everything at once. We suggest four steps.
Step 1: Find the busywork
Look for the places in your product where users spend the most time clicking, dragging and typing in data. Those are the best places to start.
Step 2: Add a way to state a goal
Build a command bar or goal input where users can say what they want in plain language. Connect it to a backend that turns that request into specific API calls.
Step 3: Show before you automate
Add the status markers and the reasoning log first. Before the agent does anything, show the user what it would do.
Step 4: Let it run, a little at a time
Once users trust it, let the agent finish low-risk tasks by itself. Give it more room as the system improves and users get comfortable.
An example: a construction dashboard
We've redesigned a construction management dashboard, and it's a good place to see how this could work.
The problem
Project managers spent a lot of their day checking supply status by hand, comparing it with inventory and flagging delays. The screen was a wall of tables and filters, and you needed to know the tool well to find anything.
What an agent could do
Instead of the filters, the manager types one goal: "Make sure the Berlin project has all its supplies by Friday." The agent then:
- Checks current stock through the ERP's API.
- Reads the shipping logs and finds a missing steel delivery.
- Looks at weather data to see if the route could cause more delays.
- Drafts a fix, for example ordering from a local supplier at a slightly higher price to meet the deadline.
- Sends the plan to the manager to approve.
The manager stops chasing data and starts making decisions. How the agent works becomes a big part of why people use the product.
The risks we need to design for
Handing decisions to software raises real questions. Here are three we keep in mind.
1. Trusting the machine too much
People tend to trust an automated system even when it's wrong. This is called automation bias. To counter it, ask for a clear confirmation before any high-impact action, like spending budget or deleting data.
2. Learning bad habits
Agents learn from how people use them. If a user keeps making biased choices, the agent can pick up the same bias. Check the agent's logic for bias regularly so it stays fair.
3. The designer's job changes
Designers are no longer only drawing screens. They're also setting the rules, the logic and the personality of the agent. That means designing for a range of possible outcomes, not one fixed path.
Terms used in this post
- Agentic UX: design for products where users hand goals to AI agents instead of doing each step.
- Intent: the goal behind a request, which the agent turns into a list of tasks it can run.
- Hand-off interface: a UI where users manage outcomes instead of doing each sub-task.
- Reasoning log: a readable record of the steps and decisions the agent took.
- Generated UI: screens the AI puts together from existing components, based on the task at hand.
- Context layer: the layer that gives the agent context, brand voice and business rules.
- Status marker: a small live sign of what the agent is doing right now.
- Overseer: the user's new role, checking and approving the agent's work.
Where to start
Users will keep moving toward products that do the work for them. If you run a SaaS product, start with step 1: find the busywork your users repeat every day.
That's the kind of work we enjoy: taking a design and making it run in a real product, AI included. If you'd like help with that first step, get in touch.