Back in April, I wrote about the new front door that software organizations were beginning to build. The focus was on autonomous agents becoming legitimate product clients. We looked at llms.txt files and Model Context Protocol (MCP) endpoints designed so synthetic callers could query products directly without scraping brittle HTML.

Engineering teams have spent the past year or so writing up the necessary architectural work for these endpoints, but as that build-out accelerated, an unintended side effect crept into our product roadmaps. While we were busy optimizing structured data pipes for autonomous callers, the interfaces meant for actual people quietly turned into crowded, exhausting dashboards.

The Information Density Trap

When you spend weeks thinking about how to feed context windows, high density starts to look like thoroughness. An LLM wants raw parameter schemas and complete relational graphs delivered in a single payload.

That’s a problem when that product design reflex spills over into human UX. Over the past year, enterprise applications have become noticeably frantic. Screen layouts sprout auto-generated summary widgets, real-time alert tickers, and unprompted AI insight sidebars. Everything flickers. Everything demands attention. We took the high-bandwidth appetite of a synthetic model and assumed human eyes wanted the same firehose.

Human biology doesn’t change when an AI lab releases a new reasoning model. When software dumps dozens of real-time indicators onto a screen, people don’t feel empowered. They feel drained.

Recent research from Composite Global tracks a sharp user backlash against this trend. Across enterprise SaaS and consumer products alike, people are abandoning hyper-dense, AI-generated layouts. They’re seeking out calm design and soft-tech aesthetics that prioritize progressive disclosure, muted tones, and intentional breathing room.

Two Very Different Visitors

When you’re designing for human mental energy, it means being honest about who is doing the thinking.

When a synthetic agent hits an API endpoint, it wants total visibility. The model experiences no emotional fatigue (unless you consider their context window as fatigue… hmm). It simply consumes schema properties and returns tool parameters.

A human being sits in an entirely different reality. A person opens your application with limited working memory, competing deadlines, and a nervous system that registers visual clutter as background stress. When software insists on showing everything it’s technically capable of synthesizing, it forces the user to sift through noise just to find their next task.

Design teams at studios like Raw Studio have pointed out that craft in software design is returning to sensory restraint. Rather than stark white backgrounds and persistent red notification dots, effective tools rely on subtle textures, generous margins, and quiet defaults.

The goal is to create software that acts like a capable partner rather than an intrusive coworker interrupting every few minutes. In my opinion, good tools do their job and fade to the background until called upon.

The Dual-Client Model

For product leaders, this requires treating machine access and human interaction as two separate architectural and design layers.

Your first entrance belongs to people. Keep it open, forgiving, and quiet. Build it in your web and mobile applications with clear hierarchy, generous whitespace, and only the specific choices needed for the task at hand.

Your second entrance is for autonomous agents. Keep it strict, fast, and structured. Host it in your API specifications and MCP manifests. When an agent connects, provide unambiguous JSON and no decorative markup.

Problems multiply when teams try to build a hybrid middle ground. An interface that attempts to be both machine-dense and human-friendly ends up serving neither well. The agent encounters visual ambiguity, and the human walks away with a headache.

Feed the machines through the structured back door. But keep the front porch calm, quiet, and welcoming for the people who actually use your product.

Try a simple exercise in your next design review: remove half of the real-time status chips and secondary metric graphs. If users genuinely need them, let them click to expand. Most won’t.