dumbing it down for the human

the best agentic interfaces will understand how much i actually need to see.

one of the major issues with agentic apps is that everything is becoming too much.

since i started using claude code, i've found myself managing more and more threads at once. the obvious response is to give agents more autonomy. but these systems still aren't reliable enough for me to completely let go.

this creates a strange tension. i want agents to do more for me, but i don't want to spend all day managing the agents doing it.

so what's the balance?

i don't have a complete answer yet. but i think good agentic interfaces will need to do three things.

  1. 1reduce what they show.
  2. 2protect the user's attention.
  3. 3build systems they can trust.

cut down stuff unless absolutely necessary

one of the beautiful things about ai is that we can now build almost anything we want. genuinely, the only thing stopping us might be the idea itself.

this is also a problem.

being able to build anything creates an even greater need to decide what not to build. this is especially true for agentic interfaces, where a single agent might be capable of doing dozens of different things.

the framework i keep coming back to is simple.

  • what is the purpose of this screen?
  • why is the user here?
  • what is the one thing the interface should help them understand or do?

if something does not support those answers, it should probably be hidden or removed.

whitespace is important. it gives the stuff that actually matters room to breathe.

protect the user's attention

in a world where agents are doing more of my work, i still need to verify decisions and attend to certain things. the hard part is figuring out what i actually need to see and when i need to see it.

agents are getting more capable, but they also take longer to finish meaningful work. i wrote about the design implications of that delay in perfecting the wait.

the obvious path to greater productivity is to run multiple agents in parallel. but that creates a new problem. someone still has to keep track of all of them.

i love using conductor, and i regularly have several agents working on different things at once.

six workspaces running in conductor, one agent's response open on the right
just an avg day running 6 agents on conductor.

with six agents and six responses, there is quite a bit to keep on top of. in this case, the actual bottleneck is me.

this seems to be where the market is heading. more agents will run in more places with more autonomy. you can see it in products like notion 3.0 and the growing number of dedicated agent interfaces.

notion's landing page pitching a 24/7 ai team
notion, pitching a 24/7 ai team.

but surely more agents also means more things asking for our attention.

conductor shows an indicator when an agent finishes working. this felt neat when i was running one or two agents. since i started running more, it has become pretty overwhelming.

the conductor dock icon with a red badge showing two finished agents
the little badge. fine at one, a lot at six.

the problem becomes more obvious when agents are working in the background while i'm trying to design, write, or reply to slack. slack already has an attention tax. soon, we will have an agent notification tax.

dia does something similar. it shows a notification dot and plays a sound when a task finishes. this works for one thread. across several concurrent threads, every useful notification becomes another interruption.

dia's sidebar with completion dots on several open threads
dia's completion dot, times every open thread.

today's agents are still mostly reactive, but we are already moving toward proactive agents that act without being asked. without careful design, we could end up being interrupted by different agents all day.

that sounds like its own kind of hell.

people already have very little attention to spare. bombarding them with text, diffs, pull requests, charts, and status updates leaves them more overwhelmed than before. even if the agents are doing the work, i still end up doing the work of keeping up with them.

the interface should know what deserves my attention now, what can wait, and what i never need to see.

build systems the user can trust

protecting attention requires trust.

an agent can only disappear into the background if i trust it to make reasonable decisions without me. but trust does not mean hiding everything. it means giving the agent enough autonomy to work while making its actions traceable when something goes wrong.

the ideal system should feel quiet most of the time. it should still provide clear ways to inspect what happened, understand why a decision was made, and intervene when necessary.

this could mean sandboxes, limited permissions, reversible actions, and a history of what the agent did.

we can already see different versions of this idea. ramp and robinhood are giving agents their own cards, which creates a clearer boundary around what they can spend. perplexity computer takes another approach by giving the agent its own contained computer to work inside.

robinhood's agentic credit card page, 3% cash back for your agent
robinhood
ramp's ramp-cli terminal, cards built for agents
ramp
perplexity computer, an agent with its own contained computer
perplexity

agents getting their own boundaries.

ps → this is roughly what i'm building with project friday. more on that later.

i want to keep control, but i only want to dig deeper when i really need to.

what this could look like

this is still a nascent issue and i definitely don't have the correct answer. i don't think anyone has the complete answer yet. but these are a few of my current guesses.

1
use progressive disclosure. show the user what requires attention now. keep background processes hidden, but make their history easy to find when needed.
2
choose the right moment. completion does not always require interruption. an agent could wait for a natural stopping point, an open calendar slot, or a moment when the user typically reviews their work.
3
prioritize before notifying. use an llm to decide what the user actually needs to know. everything else can be collected into a report for later. over time, the reasoning behind a decision may matter more than every individual code diff, copy change, or file update.
4
experiment quickly. no one has settled on the interface for this yet. that is what makes the space interesting. try things, observe where attention breaks down, iterate. ai gives us the ability to build faster, so use that speed to learn, not just to add more.