Infographic timeline showing AI evolution from 2017 to Now, with an LLM circle and speech bubbles illustrating plain language inputs.

The Interface Is Dissolving

For twenty years, the job was the same. A person points, clicks, types, and navigates to a result, and we design every step of that path. Software waits. The human is the engine.

Agents break that. When software can understand what you want and act on its own to get there, the interface stops being something you operate and becomes something you supervise. And here is the part most teams miss: the ones that win this era won’t have the smartest agents. They’ll have designed the clearest line between human judgment and machine action.

Drawing that line is the whole job now. This post is about how to do it.

How We Got Here

Five years ago, building a feature meant the same trip every time: a screen, an API, a row in a table. Picture booking a tee time. You pick the player, the date, and the number of golfers, tap an open slot, and hit Book it. The form POSTs to an API, business rules run, and a row lands in the tee_times table. We designed the clicks, and the human drove every one of them.

Then language became the interface. Now you can say “Book us a Saturday tee time” or “Summarize round 2 scores,” and the software reads your intent, calls the tools, and increasingly acts on its own. Transformers in 2017, GPT-3 in 2020, ChatGPT in 2022, GPT-4 and Claude in 2023, and agents in 2024. The question is no longer whether software can act on our behalf. It’s how we design the experience of letting it.

Timeline infographic of AI model evolution from 2017 to Now, with a central LLM circle and milestone labels below each year (Transformers to Agentic UX).

Three Places AI Shows Up

At Microsoft Build 2023, Steven Bathiche laid out three shapes AI takes relative to our apps, and the names still hold up:

  • Beside the app: the copilot or sidebar. The AI advises. You still operate. (Think GitHub Copilot Chat docked next to your editor.)
  • Inside the app: woven into a feature you already use. You upload scores_round2.csv, and the upload itself parses 72 rows, matches 70 players, and flags the 2 it isn’t sure about.
  • Outside the app: an agent working above and across your tools to finish a goal.

“Just add a chat box” is mostly Beside. The hard, unsolved design work lives Outside, where the agent acts on its own, so that’s where we’ll spend our time.

Picture it. One agent on your phone: “Set up a Saturday tee time for the four of us.” It reads four calendars, finds Saturday open, calls the course and holds the 9:10 slot, then asks once: “Send invites and post to #golf-league?” You say yes, and it does. You never opened the calendar, the course’s website, or Slack. Your job was approving, not clicking.

Chat screen showing agents discussing scheduling a Saturday golf tee time for four, with invites and Slack post confirmation later on.

From Operating to Supervising

Same request, two ways. To operate, you pick the day, scan every open slot, set players and cart, then pay. Five screens, every step yours. To supervise, you state the goal once and the agent does the legwork, then stops at the one decision that matters: Approve & book, or pick another time.

This is not a coat of paint on the old app. The unit of interaction moved from a click to a request, and that breaks years of assumptions. We got very good at information architecture, affordances, flows, and feedback, all of it about making manual operation faster. None of it tells us how a person hands off a goal and trusts what comes back.

And no, the answer isn’t “just add a chat box.” A blank text field is a wonderful way in, but it leaves every hard question unanswered. How does the user know what to ask? How do they watch it work? How do they step in when it’s wrong? Chat is the doorway. The rooms are still ours to design.

Four Jobs That Replace the Click

When you stop designing clicks and start designing delegation, four new jobs show up. Get these right and the agent feels like a teammate. Get them wrong and it feels like a loose cannon.

Ask: design the handoff, not the destination

Old interfaces captured intent through which buttons you pressed. Now the user has to say it out loud, so the asking surface is where we design. Don’t hand someone a blank box and call it AI. Show what the agent can do, offer starting points to tap, and capture constraints, not just goals (“Saturday morning,” “under $60 a player,” “don’t charge yet”).

The new error state is quieter than a 404. It’s a confident answer to the wrong question. “Set up Saturday golf for the group” could mean book a casual round for four, or register the team of eight for the tournament and charge a $400 entry. Same words, very different actions. The fix is cheap: reflect the intent back before acting. A five-second check beats undoing a booking later.

Watch: show the work without burying the user

Show nothing and it’s a black box. Show everything and nobody reads it. Aim for legibility, which means the same run at the depth the user needs. Build it in layers: a one-line glance that’s always on (“Booking Pinewood GC…”), a skimmable plan that shows where it is, and a full trace for the curious and the suspicious. Default to the glance and let people dig when they want to. Silence reads as broken, so name the work as it happens.

Three-panel walkthrough showing Glance, Skim, and Dig views for Booking Pinewood GC: left blank card, middle checklist, right code snippet.

Trust: put the checkpoint where reversal is hard

The hardest question in agent design is when the human gets to weigh in. Too often and you’ve rebuilt the manual workflow. Too rarely and you’ve built a runaway. Match the friction to the blast radius. Reading and summarizing need no gate. Drafting and staging can act freely when rollback is easy. Sending email, charging cards, and deleting in production are where an explicit confirm earns its keep.

The trap is confirmation fatigue. Gate everything and users learn to click “yes” without reading, so the one dialog that matters gets the same reflex. And watch for the agent that succeeds at the wrong thing and reports success: “Done, I archived all the inactive customers,” using the wrong definition of inactive and archiving 4,000 paying accounts. Show what it acted on, not just that it acted. A number that large should stop you.

Recover: design the way back

Here’s the question nobody plans for: what does “undo” mean once the agent has touched five systems? The old Ctrl+Z popped one change off one stack. An agent’s single action might book the slot, charge four cards, post to Slack, and email the foursome. There is no single stack to pop.

So design for it. Prefer reversible by default: archive instead of delete, draft instead of publish. Delay the irreversible with a short grace window (“Sending in 10 seconds. Undo?”). When you truly can’t undo, compensate: send the correction, issue the refund. And make the history of what the agent did part of the interface, not a log buried for engineers. The transcript becomes a control panel.

The Line is the Whole Job

The interface didn’t disappear. It changed jobs. It used to be the place you did the work, all screens and buttons and forms. Now it’s the place you direct and judge the work: where you state intent, watch it run, approve at the right moments, and recover when it’s wrong.

So “dissolving” doesn’t mean gone. Buttons, forms, and menus aren’t going anywhere, and most software will still feel familiar. Delegation is a new layer on top. We keep designing the clicks, and we add the asking, the watching, the trusting, and the recovering alongside them.

The teams that win won’t have the smartest agents. They’ll have drawn the clearest line between human judgment and machine action and made it impossible to miss.

Want to Go Deeper?

This post is really the next chapter of From Buttons to Conversations: A Revolution in User Experience (Chad Michel, Apress), which traces how interfaces are moving from buttons you operate to conversations you have.

For the engineering discipline behind shipping software like this, see Lean Software Systems Engineering for Developers (Doug Durham & Chad Michel, Apress, 2nd Edition). Both are on Amazon.

author avatar
Chad Michel Chief Technology Officer
Chad is a lifelong Nebraskan. He grew up in rural Nebraska and now lives in Lincoln. Chad and his wife have a son and daughter.

Related posts