Headless User

13 min read

ai, agents, enterprise-software, labor-markets, principal-agent, verification, salesforce

As AI agents become operators of enterprise software, principal-agent theory offers a useful—if imperfect—lens. The Verifier Class is my hypothesis for where the work may relocate.

From user-as-person to user-as-agent: the re-designation reshaping software and labor

In mid-April 2026, Salesforce announced Headless 360 at TDX: a restructuring of the platform around APIs, Model Context Protocol tools, and command-line interfaces (Salesforce). Salesforce said humans are no longer the only navigators of its platform. I read the release as a bet that AI agents will become important software operators; Salesforce did not establish that they are already the primary user.

The choice of words matters. A decade of design orthodoxy made "user" synonymous with "person." Personas had names, photos, goals; design sprints began with empathy maps; wireframes imagined someone's eyes moving across a screen. Headless 360 does not refine that orthodoxy. It disaggregates it. The browser becomes a legacy surface. The spreadsheet view becomes one of many outputs, not the output. The screen is optional.

Salesforce said the launch included more than sixty MCP tools and more than thirty coding skills alongside a broader set of agent-facing surfaces. I treat that as evidence of a platform strategy, not evidence that browser interfaces or human operators have already become secondary.

The shift is visible elsewhere in the tooling layer. The New Stack observed this month that Cursor, Claude Code, and OpenAI's Codex are "merging into one AI coding stack nobody planned" (The New Stack). Adjacent platforms are also adding agent-building layers of their own, as Atlassian's Rovo documentation makes plain (Atlassian). Each of those products presupposes an operator who can read, edit, and trust generated artifacts without examining them line by line. The artifact is no longer the dashboard. The artifact is the behavior.

What is happening is not a step forward in user experience. It is a re-designation of who the user is. For three decades, enterprise software treated the human as principal: the entity whose attention, approval, and error constituted the system's feedback loop. The human clicked; the software responded. The loop was tight because latency between intention and input was low. Software companies optimized every inch of it: faster forms, fewer clicks, prettier dashboards.

That loop is breaking. Not because the human is being eliminated. The human is still the source of intent, the owner of the account, the one who pays the bill. But the human is no longer the entity at the console. Something else is. It types. It makes API calls. It operates the software.

Calling that something a "user" strains the word. It is, more accurately, an agent operating on behalf of a user. And the distance between the two, between principal and agent, is where the new terrain opens up.

The Disappearing Interface

The trajectory had a long run-up. On Lenny's Newsletter, Marc Andreessen described natural language as the next abstraction layer above higher-level languages, after machine code and assembly had given way to C and Python (Lenny's Newsletter). Andrej Karpathy, formerly of Tesla and OpenAI, formalized the latest move with his Software 1.0, 2.0, and 3.0 taxonomy, where English prompts become a way of programming LLMs (Y Combinator podcast). Each layer made the computer accessible to a wider population and obsoleted a narrower one.

Guillermo Rauch, founder of Vercel, put the implication in stark terms on the same podcast: many programming jobs that used to be specialized are becoming translation tasks, especially from intent or design into implementation (Lenny's Newsletter). Translation, from design to code, from policy to configuration, from specification to schema, has been the middle layer of white-collar software work for two generations. My stronger interpretation is that some translation-heavy roles lose their existing moat; labor displacement is a forecast, not a result established by these product announcements.

Headless 360 is the enterprise version of the same move, and it is not singular. In the same window, Oracle, SAP, Workday, and ServiceNow each shipped parallel agent-platform moves. The browser was a translation layer: human intent expressed through clicks on forms that wrote to tables through middleware that called APIs. Remove the browser and the chain contracts: intent maps to API call, with the agent doing the translating. The administrator who knew how to click through seventeen screens to configure a compliance rule loses the moat that the screens provided. So does the operations specialist who memorized the order of checkboxes. So does the trainer who taught new hires the click path.

What replaces those moats? Not new ones at the same layer. The layer itself is dissolving. In its place sits a different set of artifacts (the system prompt, the tool schema, the evaluation harness) and a different set of practitioners who produce them. Anthropic, OpenAI, and Salesforce are each, in different ways, shipping the primitives of this replacement layer (Anthropic MCP docs; OpenAI function calling; Salesforce).

The counterintuitive thing about a disappearing interface is that the work does not disappear with it. The work relocates. Someone still has to decide what the compliance rule means, what the acceptable exceptions are, and what should happen when the agent's proposal sits at the edge of policy. That someone is no longer clicking. They are, increasingly, reviewing.

The question is what to call them.

The Principal-Agent Problem, Machine Edition

The economics literature has a fifty-year-old framework for exactly this situation. In 1973, Stephen Ross published a paper introducing what he called the principal's problem: a situation in which one party delegates an action to another and the agent holds private information the principal cannot fully observe (Ross 1973). Three years later, Michael Jensen and William Meckling formalized the framework in Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure, defining agency costs as the sum of the principal's monitoring expenditures, the agent's bonding expenditures, and residual loss (Jensen and Meckling 1976). The gap between what the principal wanted and what the agent delivered is the whole logic of the framework.

For half a century, the framework was applied to human agents. Shareholders delegated to executives. Clients delegated to lawyers. Patients delegated to physicians. Every elaboration of the theory (performance-linked compensation, fiduciary law, audit committees, board independence rules) was an attempt to narrow the residual loss by reshaping monitoring.

In 2026, the framework is a useful heuristic, not a structural equivalence. Software has no self-interest, fiduciary duty, or intentional private action. What carries over is the practical problem of delegated action under limited observability: monitoring cost, specification gaps, and residual loss. Two recent management papers, Humberd and Latham (2026) in the Journal of Management Studies and Jarrahi and Ritala (2025) in the California Management Review, explore related mappings.

Private information, in the original framework, was the agent's superior knowledge of conditions the principal could not observe. The machine analogue is opacity: users cannot reconstruct model behavior from the API surface alone. Divergence of interests, in the original, involved intentional personal gain. Models have no interests; the nearest analogue is objective mismatch, where training incentives and system design fail to produce the user's intended outcome. Monitoring cost becomes the price of verifying outputs and side effects at production scale. Residual loss becomes the gap between intended and realized behavior: hallucination, scope drift, or silent failure.

The theory anticipated every dynamic that agent-deployment teams are currently rediscovering. What it did not anticipate was the scale. A human lawyer produces one document at a time. A human executive makes one decision at a time. Monitoring that volume is expensive but bounded. A software agent produces documents, decisions, and side effects at a rate no principal can survey by default. The monitoring cost, in the classical framework, was a question of diligence. In the machine edition, it is a question of capacity.

That capacity, where it exists, is concentrated in a small and unnamed group of people. They are the bottleneck. They are, though no one has said it yet, a class.

The Verifier Class

Alexander Embiricos of OpenAI's Codex team described a coding-workflow bottleneck as human validation and code review rather than raw code generation (Lenny's Newsletter). I propose that the pattern may generalize. Evidence from coding does not by itself establish the same bottleneck in law, medicine, finance, or marketing.

That pass is harder than it appears. Hamel Husain and Shreya Shankar, AI-evals researchers, argued that evaluation criteria change as people inspect more outputs, which means the rubric cannot be fully fixed in advance (Lenny's Newsletter). The verifier is not only checking the agent's work against a specification; they are constructing the specification in real time, in response to the distribution of outputs the agent actually produces. Evaluation, in this regime, is not a matter of applying a test suite. It is a matter of inventing one under pressure.

What that looks like in practice is a possible gap between generator throughput and review capacity. Veracode's Spring 2026 synthetic benchmark found secure outcomes in 55 percent of 80 tested code-generation tasks without security prompting (Veracode). Separately, a report about Y Combinator's W25 cohort said roughly a quarter of the batch had codebases described as 95 percent AI-generated. Neither source measures production audit intensity, so together they motivate a question rather than prove that lightly audited production is common.

My hypothesis is that a similar pattern will appear in legal review, medical note-taking, financial analysis, and marketing copy. Each domain needs its own deployment evidence because its verification rules, liability, and throughput differ.

This role has no title. It has no career ladder. It does not appear on org charts. It is filled, at present, by the people who happen to be nearby: the senior engineer who was supposed to be writing features, the staff lawyer who was supposed to be advising clients, the lead designer who was supposed to be creating. Their explicit job is something else. Their actual job is to review what an agent produced and decide whether it ships.

They are the Verifier Class. The name is new; the function is not. But the conditions are.

What distinguishes a verifier from a reviewer, editor, auditor, or approver is not the act of review. It is the co-occurrence of three conditions.

The upstream queue can scale cheaply relative to human throughput, although it remains bounded by compute, budgets, rate limits, and system design. The verifier's throughput is bounded differently, by human cognitive bandwidth. The rubric is often partly emergent: fixed tests cover known requirements, while inspection reveals new failure modes that require the rubric to evolve.

Editors and auditors meet one or two of those conditions. The verifier meets all three at once. That is the economic heart of the role.

The Distribution Question

The dominant narrative about AI's effect on labor has centered on displacement: generative systems will compress the middle of the skill distribution, rendering mid-range knowledge workers redundant while concentrating gains among capital owners and frontier talent. That narrative assumes the friction-free case: an agent that ships its own output without review.

Verification changes the shape. Unlike generation, verification is domain-heavy. A general-purpose agent can draft a patent application, a radiology report, a quarterly earnings release, and a loan approval. The verifier for each must possess the domain knowledge of a patent attorney, a radiologist, a controller, and a credit officer respectively. That knowledge is not transferable. It is not quickly synthesizable. It is acquired through years of specific training in a specific context, and it is the hardest thing to outsource.

The counterintuitive consequence is that verification may re-localize certain kinds of expertise. Offshoring, in prior decades, depended on execution being decoupled from context: the specification was written once, in the source country, and executed many times, abroad. Verification cannot be decoupled. Every output is a fresh judgment. Every judgment requires the context the agent did not supply.

Figma's State of the Designer 2026, a survey of 906 digital designers run with NewtonX, reports respondents' perceptions of faster work, collaboration, and design quality (Figma blog). I interpret those responses as evidence that selection, curation, and editorial judgment are becoming more important. The survey does not directly measure cost collapse or establish judgment as the causal binding constraint. In a separate hiring-focused post, Figma argued that AI is increasing demand for designers, especially senior hires with stronger judgment and experience (Figma hiring post). That is Figma's market interpretation, not labor-market administrative evidence.

In Lenny Rachitsky's February 2026 interview, Lazar Jovanovic of Lovable framed the replacement skill as clarity, taste, judgment, and better decision-making rather than raw coding speed (Lenny's Newsletter). Clarity, in this context, is the ability to specify an intent the agent cannot misinterpret and to recognize when it has. That is the same cognitive move verification asks for, phrased from the other direction.

These observations motivate a forecast: the labor market may stratify along a generator-versus-verifier axis that cuts across existing roles. If that happens, domain-heavy verification could command a premium. Compensation and hiring data do not yet establish the forecast; wage postings, role definitions, review loads, and time-to-hire would make it testable.

That asymmetry is the labor market's next pricing anomaly.

The Two Interfaces

I expect many leading software products built in the next five years to carry two interfaces, whether their designers name them or not.

The first is the protocol interface: the surface through which agents operate the system. Its primitives are the API endpoint, the MCP tool definition, the CLI command, the permission scope, the rate limit. Its design discipline is legibility to a model: naming that resists ambiguity, schemas that fail closed, documentation dense enough for retrieval but structured enough for tool selection. Salesforce's Headless 360 is an early public statement of what this interface looks like at enterprise scale, while Anthropic's Model Context Protocol and OpenAI's tool-use specifications are part of the ecosystem infrastructure around it (Salesforce; Anthropic MCP docs; OpenAI function calling).

The second is the judgment interface: the surface through which a verifier reviews, approves, amends, or rejects what the agent did. Its primitives are the diff, the rollback, the trace, the attribution chain, the approval queue. Its design discipline is not legibility to a model but legibility to a domain expert operating under time pressure. What happened. Why. What changes if it stands. What breaks if it is reversed. A well-designed judgment interface lets a domain expert confirm an AI-assisted output quickly; a poorly designed one forces them to redo the work manually and erases the efficiency gain the agent was meant to deliver.

Most companies, at present, are building the first interface aggressively and the second almost not at all. The protocol surface gets a roadmap, a dedicated team, and board-level attention. The judgment surface gets a retrofitted admin panel, a CSV export, or, increasingly, nothing, on the assumption that the agent is "good enough" to ship without review. Every verifier now working out of a ticketing system disproves that assumption.

A falsifiable forecast: by the end of 2028, I expect most leading enterprise software vendors to ship a named, first-class judgment interface. The forcing function is procurement, not agency theory. As early agent-era contracts come up for renewal, the verifier-burnout question will be hard to answer without a dedicated surface.

The deeper shift is older than any of the technology. Jensen and Meckling's 1976 framework moves from economics departments to product roadmaps. The monitoring costs they modeled become UX budget line items. The residual loss they named becomes a quarterly metric. Agency theory, for five decades the language of corporate governance, becomes the language of software design.

When the user is an agent, the customer is a verifier. The distinction is not rhetorical. It is the shape of the next decade of enterprise software, and of the labor market that runs it. The products and careers that understand this will compound. The rest will keep optimizing for a principal who has already left the screen.

Sources