The Interface Was the Meter

Each shift in how work gets counted changes who benefits from it. When room-sized computers arrived at NASA in the 1950s, they accelerated calculation and, less obviously, changed which calculations were visible, and to whom. The women who'd been doing that work by hand, carrying the title "human computer" as a job description, had built careers inside a surface that was about to be replaced. Some were retained. Many weren't. The work didn't disappear, but the surface it ran on changed.

Every new tool that makes labor visible eventually does something similar, but at a different scale and speed. Every counting surface creates its winners and its ghosts. The person whose work leaves a trail their employer can see and price occupies a different position than the person whose value is judgment, context, or relationships that don't transfer cleanly to some record. The SaaS era turned navigating a system into that kind of visible, transferable labor.

The early read on AI agents is that they put the most pressure on roles closest to the interfaces: the people whose expertise was in a specific sequence, clicking through the right screens in the right order, translating between systems that didn't talk to each other. That work looks the most exposed, not because it wasn't real or hard, but because it was visible in exactly the way agents can replicate.

The NASA shift took years. This one may not.

The word "interface" carries an assumption easy to miss: an implied middle layer, a place where two things meet. In the software context, one of them is a person with a name attached to the audit trail. Someone decides what to do. The software helps. And someone can be called into a room if it goes wrong.

The implied person is becoming optional. The word hasn't changed, but the assumption underneath it definitely has. When an agent navigates a system, there's still an interface in the technical sense, but no one is really interfacing. The surface exists. The person who was supposed to stand at it has stepped back.

It's the kind of language drift that happens before anyone officially updates the vocabulary.

Even in software, "apply" still feels physical. You bring effort into contact with something and expect it to leave a mark.

The first software I used that felt genuinely native to how I thought was Gmail. At some point it stopped feeling like a tool and started feeling like a place. I had opinions about threading. I had a labeling system that made sense to no one but me. The software worked because I was inside it, arranging things.

If the primary operator becomes another system, the software still exists, but it stops functioning as a place. It becomes a surface other systems query and update. The interface may remain for humans to inspect or override, but it's no longer where most of the work actually happens.

The word "application" survives that shift, but the metaphor underneath it starts to wobble.

But not every intermediate step can be skipped. In regulated industries, the screen isn't just a surface for convenience. It's the legally required moment where a human witness is inserted before a consequential decision is finalized. The interface, in those contexts, is a liability structure as much as a product.

There's a reason it takes a human three days to deny your insurance claim when a system could do it in three seconds. The delay is the product.

If an AI agent denies a health insurance claim via an API call and that denial is contested, "the system returned a successful response" is probably not a great legal defense. Regulators frequently require demonstrable human review before a decision takes effect. The screen is where that seeing happens, officially and on the record.

That requirement doesn't bend easily to architectural preference, but it does bend, usually after something breaks badly enough to force a legislative response. So the pace of headless adoption is likely uneven across industries in ways that don't map cleanly to technical readiness. The companies most confident about the shift may be the ones operating furthest from where that wall currently stands.

Supervision assumes you know what you're looking for. That's reasonable when the work is familiar and the ways it can fail are well understood. It gets less stable when the system assembling the answer is doing things you can't fully trace.

The task stops being reviewing work you understand and checking it for errors. It becomes reviewing an output you didn't produce, for errors you might not recognize. At that point "supervision" starts to look a lot like trust, though the vocabulary hasn't caught up yet.

Trust meaning: close enough, so far.

Shaw and Nave's Wharton experiments measured this at the level of individual reasoning tasks. When people could optionally consult AI, they did so on a majority of trials and adopted its answers with minimal scrutiny, even when the AI was deliberately wrong. The detail that sticks is the confidence: participants didn't just defer, they felt more certain afterward. The paper calls this "cognitive surrender," and distinguishes it from strategic offloading. Offloading is delegation with evaluation. Surrender is reasoning that's been vacated without the person noticing it left.

In practice, the responses probably sort into at least three groups: people who evaluate and override, people who surrender without realizing it, and people who know the output is probably fine and would rather clock off. The third group isn't surrendering in the cognitive science sense. They've made a calculation that the verification step costs more than it's worth, and they might be right. But nothing in the audit trail can tell the difference between someone who checked and someone who decided not to, which means the organizational assumption that a human is in the loop starts to describe a job title rather than an activity.

Early LLM discussions focused on whether the output sounded intelligent or human. That question mattered when the model was functioning as a surface for conversation.

Nobody talks about that anymore. What matters now is whether the system underneath the response can reliably operate across other systems: calling APIs, retrieving structured data, triggering workflows, assembling results without a human navigating each step. The question shifted from "does it sound smart?" to "does it work at 2am with no one watching?"

That's the shift that demotes the screen.

If the interface stops being the primary meter of work, a lot of adjacent systems start measuring the wrong thing. Compensation plans tied to seat expansion. Product roadmaps optimized for feature discoverability. Customer success playbooks built around increasing login frequency.

Those structures don't disappear just because agents abstract the interface. They continue operating, rewarding the behaviors they were designed to reward. If the locus of value shifts underneath them, they begin optimizing for a surface that no longer carries the weight it once did.

Microsoft's response to this pressure has been to charge more. Their new enterprise tier costs roughly twice the previous top offering, on the theory that AI makes those seats more valuable rather than fewer. It's a reasonable bet and also exactly what you'd do if you needed the meter to keep running while you figured out whether the meter still made sense.

Intercom chose the opposite direction. They rebuilt around Fin, their AI support agent, and gave up something like $60M in existing product revenue to make room (as described by Eoghan McCabe). Most companies in that position would have hedged, protected the existing line, and called it strategy. Intercom didn't. Customer support has an advantage most SaaS categories don't: the unit of value is clear, a ticket is either resolved or it isn't, and the category had already been under automation pressure for years. Whether the conditions that made it possible exist in other categories is an open question. The unit of value in most enterprise software is harder to isolate, which makes the same bet harder to underwrite.

Two companies, same structural pressure, opposite responses. Organizations rarely notice when their meters stop measuring what matters.

The people who hold systems together rarely describe themselves that way. They say things like "I just know where things are" or "someone has to remember" or, my favorite, "yeah, don't touch that field." The knowledge isn't dramatic. It's procedural, accumulated, and mostly invisible until the person who held it leaves and three things break on the same Thursday.

Agents surface this faster than any onboarding or handoff ever did. When a system tries to automate a workflow and discovers that step three depends on a manual correction no one documented, that's the organization learning what it actually runs on. The cost was always there, but it was just being absorbed by someone who never got around to writing it down.

Whether that surfacing leads to better architecture or just more expensive failure depends on whether anyone is paying attention when it happens. Most organizations have a narrow window between "the agent hit an error" and "someone routed around the error and forgot about it."

Architectural costs behave differently from human ones. A team being retrained complains immediately. A brittle API doesn't. An inconsistent schema doesn't escalate to a manager.

The failure mode is usually quiet: months of small workarounds, duplicated transformations, integrations that hold on just long enough to pass a demo. The system appears stable until someone tries to automate across it and discovers how much coordination was previously being done by people.

Architectural failure is hard to name in advance. You find out what it looks like when someone tries to automate across the seams and they don't hold.

Companies that successfully made infrastructure transitions didn't start by becoming invisible. They kept the identity-facing layer long enough to pay for what was happening underneath.

Amazon is the obvious case. AWS began as internal infrastructure, built to support the retail business. The external product came later. What looks like a clean shift in hindsight was subsidized for years by something much easier to see.

Something similar is starting to show up in how agent systems actually work. The model gets most of the attention, but the useful behavior sits elsewhere: in the layer that decides what to call, what context to carry forward, how to keep a thread of execution intact. Improvements there explain more of the recent step-changes than the model itself (a reasonable overview here).

That leaves an awkward question for companies built around the interface. If the visible layer stops being where the value accumulates, it's not obvious that removing it is the right move. What matters is whether the system underneath can stand on its own when the screen recedes.

There's a version of this where the screen doesn't recede at all. It multiplies. An LLM generates a one-off interface shaped to a specific question, pulling from the same APIs and data layers the pre-built UI sat on top of. The vendor's screen was always a compromise designed for the median user. When the presentation layer can be generated on demand, the compromise becomes optional.

That looks like a different future, but it's the same structural shift seen from the user's side. The systems underneath can't know or control the final form by which they'll be presented. Whether the consumer is an agent running a workflow with no screen at all or an LLM assembling a temporary interface for a specific person, the infrastructure is headless either way. The vendor just lost the surface, not the system.

The interface is still generating enough revenue at most companies to make this question feel optional. That likely won't last.

This is where the counting surface argument meets the labor question from the beginning.

The interface made certain kinds of work visible, and visibility was what made that work countable, and countability was what made it compensable. The person who could navigate Salesforce, reconcile data across three systems, and surface a clean report had built a career on a specific counting surface.

Agents don't eliminate that work. They replicate the visibility of it. The sequence, the clicks, the movement through systems: those were always the observable part, the part that showed up in utilization metrics and justified the headcount. The judgment underneath was harder to see and harder to price.

When the visible layer gets automated, the question isn't whether the person was doing real work. They were. The question is whether the part of the work that survives is the part anyone was paying for.

I've watched this happen in operations roles. Someone spends years learning which reports to cross-reference, which fields to distrust, which numbers to sanity-check before they go to leadership. An agent can now pull the same report in seconds. What it can't do, yet, is notice that the number feels wrong given what happened last quarter, or that the data is technically accurate but misleading in context. That judgment was always there. It just never had its own line item. It rode in on the clicks.

If anything stabilizes, it's probably work that understands systems well enough to know when they're lying. Whether that's a role or just a temporary edge is unclear. The pace of improvement keeps outrunning the analysis.

The pressure described in this essay falls unevenly across software categories, and the split reveals something about what these tools actually are. A CRM records what happened. A support platform routes requests. An ERP tracks transactions. These are metering surfaces: they make activity visible, and the value proposition is that visibility. When an agent can generate the same visibility without a human clicking through the interface, the seat loses its justification. The meter still runs, but no one needs to stand at it.

Production tools behave differently. Figma, a code editor, an audio or video editing suite: these don't meter work. They produce it. The output is the artifact itself, shaped by decisions the tool helped execute. A designer in Figma isn't generating evidence that design happened. They're designing. The value is in the thing that gets made, and the interface is where the making takes place.

That distinction matters because AI enters these two categories with opposite effects. In a metering tool, AI substitutes for the person at the interface. The system can route, record, and reconcile without someone navigating it. The human in the loop becomes optional, and the seat-based model starts to buckle under the weight of that optionality.

In a production tool, AI is additive. It accelerates what the person is already doing. More iterations, faster prototyping, broader exploration of a design space. The person doesn't step back from the interface. They go deeper into it, because the tool just expanded what's possible per session. If you're sitting on a resource and AI lets you extract more of it per unit of effort, that's not disruption. That's finding more oil.

This is likely why Figma's pricing model and market position have held steady through a period that has put visible stress on CRM, support, and workflow automation companies. The seat in Figma isn't measuring activity. It's underwriting production capacity, and AI just made each seat more productive. The same logic applies to development tools, audio production, video editing, and most creative software. The interface isn't the meter. It's the factory floor.

The boundary between these categories isn't always clean. Some tools meter and produce simultaneously, and the ratio determines how exposed they are. A project management tool that also functions as a collaborative workspace sits closer to the production end than a pure tracking system. The question for any software company trying to read its own exposure is which side of the line most of its value sits on, and whether that answer changes once agents are doing the navigating.

The metering tools have the harder problem. Their value was always the visibility, and visibility is exactly what agents replicate first.

Some, if not most, speculation assumes humans remain meaningfully in the loop. The supervision model, the reflection model, the idea of the screen as a site of judgment: all assume that somewhere in the chain a person still intervenes.

It's worth asking what happens if that assumption weakens or is plain wrong. Systems get good first at repetition, then at the adjacent workflows near that repetition. Humans intervene less often. Once intervention becomes occasional, people lose familiarity with the work they were supposedly there to supervise. Shaw and Nave's research on cognitive surrender suggests this isn't just an organizational pattern but a cognitive one: the more available the system, the less the evaluation muscles get used, and the less the person notices they've atrophied. The role evaporates from both sides at once: the system needs less help, and the human gets worse at giving it.

The person doesn't disappear in a single moment. They get pushed further from the operating layer until "in the loop" stops describing anything precise.

At that point the software isn't really being used as a tool in the old sense. It's operating more like infrastructure: capability delivered continuously, often invisibly, with no one opening the application to make it run. What that looks like in practice is unclear to all of us.

I ask this as someone also working out the answer. The dashboards I still open when something feels off might be judgment rehearsing itself. Or they might be habit that hasn't realized it's no longer necessary. It's not obvious which.