The UI is not the product

Fin AI Design Lead Molly Mahar said the work behind the company's Topics Explorer feature was largely building the context and data layer underneath, and that "the UI was the best way to surface it at the time," as agent-driven software increasingly replaces traditional interface surfaces at Fin. The company's internal agent Operator, a chat-based interface that configures and runs Fin, now performs tasks such as detecting needed content changes and rendering bespoke UI on demand, work previously handled by crafted screens like Topics Explorer. Fin argues that adding an AI assistant to an existing product is not the needed change, because agents remove entire categories of problems those products were built to solve and return completed tasks rather than recommendations.

A lot of design industry discussion recently has focused on what judgment, taste, and quality mean when building software is cheap and execution is no longer the constraint. That conversation is worth having, but I think it’s missing something important. It’s not just how we build products that’s changing, the products themselves are changing too. Agents are in the process of reshaping entire UI surfaces, including the configuration layer that underpins Fin https://fin.ai/ . Traditional software exposed the system through UI so people could operate it themselves. Agent-driven software increasingly operates that system on their behalf. That’s an entirely different design problem. The thing we built, and what’s happening to it Most of the UI we created as product designers existed to help someone do something: navigate to information, notice a flag that needs attention, or take action on a task. I may be biased, but I think our team at Fin is very good at this. We have built industry-leading tools that make complex systems legible and easy to act on. One example is Topics Explorer. It surfaces emerging themes from customer conversations so teams can keep their help center content up to date, which improves AI performance. It tells you what’s changing, why it matters, and gives you the tools to act on it. It’s beautifully crafted, but UI features like this are increasingly taking a back seat to Agent conversations. Topics Explorer https://academy.fin.ai/topics-explorer : an example of UI that agents are replacing Now Agents can do the job this feature was helping users do. You simply tell it what you want, it pulls the data, makes the connections, comes back with a proposal, and asks if you want to approve it. The carefully considered interface in the middle is no longer needed. Increasingly, you don’t even have to ask. Agents can detect when a content change is needed, and the first you might hear about it is when you see a content-change proposal waiting for your review. An Agent can do this because the groundwork has already been laid: someone decided what data matters, and how to glean meaningful signal and action from it. Designing the screen is how we worked a lot of that out. As Molly Mahar, AI Design Lead for this feature, puts it: “Much of the work on Topics Explorer was building the context and data layer underneath: the definitions and relationships between different metrics. The UI was the best way to surface it at the time.” But that same logic is now being used by Agents to complete the same and similar tasks. These products are a different shape There’s a version of adding AI that many teams default to: keep the existing product and bolt on an AI assistant. It feels like progress, and it probably helps to some degree, but it’s not the change that’s needed. AI doesn’t just speed up existing products, it removes entire categories of problems those products were built to solve. It’s not there to help you navigate a dashboard; it distills the dashboard into its most important and actionable insights and takes action based on those insights. So the output isn’t just a recommendation, it’s a completed task. That’s an entirely new way of addressing users’ underlying needs. Operator https://fin.ai/operator , our internal Agent that helps teams configure and run Fin, is a clear example of this. It’s a simple chat-based interface that understands your context and data. It can help you fix a problem you’ve identified or make improvement suggestions unprompted. It even renders bespoke UI on demand; whatever the task or the person needs at that moment, assembled there and then. It’s generative, tailored, and highly contextual. There’s a second-order effect that also matters. Traditional UI is reliant on pages, controls, and states. An Agent, like Operator, can abstract a lot of the complexity away, revealing only what matters for specific tasks. This allows users to deal with a greater level of complexity than would have been possible with UI tools alone. This also makes it a great way to learn about capabilities, where the complexity can be progressively revealed over time. For these reasons, Operator is in the process of taking over a lot of the jobs our UI used to do, and I think that’s a good thing. It’s important to lean into this change, as the alternative is waiting for someone else to do it. Operator http://fin.ai/operator finds the data, proposes the change, and renders whatever UI is needed. The question every product team must face Think about how much of a product exists to help users navigate to something. Then ask what happens when an Agent can just do that thing. The dashboard that existed to help users understand their data and what to act on is no longer needed. Some teams will preserve existing features and retrofit AI onto existing structures. That might work in the short term, but competitors will come along with a different, more disruptive solution. The surface we author will get thinner, but the end-user experience will be richer. One question might pull from multiple sources, collapsing what used to be three separate tasks into one answer. For designers, this changes the work. My previous article https://ideas.fin.ai/p/how-we-design-when-the-code-writes argued that design’s value concentrates at the edges of the product development process. That’s still true, but it’s not the whole picture. As Agents absorb more of the interface, what’s left to design gets smaller and more consequential. Fewer screens, each carrying more weight. The way you get those right is by deeply understanding the system underneath, because that’s what now drives the experience. Discoverability becomes a different challenge too. UI surfaces are an effective way to showcase new capabilities, but when they are now just part of the underlying agentic system, how are users meant to find them? Striking this balance of the accessibility of a minimal chat-based UI while performing the myriad of jobs needed is a difficult design challenge. That means being critical about which UI actually serves user needs, but designers are trained for exactly this. When execution is cheap, the people who can tell what needs to exist, and make it feel intentional when it does, are the ones who will shape what comes next. What still needs designing Not everything will go away. Some surfaces matter more than they used to. Take approval interfaces – the moments where someone has to understand what an Agent did and decide whether to trust it. As Agents take on more, these surfaces will become crucial. Get them wrong and people lose trust in the product, which ultimately means they stop using it. But these are often harder to design than the screens they replace. An approval interface has to show what changed, why the Agent thought it was right, what it was working from, and what happens if you say no. This requires a deep understanding of the product. Human-in-the-loop configuration for Fin There’s also the issue of when an Agent assembles a view on the fly. Nobody draws those screens one at a time anymore. Instead, we design the rules that produce them: what can appear, in what order, and what it should never do. Systems become the product If designers are building less UI, where does their focus land? Part of the answer is deciding what we should build in the first place. The other part is shaping the systems underneath. Not just the design systems, but also the rules and guidance that determine what Agents do, and how they behave. Fin depends on things nobody sees: the information it pulls from, the data model that defines the concepts and relationships, evals https://ideas.fin.ai/p/why-not-just-ship-it that define how we measure whether its answers are good, and the guardrails that set the boundaries of what it can do. As internal Agents, like Operator, become more common, design decisions move into defining their behavior and the systems they run on. These decisions are what determine the experience. I don’t mean we all need to become technical AI practitioners, but we do need to consider how Agent behaviour shows up for users: what it says, when it’s thinking, when it stops, what it does when it isn’t sure, and when it refuses. That’s content and interaction design as much as AI/ML work. Further down sits the machinery: what the Agent retrieves and how we measure whether an answer was good. Most designers won’t author those, but we do need to understand this layer. In the same way that we don’t need to become back-end software engineers to build great software, it helps to understand the structure and boundaries of these AI systems. This means knowing enough about the system to make good calls about the parts you do control. It’s also worth saying that our team is further along on this journey than most. We are building Agents, with a 50-person in-house AI team. While some of what I’ve described might not be familiar yet, I think the trajectory is clear regardless. The specifics of how fast this arrives will depend on your product and your company. Even Operator is a stepping stone Dedicated UIs won’t vanish overnight, of course. Some tasks will always need a dedicated surface to give people real control and context. But there will be less waiting for people to come to the tool, and more of the tool meeting people where they already are. Operator is one answer, for now. It’s still primarily a place users go to. The direction is clear though: this kind of functionality will start to surface wherever users already are. That could be a Slack thread, a Linear ticket, or a GitHub PR. It will get more autonomous too, as the system gets more reliable and people’s confidence grows. That should ultimately be a better experience for users. The job gets done wherever they happen to be, with less friction attached. What the work is still for Design craft hasn’t disappeared with these changes, but it has evolved. As Agents take on more of the execution and product surfaces contract, the care and attention to detail that used to go into outputs goes into the underlying systems, standards, and Agents themselves. What won’t change, however, is what the work is for: understanding the people using our product and what they are trying to do; deciding which problems are worth solving; and knowing if our solutions are good enough.