The headless product

Sebastian Mertens · 25 August 2026

A hosting product usually asks a new customer to start configuring things. Create a project. Connect a repository. Choose an environment. Find the database settings. Work out which configuration belongs where.

When I built ohmyho.st, I chose a different starting point: a prompt the customer can copy into the agent they already use. The intention is that the agent carries the deployment forward. The customer describes the outcome; the service exposes the operations required to reach it.

That decision led me to a larger question. If an agent can understand what a customer wants and operate the necessary services, how much of a product’s dedicated interface does the customer still need to learn?

The strongest version of this idea is often expressed as a prediction that products will have no UI. I think the more consequential change is that a product’s interface can become optional for obtaining its value. A person may continue to use visual controls, but those controls no longer have to belong to every individual service involved in the task.

I call this the headless product: software whose core capabilities can be discovered, invoked, composed and verified by an agent independently of its own graphical workflow. Research on agent interfaces gives this idea an empirical basis. It also identifies the conditions under which it works.

Figure 1. The ohmyho.st onboarding screen directs the customer to continue setup in an external agent, with MCP and CLI options available. Screenshot supplied by the author.

The capability becomes independent of the screen

The important unit of a headless product is an operation with a defined effect. A deployment service publishes a particular version of an application. A workflow platform executes a scenario with specified inputs. A business system retrieves or updates a record under the permissions of an authenticated user.

A graphical interface can present these operations to a person. A programmatic interface can expose them to an agent. The underlying product still needs to implement the operation correctly, preserve its state and explain its result.

This separates two relationships that are often conflated: the person interacting with an agent, and the agent interacting with a service. The first relationship may benefit from conversation, diagrams or direct manipulation. The second requires precise capabilities and usable feedback. Improving one does not imply eliminating the other.

The resulting design question is practical. Can the agent discover the operation it needs? Does it understand the required parameters? Can it inspect current state before changing it? Can it distinguish a request that was accepted from work that actually finished?

If those questions cannot be answered, removing the dashboard merely removes a source of information. A useful headless product has to make the operational knowledge that a human interface once supplied available in another form.

Interface design changes what an agent can accomplish

The research suggests that the interface is part of an agent’s effective capability.

In SWE-agent, published at NeurIPS 2024, Yang and colleagues evaluated the same GPT-4 Turbo model on 300 SWE-bench Lite software-repair instances. A shell-only agent supplied with a demonstration resolved 11.0% of them. The designed agent-computer interface resolved 18.0%. Editing support, search behavior and feedback affected outcomes without changing the underlying model. This is historical evidence from repository repair, but it establishes a useful principle: giving an agent a terminal is not the same as giving it an effective way to work. Yang et al., 2024

The same issue appears in web interaction. Beyond Browsing, published in Findings of ACL 2025, compared GPT-4o agents on 812 WebArena tasks. Browsing alone achieved 14.8% success, API access 29.2%, and combined API and browser access 38.9%. APIs improved access to useful operations, while browser access remained valuable. The study introduced task-agnostic APIs for one environment, and its API-based configurations incurred higher inference costs. It supports programmatic access, with explicit limits on claims about universal efficiency. Song et al., 2025

More recent enterprise research reaches a related conclusion. The August 2026 version of Terminal Agents Suffice for Enterprise Automation evaluates 729 tasks across ServiceNow, GitLab and ERPNext. With Sonnet 4.6, browser agents achieved 72.2% success at an average inference cost of $3.29 per attempt. Terminal agents using APIs achieved 72.7% at $0.56. A generic authenticated API tool achieved 73.5% at $0.15, while a narrow MCP catalogue achieved 32.9%. These are preprint results on API-accessible platforms. The authors attribute much of the difference to coverage and granularity, not MCP itself; the browser configuration also used MCP. Bechard et al., 2026

That qualification matters. An incomplete tool catalogue can make a capable model ineffective. The protocol carrying the request cannot supply an operation that the product never exposed.

A June 2026 preprint makes the limitation particularly clear. Across 440 matched desktop tasks, the strongest tested GUI configuration achieved 59.1% success and the original CLI skills achieved 48.2%. Repairing the skills raised CLI performance to 69.3%. However, those repairs used verifier information, so the result is a diagnostic upper bound rather than evidence of unseen-task performance. The strongest GUI and CLI configurations also used different models. The finding supports interface completeness, rather than an automatic advantage for command lines. Zhou et al., 2026

Taken together, these studies change what I would prioritize when designing a product for agents. The relevant question is whether the interface exposes enough of the service, with enough clarity, for the agent to complete a meaningful task. The number of tools is a poor substitute for that assessment.

MCP and CLI have different jobs

MCP provides a shared structure for connecting agent hosts to servers that expose tools, resources and prompts. Its architectural value lies in making independently developed capabilities accessible through compatible clients. It does not define a product’s business logic or guarantee the correctness of an operation. Model Context Protocol, 2025

A CLI provides executable commands. Code execution adds the ability to combine operations, filter results and implement control flow. An agent can use these mechanisms together: discover a capability through MCP, execute a sequence programmatically and return a concise result to the user.

There is experimental support for the value of that composition. In Executable Code Actions Elicit Better LLM Agents, published at ICML 2024, executable Python actions achieved 74.4% success on an 82-task evaluation with GPT-4-1106-preview, compared with 52.4% for JSON actions. Code offered a richer action space within each turn. This was neither a GUI comparison nor an MCP evaluation, but it helps explain why programmatic composition can matter. Wang et al., 2024

For a product builder, the practical implication is to maintain a coherent service contract beneath these access methods. MCP and CLI should not disagree about permissions, current state or the meaning of success. The customer should be able to change agent environments without inheriting incompatible versions of the product’s behavior.

This is also why I would avoid tying the entire thesis to the permanent dominance of one protocol. The durable requirement is dependable machine access. MCP and CLI are concrete ways to provide it today; the underlying product should remain understandable if the preferred client changes.

Established products are exposing the same separation

The pattern is visible in products that already have substantial graphical interfaces.

Make documents an MCP server that lets compatible AI systems run active, on-demand scenarios and manage resources within selected authorization scopes. Its separate CLI supports terminal-based resource management. Together, these interfaces allow an external agent to work with capabilities that customers have traditionally accessed through Make’s application. Available MCP tools depend on authorization scopes, and MCP management tools require a paid plan. Make MCP documentation, Make CLI documentation

Figure 2. Make’s Developer Hub documents scenario execution and account-management capabilities available to compatible agent clients. Screenshot supplied by the author.

Salesforce presents a similar direction through its Headless Toolkit, which describes MCP, APIs, skills and CLI commands as access methods for external agents. Its technical documentation is more specific: the unified Headless 360 MCP server is a beta offering, initially focused on administrative operations. That distinction keeps a broad product vision separate from the capabilities documented for a particular release. Salesforce Headless Toolkit, Salesforce Headless 360 documentation

Figure 3. Salesforce presents existing business capabilities as accessible through external agents and applications. The screenshot illustrates product positioning rather than measured performance. Screenshot supplied by the author.

These examples establish that suppliers are building and documenting external agent access. They do not establish how much customer work has moved to those interfaces or whether every workflow improves. The research papers carry the empirical performance argument; the product documentation shows how the architectural idea is being implemented.

For an established platform, this creates another route into capabilities it already provides. For a new product, it changes the starting assumption. The dedicated application no longer has to be the only place where the complete customer journey can happen.

A headless product still has to explain what happened

The difficult part of delegation begins when an operation does not finish as expected.

A request may time out while work continues. A deployment may be accepted but later fail. Another process may change the resource between inspection and execution. An agent that cannot distinguish those states may repeat an action, overwrite a newer change or report success prematurely.

Make’s documentation contains a concrete example: a scenario can continue running after the tool call times out, and the response supplies an execution identifier for retrieving the result later. The agent needs that identifier to continue the original operation rather than assume that nothing happened. Make MCP documentation

This is the kind of operating contract I want from an agent-oriented service. Planning should reveal the intended change. Execution should produce a trackable operation. Retrying after an uncertain response should not accidentally duplicate the work. Completion should be supported by an observable result.

The published ohmyho.st deployment instructions describe that sequence: work from an exact pushed commit, obtain a plan, execute it, follow the operation and verify relevant application behavior. A successful build alone is insufficient. I use this as an example of the intended architecture, rather than as evidence that the product outperforms another host. That comparison would require a controlled evaluation.

Authority must also stay grounded in the service. AgentDojo, published at NeurIPS 2024, evaluates agents performing tool-based tasks while encountering adversarial instructions in untrusted content. Its relevance here is that retrieved text can interfere with an agent’s behavior even when useful tools are available. The system must distinguish information encountered during a task from permission to change the task. Debenedetti et al., 2024

My design conclusion is that the backend must remain authoritative for permissions and allowed state transitions. An agent can coordinate the work, but a fluent explanation cannot substitute for a permission check or a verified result. Making a product accessible from another interface increases the importance of a reliable contract.

The human interface can move closer to the task

None of this requires people to work exclusively through text.

The MCP Apps extension allows tools to supply interactive experiences inside an agent client. It provides a concrete mechanism for a service to offer visual interaction where the user is already working. The existence of that extension supports interface migration rather than the disappearance of graphical interaction. MCP Core Maintainers, 2026

Human-computer interaction research gives a reason to preserve that choice. DirectGPT, published at CHI 2024, studied 12 participants across 288 editing trials and reported 50% faster completion with a direct-manipulation interface than with its chat comparison. The study used a historical model and a limited task set. It does not rank MCP against CLI; it shows that the human side of an AI workflow can benefit from visual control. Masson et al., 2024

A customer asking about hosting costs might benefit from a chart. Someone reviewing a proposed change might need a diff. A person comparing several alternatives may want to select directly from a table. An agent can obtain the data and perform the underlying operations while presenting an interface suited to the decision.

The opportunity is to reduce the number of product-specific workflows a person must navigate. A shared agent environment can become the place where those capabilities are brought together. The supplier may still provide a dedicated interface, but entering it becomes a choice rather than a prerequisite for every operation.

Becoming callable changes the business as well

There is a commercial consequence to that separation. If customers interact primarily through an agent, the agent may influence which supplier receives the work. Easier integration can expand a product’s reach while also making alternatives easier to compare.

Hydari and Muzaffar examine this issue in Going Headless? On the Boundaries of Vertical AI Firms. Their 2026 theory preprint argues that agents can lower coordination costs while increasing orchestrators’ distribution power. It identifies authoritative records, evidence and accountability as potential sources of retained value. This is a conceptual framework, not an empirical demonstration of which business models will win. Hydari and Muzaffar, 2026

For a hosting service, I read that as a reason to keep the core service strong while making access flexible. The agent can choose how to request a deployment. The hosting provider still needs to execute it dependably, preserve the relevant state, explain the bill and support recovery when something goes wrong.

The product’s quality becomes visible through the work it completes. A clean interface can help communicate that quality, but agent access makes reliable execution and understandable results directly consequential to whether the service can be used at all.

What would make the thesis convincing

Two claims need to be tested separately. The first is feasibility: can an agent complete the product’s core workflows without using its graphical interface? The second is comparative benefit: does that arrangement reduce human effort or total cost, or improve reliable completion?

A functional headless product could satisfy the first claim while failing the second. To establish an advantage, an evaluation would need representative tasks, equivalent permissions and capabilities, matched initial states, repeated runs and independent verification. It should count failed attempts and recovery work, not just successful demonstrations.

The most useful measure would be a correct and authorized customer outcome. Active human time matters alongside elapsed time. A workflow that completes without supervision may be valuable even if it takes longer; one that needs frequent rescue may be expensive despite low token usage.

That is the standard I would apply to the products built around this idea. The literature already supports the importance of programmatic access and carefully designed agent interfaces. It does not establish that every graphical workflow should disappear, nor that adding MCP or a CLI automatically improves a product.

My expectation is that more software will be designed so its core value can be obtained without entering its own application. Agents make that architecture useful to people who would never write the integration themselves. MCP helps connect the capabilities; CLI and code help execute and combine them; the service remains responsible for what its operations do.

For me, the headless product is a commitment to make the product fully usable by the agent the customer brings. Its success will be judged by whether that agent can accomplish the customer’s goal reliably, and whether the person can understand and trust the result.

Research and technical references

The empirical findings above come from published research and explicitly identified preprints. Specifications and supplier documentation establish architecture or documented availability, not independent performance. Sources were assessed through 24 September 2026. I built ohmyho.st and include it as an illustrative case; this essay reports no new controlled experiment.

1. Yang et al. (2024). SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. NeurIPS 2024. Paper.
2. Song et al. (2025). Beyond Browsing: API-Based Web Agents. Findings of ACL 2025. Final publication.
3. Bechard et al. (2026). Terminal Agents Suffice for Enterprise Automation. arXiv:2604.00073v3, 5 August 2026. Preprint. Paper.
4. Zhou et al. (2026). GUI vs. CLI: Execution Bottlenecks in Screen-Only and Skill-Mediated Computer-Use Agents. arXiv:2606.24551v1. Preprint. Paper.
5. Wang et al. (2024). Executable Code Actions Elicit Better LLM Agents. ICML 2024. Proceedings.
6. Debenedetti et al. (2024). AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. NeurIPS 2024 Datasets and Benchmarks. Proceedings.
7. Masson et al. (2024). DirectGPT: A Direct Manipulation Interface to Interact with Large Language Models. CHI 2024. Paper.
8. Hydari and Muzaffar (2026). Going Headless? On the Boundaries of Vertical AI Firms. arXiv:2605.17812. Conceptual preprint. Paper.
9. Model Context Protocol (2025). Architecture. Specification version 2025-11-25. Specification.
10. MCP Core Maintainers (2026). MCP Apps: Bringing UI Capabilities To MCP Clients. 26 January 2026. Official announcement.
11. Make (n.d.). Make MCP Server and Make CLI. Documentation accessed 24 September 2026. MCP documentation; CLI documentation.
12. Salesforce (n.d.). Headless Toolkit and Headless 360 MCP Server Beta. Documentation accessed 24 September 2026. Product page; Technical documentation.