Headless User

14 min read

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

When the primary user of enterprise software becomes an AI agent, Jensen and Meckling's 1976 principal-agent framework stops being a metaphor. The verifier class emerging on the other side is the labor market's next pricing anomaly.

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; VentureBeat). The release was not a UX refresh. It was a recognition that the primary user of enterprise software is no longer a human.

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.

The trade press read the shift as cleanly as Salesforce did. VentureBeat described the launch as infrastructure for AI agents, while PPC.land framed it as a move that removes the browser as the mandatory interface (VentureBeat; PPC.land). Salesforce said the launch included more than sixty MCP tools and more than thirty coding skills alongside a broader set of agent-facing surfaces (Salesforce). That is the scale of a platform pivot, not a product release.

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. Rauch's claim is not that programming disappears. It is that the translators do.

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 applies with unusual directness. Software has no self-interest or fiduciary duty, so the analogy is not perfect, but the structural assumptions carry over cleanly enough that the cost categories map without much forcing. Two recent management papers, Humberd and Latham (2026) in the Journal of Management Studies and Jarrahi and Ritala (2025) in the California Management Review, make the same move independently — treating AI as a new kind of agent inside the firm and asking what monitoring and bonding look like when the agent is software.

Private information, in the original framework, was the agent's superior knowledge of conditions the principal could not observe. In the machine version, the private information is the model's internal reasoning: the chain of activations that produced the output, which cannot be inspected from the API surface. Divergence of interests, in the original, was the agent pursuing personal gain at the principal's expense. In the machine version, it is the training objective diverging from user intent: the model optimizing for plausible output rather than correct output, for the appearance of helpfulness rather than the substance. Monitoring cost, in the original, was the price of auditing the agent's actions. In the machine version, it is the cost of verifying model outputs at production scale, a cost that scales with output volume rather than with task importance. Residual loss, in the original, was the delta between intended outcome and realized outcome. In the machine version, it is hallucination, scope drift, silent failure: the full taxonomy of errors a principal may never detect.

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 the current bottleneck as human validation and code review rather than raw code generation (Lenny's Newsletter). Embiricos was describing a specific workflow (asynchronous coding agents that spin up, produce changes, and return them for approval), but the diagnosis generalizes. Across domains, the step that determines whether an agent's output enters production is the human pass that follows it.

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 floor of defects the generator reliably introduces and a ceiling of review capacity the verifier can reliably supply, with the gap widening as usage scales. The floor is measurable: Veracode's Spring 2026 update found that 55 percent of tested AI code-generation tasks were secure, implying a roughly 45 percent rate of known security flaws across the benchmarked set (Veracode). A Y Combinator discussion of its W25 cohort, reported by TechCrunch, said about a quarter of the batch had codebases that were 95 percent AI-generated (TechCrunch). High-volume generation running into lightly audited production is not a prediction; it is already common.

None of this is unique to code. The pattern repeats in legal review, in medical note-taking, in financial analysis, in marketing copy. In each domain, the agent produces at volume; a human checks; the checker is the constraint. The domain-specific detail differs. The shape of the role does not.

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 is uncapped: output is produced by a system whose throughput scales with API spend, not with another human's working hours. The verifier's own throughput is not: it is bounded by human cognitive bandwidth and does not scale with the same lever. The rubric is emergent: as Husain and Shankar describe, it has to be formed in response to the distribution of outputs the system actually produces, not defined in advance.

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, documented a sharp reshaping of the role itself (Figma report; Figma blog). Execution work (the production of mockups, wireframes, prototypes) has collapsed in cost, while judgment work (the selection, curation, and editorial direction of generated options) has become the binding constraint the survey respondents describe. 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). The two claims sit at different levels. One is what designers report about their own work, the other is how Figma interprets that for its enterprise customers. Both point in the same direction. The job title did not change. The job did.

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 point in one direction. The labor market is not flattening toward a narrow frontier elite. It is stratifying along a new axis (generator versus verifier) that cuts across existing roles. The high-leverage position is the verifier in a domain that matters, with the context that cannot be easily scripted and the judgment that cannot be easily automated. Compensation will follow. So will hiring friction: the number of people who can generate at scale is exploding; the number who can verify at scale is not.

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

The Two Interfaces

Every software product built in the next five years will carry two interfaces, whether its 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