The Dot Interface

Another article, or rather essay, I drafted eons ago but never published.

I want to tell you about a morning that doesn’t exist yet, but almost could.

You wake up. Not to a notification. Not to a lock screen competing for your attention before your eyes adjust. You wake up, and the thing on your nightstand is dark except for a small white dot.

You glance at it. A short briefing surfaces, not everything that happened overnight, just the things that matter to you. The contract you were waiting for came back with two changes flagged. Your 9 AM got moved because the other side had a conflict, your morning rules allow reschedules under an hour without asking, so the system proposed 9:45 and both calendars accepted. The reimbursement form you were waiting for is filled out because your last receipts came in overnight. It’s waiting for you to confirm the total. A package was shipped.

You approve the contract changes with a word. You confirm the reimbursement with a glance. You didn’t open anything. You didn’t choose a tool. You didn’t navigate. You just handled your morning. And then the dot went quiet again.

That morning ran on a single white dot.

The dot is not a logo. Not a chatbot face. Not a gimmick. It is the smallest possible promise a computer can make: I’m here when you need me. It’s an interface that refuses to compete for your attention, not out of politeness, but because there’s nothing to compete for. It only exists in the moment you need it. It’s the point where software stops being a place you go and becomes something that meets you where you are.

But the dot only makes sense if we change what software is. So that’s what this article is: an escalation ladder from the world we have now, with apps, stores, subscriptions, menus, toward a world where the default interface can shrink to a dot because the system behind it can reliably convert intent into outcomes. I think this is where software is going.

Design the dot before you earn it

Black screen with a dot? So… a chat UI? If that’s what you heard, good. That’s the trap. Chat is a transitional skin, not the endpoint!

The dot interface is a stable loop that the user learns once and then stops thinking about. You state what you want. The system proposes what it will do. You approve the consequences. It is executed. It shows you what has changed. That’s the loop.

The loop matters because it separates the thing people keep confusing. People describe the agent future as if it’s mainly a better way to ask, better prompting, better voice, better natural language. I do not believe that’s not the hard part. I think the hard part is making “asking” connect to “doing” without the system surprising you with consequences you didn’t approve of.

The dot isn’t there to accept your poetry. It’s there to stage an outcome request into a controlled action pipeline.

And the dot becomes more compelling as the system becomes more capable. With weak systems, you need rich interfaces because you’re compensating for capability gaps. With strong systems, you need interfaces for exactly two reasons: to clarify intent and to verify consequences. Everything else is navigation friction we’ve accepted because computers used to demand it.

The dot interface isn’t minimal because minimalism is cool. It’s minimal because in an “outcomes first” world, the menu is no longer the center of gravity. The plan and the approval are.

Replace “choosing tools” with “requesting outcomes”

The shift I’m predicting is not “software becomes AI.” It’s “software becomes on-demand.” AI is the catalyst, but the change is deeper: the unit of value stops being the app you picked and becomes the outcome you requested.

The app era trained us to think like this: Which tool should I use? Even when we pretend we’re outcome-driven, we still translate outcomes into tool selection. That translation is a learned skill. It’s why experts look like magicians and beginners look lost. Experts don’t just know what they want, they also know which tool shape produces it.

The agent era will flip the default question: What do you want to happen? Not “what app,” not “what menu,” not “what workflow,” but “what changed state would satisfy you?”

This might sound like semantics until you watch what it does to everything around it.

When you choose an app, you accept its implementation. Its constraints, its UI decisions, its integration limits, its “this is how we do it here.” You also accept its business model, because those things are welded together now. The app is not just a capability, it’s a surface that wants to keep you inside it. You adapt to it.

When you request an outcome, you’re not committing to a surface. You’re committing to a result. And that changes what software companies compete on, because the surface becomes less defensible than the capability behind it.

This is why I keep coming back to a specific framing: apps don’t disappear; they stop being destinations. They become substrates. The durable thing is the API, the data model, the compliance boundary, and the reliability guarantees. The agent becomes the surface that routes you into those substrates.

If you want a quick way to detect whether you’re thinking in the old era or the new era, listen to your own internal monologue.

Old era: “Where is that setting again?” New era: “Make it like last time, but for this thing.”

Old era: “Which tool exports this format?” New era: “Turn this into something I can use in the report.”

Old era: “I need an app for that.” New era: “Handle that.”

That last one is the most important. The emotional center of gravity shifts from “I need to learn a tool” to “I need to delegate an outcome.” And delegation forces us to confront the boring adult topics the hype skips: permissions, auditability, rollbacks, verification, and security.

We have heard this before

This is probably where someone reasonably says: we’ve heard this promise. Siri was supposed to be outcome-first computing. Hey Google, Alexa, and every smart assistant since 2011, each one promised at a world where you say what you want and the machine handles the rest. Each one stalled. Honestly, I feel they even got worse.

But the failure mode was specific, and it matters. Those systems could handle one intent routed to one capability. “Set a timer.” “Play this song.” “What’s the weather?” “How tall was a Tyrannosaurus Rex?”. “Who would win in a fight between between one Tyrannosaurs Rex and 10 gorillas?” (if you have kids you know, and they fail miserably on that last one). They couldn’t compose across arbitrary systems. They couldn’t verify their own outputs. They couldn’t recover gracefully from ambiguity or partial failure. And the cost of each interaction was high enough that the economics only worked for simple, pre-wired commands.

What’s different now isn’t the vision. The vision is decades old. What’s different is that general-purpose tool use, cost-per-interaction, and structured verification, with constraints, typed outputs, audit trails and reversibility, are all moving at once. Backed by infrastructure investment at a scale we usually only see during platform shifts. We’re not iterating on the smart speaker. We’re building something whose failure modes are different in kind, not just degree.

But I want to be precise about what “different in kind” means, because the previous generation of hype failed on specifics too. Current agents can use tools across multiple systems, but they seem to reliability degrade with each hop. They can verify structured outputs, but they struggle with ambiguous success criteria. They can recover from some errors, but their failure modes are often silent rather than loud. The gap between “demo” and “I’d trust this with my Monday morning” is still real. The companies that close that gap through engineering discipline, not just model scale, are the ones that will matter.

The idea might not be new. But the engineering conditions are.

Escalate on-demand software up the stack

Here’s my escalation ladder. It’s not based on “what’s coolest.” It’s based on what flips first when capabilities improve and costs drop.

The first wave is niche tools. The second wave is workflow glue. The third wave is system composition. The dot becomes real when those waves stack on each other.

Start with the niche tool that never should have been an app

The internet is full of tiny tools that exist because a human had a tiny outcome and paid the “discovery tax.” Convert this file, rename that batch, extract these frames, summarize that document, transform a dataset, clean up a list, generate a report template, splice a video clip, create a small diagram.

Most of these are not products. They’re outcomes with a thin wrapper.

Agents eat this layer first because the economics are unfair. Building and maintaining a full app surface for a narrow outcome is expensive. Generating a small, disposable tool for a narrow outcome is cheap.

Verification is also cheap here. If the agent converts the file wrong, you see it immediately. If it formats the text wrong, you correct it. The cost of failure is annoyance, not catastrophe. That’s where on-demand software thrives: low-stakes, high-frequency friction.

This is also where the behavior change starts quietly. People stop searching app stores for niche utilities because asking the dot is faster. Not because the dot is magical, but because the dot can generate the wrapper you needed without you adopting a new UI religion. And once that happens, something subtle dies: the interface itself stops being a selling point. Nobody compares designs. Nobody writes reviews about the layout. The tool becomes invisible in the way that a good door handle is invisible, you just use it and then move on. The outcome was the only thing that ever mattered; we just used to have so much friction that we mistook the friction for the product.

Move into the workflow glue that humans should not be doing

Then it escalates into the part of modern work that burns time and soul: glue.

Every Monday, an ops team, somewhere in the world, opens four project boards, reads through last week’s status updates, copies the key decisions into a slide template, cross-references them against the budget tracker to flag anything over plan, writes a summary email to leadership, CC’s the project leads with individual follow-up items, and schedules three check-ins based on what’s slipping. That’s two hours. It requires zero judgment. It requires only the ability to traverse tools, transform formats, and follow a repeatable pattern. It is, in the purest sense, glue.

Glue work is the connective tissue between tools. It’s pulling information from one place, shaping it, pushing it into another, notifying someone, waiting, repeating. Everyone knows it’s not where human judgment should go. Everyone does it anyway, because “this is how we operate.”

This layer flips when agents can use tools reliably. Not “write a nice email,” but “read the latest update, extract the decision points, update the ticket, send the recap, schedule the follow-up, and attach the context.”

The experience change here is subtle but profound. The job stops being “operate the workflow” and becomes “supervise the workflow.” You stop living inside menus because the system can traverse menus. Your job becomes defining what “done” means and confirming that it happened correctly. In that Monday morning workflow, the human’s job isn’t to copy numbers between systems. It’s to decide what the budget overrun actually means and what to do about it.

And now the dot begins to make sense as a default entrypoint, because if the system can orchestrate multiple tools, the last thing you want is to bounce between them manually just to keep the glue moving.

Climb into system composition

This is the step that scares incumbents. It’s also the step people will overhype and deliver wrong.

I don’t think agents instantly replace big systems. I think agents route around their surfaces.

Big software today survives partly because it’s hard to compose across systems. Integrations exist, but they’re brittle, permissioned, slow to change, and expensive to maintain. The UI becomes the practical place where humans do the “last mile” work of connecting things that don’t natively connect.

But if the agent can reliably compose capabilities, pull from system A, reconcile with system B, apply policy, write back, and log everything, then the UI stops being the place where value is realized.

Forget about that ops team! Right now, somewhere, a procurement manager has seventeen tabs open, again, because she’s matching a vendor’s invoice against a purchase order in one system, a delivery confirmation in another, and a budget approval in a third and when the numbers don’t match, yet again, she emails someone to ask why, then sets a reminder to follow up. That entire afternoon is composition work trapped inside manual glue. The agent doesn’t need to be smarter than her. It just needs to hold context across systems without dropping it.

The UI becomes a specialized surface you visit for deep inspection, debugging, or high-stakes editing.

And here’s the thing that’s hard to see from inside the app era: most of what we call “UI” starts to feel like an implementation detail. Menus, settings panels, navigation hierarchies, they become what machine code is to a modern developer. Still there in some way. Still running underneath. But no longer something a normal person touches, or even thinks about. You don’t care how the zeros and ones are arranged on disk. Soon you won’t care which screen the agent navigated to get your result.

That’s the composition step. It’s not that apps vanish. It’s that you stop living in them. You live in outcomes. And the interface can finally shrink to match.

The craft that becomes the substrate

There’s a reasonable objection here, and I want to take it seriously before moving on.

Choosing tools isn’t just friction. For many people, it’s a form of literacy, perhaps even identity. The person who knows Photoshop cold, the spreadsheet wiz who can make Excel do things its designers never imagined, the developer who chose vim not because it was efficient but because it reflects how they want to think. That mastery is real. It’s satisfying. It’s a kind of craft. And saying “the agent will handle it” can feel like saying “your expertise doesn’t matter.”

But history has a clear pattern here, and it’s worth sitting with.

Switchboard operators managed complex, real-time routing of human communication: automatic switching didn’t make their skill worthless, it made their skill no longer the bottleneck. Linotype operators were artisans of text: desktop publishing didn’t erase beautiful typesetting, it erased the requirement that every printed page pass through a specialist’s hands. Photo lab technicians understood chemistry, timing, light: digital photography didn’t prove them wrong, it just made the transaction cost of a photograph so low that the average person no longer needed to understand development to get an image.

The pattern is consistent: the craft survives, but the mandatory apprenticeship doesn’t. We absorbed those transitions because the cost of access dropped and the people who genuinely loved the craft kept practicing it, as a specialty, a choice, a form of art rather than a requirement. Or, maybe not the switchboard operators.

The same thing will happen with tool selection. The Photoshop expert won’t vanish. But “learn Photoshop” will stop being the default answer for someone who just needs an image edited, the same way “learn darkroom technique” stopped being the default answer for someone who just wanted a photograph.

That’s not a tragedy. It’s a transition we’ve made dozens of times. It’s just that this time, the craft being absorbed is the meta-craft, the skill of knowing which software to use and how to navigate it. That’s what makes it feel different. It’s not one tool being replaced. It’s the act of tool selection itself becoming optional.

And that’s also what makes the scale different. When automatic switching replaced switchboard operators, it was one occupation. When desktop publishing replaced typesetters, it was one industry. But the meta-craft of “knowing how to operate software” cuts across nearly every profession in the service economy. Receptionists, analysts, coordinators, brokers, administrators, a significant part of what these roles do, day to day, is navigating software on behalf of outcomes. When the navigation layer compresses, it doesn’t affect one sector. It sends a tremor through the entire tertiary economy simultaneously. That’s not the same historical pattern playing out again. That’s the pattern operating at a scale we haven’t seen before.

If that’s unsettling, it should be, and more than a little. Something real is lost when a form of literacy becomes unnecessary. But something real is gained when a billion people who never had time to become experts can suddenly get the outcomes that used to require expertise.

Wear the interface after you shrink the contract

Once the dot loop is mature, the interface naturally wants to migrate to whatever surface reduces friction.

Phones are incredible, but they’re interaction-heavy. Unlock, swipe, tap, navigate, back out, switch apps, find settings, hunt for the right entry point. That friction is acceptable when software is a set of destinations. It becomes ridiculous when software is an outcome engine. So the capability stays central, and the surface becomes contextual. Your watch, earbuds, car, wall display, glasses. Each one could be a viewport into the same dot loop, not a separate product category.

Glasses matter here not because “AR is the future” in some generic sense, but because of something specific, they change the cost of verification. The dot loop needs quick moments of confirmation, a mere glance to approve, another to inspect and one to confirm what changed. Glasses make glanceable supervision cheaper than pulling out a phone. The argument for lightweight wearables in an agent world isn’t about immersion. It’s about making the approval step as cheap as looking up.

Voice becomes more useful in this world too, but not because voice is finally perfect. Voice becomes useful because it can trigger an outcome request that results in a plan. The value is not in saying words to a machine. The value is in collapsing the distance between “I want” and “here’s what I’ll do, want me to proceed?” while keeping a human in the approval loop.

The surface will keep evolving. But the surface is not the point. The point is the contract underneath. Get that right, and the dot works on anything with a screen. Or without one.

Pay the taxes that decide whether this becomes normal

If this future doesn’t arrive, it won’t be because the models aren’t clever enough. It’ll be because the taxes are too high. Each of the following is a branch point. If any of them stays too expensive for too long, the dot stalls at whatever layer it reached and the app era extends.

Verification

Generating outputs is cheap. Confirming them is expensive. On-demand software wins fastest where the cost of being wrong is low and the correction loop is tight. It stalls where being wrong is catastrophic or ambiguous.

This is why the niche layer flips first. You see the bad conversion immediately. It’s why glue flips next. The workflow has a known “done” state you can check against. And it’s why regulated domains will lag, not because they’re “behind,” but because their verification requirements are a different species entirely. When the cost of a wrong answer is a compliance violation or a misdiagnosis, “check if it looks right” is not a verification strategy. The system needs structural guarantees, audit trails, and domain-specific validation before anyone will trust it.

Security

A tool-using agent is a supply chain. It consumes inputs from messy environments, like web pages, emails, documents, chats, and turns them into actions. That is exactly the kind of system attackers dream about.

“Trust the model” is not a security posture. The plan has to be structural. Constrained tool access, explicit permissions, allowlists for high-risk actions, sandboxing for execution, audit logs, and a default stance of skepticism about instructions that arrive through untrusted channels. If we don’t engineer this, we won’t get the dot. We’ll get a constant stream of “the agent did something weird” stories, and eventually people will clamp down until it’s a glorified search box.

Latency and cost

The dot loop only becomes a default interface if it feels immediate. If every outcome request requires a slow chain of reasoning, tool calls, and retries, people will retreat to apps because apps are predictable and fast.

This is where inference efficiency matters, and also where hybrid execution matters. Some steps will be local. Some will be cached. Some will be precomputed. Some will run on-device for speed and privacy. The dot doesn’t need every request to be a cloud round-trip. It needs the perception of responsiveness. An engineering problem with known solution shapes, even if the solutions aren’t fully deployed yet.

Incentives. The tax that determines who owns the future

The app economy will not politely dissolve. Gatekeeping will shift, not vanish. And this is the tax that deserves the most attention, because it determines whether the dot future is liberating or captured.

Here’s the structural issue. In the app era, the home screen was distribution. Icon placement, app store ranking, default apps, that’s where power is concentrated. Two companies controlled which icons you saw first, and they extracted enormous value from that position.

In the dot era, distribution is which substrate the agent routes to. If you say “book a flight” and the agent picks one provider over another, that routing decision is worth billions. If you say “edit this image” and the agent chooses which underlying engine to use, that’s market share being allocated by an algorithm you never see.

This means the “agent-friendly API” becomes the new SEO. Vendors will optimize not for human eyeballs but for agent selection. They’ll compete on structured outputs, reliability scores, and integration ease, not because they want to, but because the agent is now the customer-facing surface, and if your substrate isn’t legible to the agent, you don’t exist.

The uncomfortable possibility is that the dot could concentrate power more than the app store did. Apple and Google control app distribution, but at least users consciously choose which apps to install. In a dot world, the agent makes substrate choices that users may never inspect. Three companies running three dots, each with preferred substrates, preferred billing rails, preferred identity layers. That’s not decentralization. That’s a new oligopoly wearing a minimalist interface.

The escape valve is interoperability. If agents can compose across substrates freely, and if the protocol layer is open and substrate selection is transparent, then power disperses. Users can see why the agent chose what it chose. Competing agents can access the same substrates. Substrates compete on quality rather than exclusive deals. If not, we’ve just moved the gatekeeping from the icon grid to the action layer. Same dynamics, thinner interface, less visibility for the user.

If you want to understand the next decade of software economics, watch this: are the major platforms enabling open orchestration, or are they trying to make their agent the only viable surface?

Adoption. And the privacy objection that won’t matter as much as it should

There’s an objection that sounds principled and feels important: people won’t accept this. They won’t hand that much of their life to a system. They won’t let an agent see their calendar, their messages, their finances, their habits. They’ll refuse to be that legible.

I take this objection seriously. I also think history has already answered it.

Someone from the 1970s would be horrified by how we live now. You’re on a mountain peak and your boss can reach you. You’re in a delivery room and a group chat is buzzing. Your location is tracked by default. Your face is in a database. Your purchasing history is a commodity. We know this. We’ve known it for years. And we keep using the apps. Keep uploading the photos. Keep granting the permissions. We consent through behavior, not through principle.

The dot will face the same resistance. Privacy advocates will raise alarms, correctly. Some people will opt out, genuinely. And a single high-profile breach, an agent draining an account, leaking a medical record, acting on a spoofed instruction, could freeze adoption for years. But the long pattern is relentless: when convenience is high enough and the friction of refusal is sharp enough, most people adopt. Not because they don’t value privacy. Because the daily calculus of “this makes my morning easier” beats the abstract calculus of “this makes my data more exposed” almost every time.

That’s not a celebration. It’s a prediction. And it means the real fight isn’t whether people will adopt the dot, it’s whether the systems are built so that adoption doesn’t become exploitation. “Build it right” has to mean something specific: data residency on-device wherever possible, so the agent can reason locally without shipping your life to a cloud. Transparent substrate routing, so you can see why the agent chose a particular service, which connects directly to the incentives problem, because opaque routing is both a privacy risk and a power-concentration risk. Auditable action logs that the user owns, not the platform. These are first-generation design decisions, not features you retrofit later. We’ve already run the experiment of building for convenience first and bolting on privacy after. It’s called the entire history of social media.

But not everything compresses. Some tasks refuse to fit the dot, and not marginal tasks.

A designer in Figma isn’t navigating friction. She’s thinking spatially, dragging, resizing, iterating through visual possibilities in a way that requires a canvas. A developer debugging a distributed system needs a console, a log viewer, a trace visualizer, and a terminal running simultaneously. A data analyst exploring a dataset needs a grid, interactive charts, the ability to ask “what if” and see the answer reshape in front of her. These aren’t edge cases. For many professionals, this kind of deep-surface work is the job.

So the realistic endpoint is not “screens disappear.” It’s that the dot becomes the default entrypoint, and rich surfaces get fluidly summoned when the task demands them, with context already loaded. You don’t hunt for the right tool, navigate to the right screen, and re-establish where you left off. The dot handles the routing. You arrive in the deep surface already oriented, and when you’re done, you return to the dot.

The honest framing: the dot doesn’t replace the cockpit. It replaces everything you do between takeoff and landing. That’s still a massive shift.

Where I place the bet

My bet is that we will gradually stop “choosing apps” the way we stopped choosing libraries when platforms matured. We won’t throw away apps overnight. We’ll just interact with them differently. Less through their surfaces. More through their capabilities.

The escalation feels almost inevitable to me once you accept the first step: niche outcomes become summonable. From there, the second step follows because glue work is the next obvious target. From there, composition follows because once glue is cheap, monolith surfaces lose their grip. And once composition is reliable, the interface can shrink because navigation stops being the dominant activity.

Then the dot starts to look like the correct design. Not because it’s futuristic. Because it’s what’s left when you remove all the UI that existed mainly to compensate for the fact that computers used to require you to drive them.

In that future, the most important interface isn’t the home screen. It’s the contract. The permission model. The audit trail. The ability to propose before executing. The ability to roll back. The ability to say, with confidence, “this is what will happen if you approve.”

Build that contract, and the dot is the most boring thing you can ship.

And boring is usually the shape of the future, right before it becomes normal.