Your most valuable users are about to stop showing up as often. Their agents are handling everything else.
The sessions that remain look nothing like the ones your product was designed for. Every login is a decision that matters: approving a workflow the agent assembled, overriding a recommendation that feels wrong, catching an exception the automation flagged but couldn't resolve. Familiar layouts, progressive disclosure, workflows that rewarded muscle memory. None of that helps when someone shows up for five minutes to make a call on something the system couldn't handle on its own.
This is a product design problem that most teams haven't named yet. And if you're building or leading a product right now, I think it's the most important one in enterprise software.
The shift nobody designed for
The headless infrastructure layer is table stakes. Every enterprise CIO I've talked to is demanding APIs, machine-readable specs, and standard protocols. The question of whether to build for agents has been settled.
What almost nobody is thinking about is what happens on the other side.
What's left is all judgment calls, and the consequences of getting them wrong are personal.
Higher-stakes, less frequent, more cognitively demanding. They need better interfaces than anything you've built before.
Most SaaS companies will build the headless infrastructure because the market demands it. They'll expose the APIs. And then they'll discover that great infrastructure with a bad oversight screen is how you get approvals rubber-stamped by exhausted humans making decisions in 90 seconds without the context to make them well.
Five principles for product builders in the agent era
I've been thinking about this for a few months now, watching what works and what doesn't as agents move from demos to production workflows. Five principles keep showing up.
1. Treat agents as a first-class consumer
Most products bolt on an API after designing for humans. Flip the order. Your agent consumer will likely drive more volume than your human users within a year or two.
This means building on the standards agents already speak. Markdown files are becoming the universal interface between humans and agents. CLAUDE.md, AGENTS.md, DESIGN.md: these are all variations of the same pattern, a structured document that tells the agent what it's working with. If your product accepts markdown as input, agents can use it immediately. If you invent a proprietary format, you're asking every agent builder to write a custom integration.
The same logic applies to protocols. MCP (Model Context Protocol) is emerging as the standard for tool discovery and invocation. A2A (Agent-to-Agent) handles cross-agent communication. These aren't competing with your product. They're the rails your product should run on.
Support them natively. Don't build parallel systems that do the same thing with different syntax. The products that win adoption will be the ones agents can use without a tutorial.
The interaction model has shifted. It used to be User to Software. Now it's User to User's Agent to Software's Agent to Database. Two systems collaborating toward a single outcome. Your product sits between those agents, and the interface quality between them determines what context is available when the human eventually shows up for the judgment call.
The counterintuitive part: designing well for agents actually improves the human experience too. Supporting standards forces you to be explicit about what your system needs. Clear schemas force you to name your assumptions. The clarity compounds.
2. Design living surfaces, not static screens
The old model was a fixed dashboard you visited daily. You knew where everything was. You built mental models of the layout. The screen was the same whether you were making a routine check or a critical decision.
That model breaks when sessions become decisions. The design challenge now is an interface that assembles itself around the decision at hand.
A living surface shows you what the agent considered, where it was uncertain, and what specifically requires your judgment. It adapts based on who you are, what the agent is trying to do, and what the agent knows versus what it doesn't.
If the agent is confident about 95% of a workflow and uncertain about one parameter, you should see that one parameter front and center, not a full audit of every step.
This matters even more when multiple agents are involved. Every handoff between agents loses context. The living surface's job is partly to reconstruct what got lost in the chain so the human isn't making a judgment call with half the picture.
Most software today still serves the same pre-built screen to every user regardless of context. Even modern CMSes mostly fetch pre-created pages. But decision interfaces for agents can't work that way. The approval screen shouldn't exist in a fixed form. It should materialize around the specific decision, with the specific context, at the specific moment, assembled from components the way a CMS should build a page but rarely does.
Products that surface raw data and ask the human to figure it out are forcing their users to do the hardest cognitive work with the least support. More on living surfaces in practice in a follow-up.
3. Build for infrequent, high-stakes use
When a human only touches the product for the 2% that requires judgment, that surface has to load fast, show context instantly, and make the decision obvious.
Bad GUIs get forgiven when you use them 50 times a day. You build tolerance, muscle memory, workarounds. At twice a week, every friction point is a failure. The entire experience has to be optimized for someone who hasn't been here since Tuesday and needs to make a good call in under two minutes.
This inverts most of what product leaders have been trained to optimize for. Engagement metrics, daily active usage, session duration, time in app: if you're still running quarterly reviews against these numbers, you're measuring the wrong thing. Your best outcome is a human who made a confident decision quickly and left.
The metrics that actually matter look different:
- Decision latency time from escalation to resolution. Are humans getting faster as the agent improves its context presentation?
- Override rate how often humans change the agent's recommendation, tracked over time. A falling rate means the agent is learning; a flat one means it isn't.
- Escalation precision of the items the agent flags for review, what percentage genuinely needed a human? If it's escalating everything, it's a notification system pretending to be an agent.
All three are measurable from event logs you're already generating. Session duration tells you nothing.
4. Close the loop between agent behavior and human judgment
This is where most products fall short. They build the agent path and the human path as separate experiences. They shouldn't be.
No one starts by trusting an agent. Trust is earned, and the fastest way to earn it is explainability. When an agent shows its reasoning, not just its conclusion, humans can evaluate the process, not just the output. That matters because agents don't fail loudly. They produce plausible nonsense. The dangerous failure mode is an agent that assembles something that looks right, reads right, and is quietly wrong. Without visible reasoning, nobody catches it.
Make explainability a product requirement, not a debugging afterthought. When an agent must explain its reasoning as a condition of taking action, that explanation becomes the human's decision-support layer. The agent's reasoning trail is the human's context. Over time, consistent explanations that match outcomes build the trust that lets humans move faster. They stop re-deriving every answer and start spot-checking instead. That's the transition from supervision to collaboration.
The feedback loop runs both directions. When humans override agent recommendations, that signal should improve the agent's future behavior. When humans approve quickly without hesitation, that pattern should inform where the agent can eventually act autonomously. The approval surface is a training interface for the entire system.
Instrument every decision. Mine the patterns. Over time, the system learns which decisions the human always agrees with (candidates for full automation) and which ones consistently require human nuance (candidates for richer context in the approval surface).
5. Design for progressive trust
The biggest mistake I see is treating agent permissions as binary: either the agent can do something or it can't.
In practice, trust develops gradually. Think about how you'd onboard a new hire: you wouldn't give them full production access on day one. The right model is a permission ladder with four levels:
Each rung requires a different product surface. Read-only needs good summarization. Write-with-approval needs the living surface described above. Guardrailed execution needs strategic override controls and anomaly detection. Full orchestration needs closed-loop monitoring and pattern mining across decision traces. Most products only design for one rung.
The permission ladder also creates your competitive moat. Every decision trace builds organizational context. Every approval teaches the system something about how this specific company operates. The longer the system runs inside an organization, the more it understands the texture of how decisions actually get made there. Switching costs rise with every rung climbed.
What I'm not covering
I'm deliberately leaving a lot out: pricing shifts from seats to consumption, the observability layer underneath all of this, workforce reorganization as agents absorb the coordination layer, the compiled knowledge problem. Each deserves its own treatment. This piece is scoped to the experience layer because that's where I see the widest gap between what's needed and what's being built.
The gap is a product problem
The infrastructure layer is moving fast. The agent harness pattern is converging. Models are improving on a quarterly curve.
The products people use to oversee all of this are barely moving at all.
That's the agent experience gap. It's a product design problem that requires a different kind of thinking than the one the industry spent 15 years refining. The interfaces that matter most will be used twice a week, assembled around decisions, earning trust from every human override. The approval screen becomes the highest-value surface in the entire product.
The companies that close this gap will build something durable. Everyone else will ship impressive agent infrastructure that humans can't effectively supervise.
I know which failure mode I'd rather avoid.
Sources and further reading:
- Teddy Riker (Ramp), designing software for agent consumption (April 2026)
- Cat Wu (Anthropic), product team shipping principles (April 2026)
- Shreyas Doshi, product sense as durable career moat (March 2026)
- Jaya Gupta, context graphs and the two-layer enterprise moat (April 2026)
- Aaron Levie, enterprise CIO field notes on headless mandates (April 2026)
- Akshay Pachaar, inverted harness architecture and mediator patterns (April 2026)