The Software That Stays

The argument that agents will replace software often treats an application as a collection of screens. Many applications contain something harder to replace: an executable account of how a domain works.

A chip-design tool encodes constraints that a circuit must satisfy. A financial system maintains a consistent record of transactions. A simulation lets someone test a proposed design against a model of the world.

An agent may become the main way people interact with these systems. That can diminish the value of the interface while increasing the use of the underlying machinery.

The distinction matters for builders. Software will have to earn its place by doing work that remains useful when nobody is looking at its dashboard.

Skills change how capability is reached

In our conversation, Baris Gultekin described skills as instructions and scripts that an agent can load when needed. That makes capability modular. A person can ask for an outcome, and the agent can assemble the means of pursuing it.

This puts pressure on products whose main contribution is guiding a human through a sequence of routine steps. If the sequence becomes a reusable skill, the old interface may no longer deserve its own destination in someone's working day.

But the skill still needs something to execute. Instructions for checking a design need access to a checker. Instructions for reconciling a payment need reliable records and a way to update them without creating inconsistency.

A skill can package access to those functions. It does not make their underlying guarantees free.

This is the first refinement I would make to the show's “skills as the new apps” thesis: skills can reorganize the distribution of software without erasing the need for specialized execution.

A partnership reveals a possible division of labor

The September 30 OpenAI and Synopsys announcement describes a planned specialized model, GPT-Synopsys, alongside a multi-year partnership covering electronic design automation tools, joint research, and commercial collaboration.

The proposed system would bring model reasoning together with Synopsys tools and engineering verification. It is an announcement of an intended approach, not published proof of better chip-design economics.

The interesting signal is architectural. The proposed route to more autonomous design includes domain software as part of the execution environment. It does not assume that generating a convincing design description removes the need to evaluate the design.

That is consistent with a broader hypothesis: better agents can increase demand for tools that let them discover whether their proposals work.

The commercial outcome is still contested. A partnership does not establish who will capture the margin, how customers will buy the combined product, or how long the arrangement will remain advantageous. Those questions require operating evidence.

Representation and execution have different jobs

Stephen Wolfram made the underlying distinction in our conversation: natural language is useful for expressing intent, while a computational language can represent a problem precisely enough to calculate with it.

That gives the agent a powerful role. It can help someone formulate a question, translate it into an executable representation, run a tool, and interpret the result. Each step can make specialized software accessible to more people.

The representation still needs scrutiny. A perfectly executed simulation can answer the wrong question if its assumptions are wrong. A valid database update can record an unauthorized decision.

So the durable product is not simply “a deterministic tool.” It is a tool whose scope, inputs, outputs, and failure conditions can be understood well enough for the task at hand.

For an agent, that may require a more explicit interface than the human product ever had. A person can notice an ambiguous screen, call a colleague, and repair a misunderstanding. An agent needs the system to distinguish a proposed action from a committed one, a partial result from a completed one, and missing information from a negative answer.

The old interface hid some of this work inside human judgment. Automating the interaction brings it into the product contract.

Useful software does not guarantee incumbent power

The strongest counterargument is that agents will make specialized tools easier to replace too. Once the user stops visiting the interface, the incumbent may lose its privileged position in the workflow.

That is plausible. A common interface can make several implementations interchangeable. Agents can reduce migration effort, and cheaper software development can improve competing tools.

OpenROAD's documentation provides a concrete counterweight to the idea that domain execution must belong to an established commercial vendor. It describes an open-source chip-design application that integrates tools around a shared process and database, taking synthesizable circuit descriptions toward physical layout.

OpenROAD is not evidence that every commercial design requirement has been commoditized. It is evidence that specialized execution and open development can coexist.

That changes the claim. The software function can remain essential while a particular supplier loses pricing power. An indispensable category is not an entitlement to an incumbent's margins.

A vendor deserves to retain value where it supplies difficult-to-reproduce accuracy, trusted integration, operational reliability, or support that customers actually need. A large installed base may help, but it cannot substitute indefinitely for those contributions.

For customers, this is a reason to separate the agent interface from the choice of execution tools where practical. A convenient assistant should not quietly make every downstream tool choice permanent.

Build for a customer that calls functions

If agents become major users of software, product quality will increasingly show up in behavior that a screenshot cannot demonstrate.

An action should have a clear scope. A retry should not accidentally repeat a consequential transaction. Long-running work should expose progress and a recoverable failure state. The result should contain enough information to establish what the tool actually did.

These are familiar engineering concerns. Agentic use raises their economic importance because the interface can be invoked more often, with less direct human interpretation between steps.

Consider a hypothetical inventory service. An agent asks whether ten units can be promised to a customer. A useful tool distinguishes stock physically present from stock already allocated, identifies the location, and states when the information was checked.

A stronger version can place a bounded reservation, return an identifier, and let the agent confirm or release it. A reassuring sentence about availability is a poor substitute for that operational behavior.

The product opportunity lies in making a domain action easier to use correctly. That may support pricing based on transactions, capacity, or delivered service. The appropriate model depends on the work; a fall in human seat count alone cannot tell us the right commercial structure.

Access should improve as interfaces disappear

There is an ethical tension in this future. Specialized tools can make agents more reliable. Concentrating access to those tools can also make a small number of platforms more powerful.

We should preserve the first benefit without treating the second as inevitable.

A customer should be able to understand which tool performed consequential work, inspect relevant evidence, and move their own records through documented interfaces. Security and legitimate intellectual property impose real limits. They do not justify making every result intelligible only inside the original vendor's product.

The Cost of Leaving develops that obligation from the user's side. Here, it is a product strategy: become valuable because the tool works well, and make that value visible through reliable results.

The strongest software may disappear from the screen while remaining indispensable to the work.

Builders should design for that possibility. Customers should demand evidence that the underlying service earns its place. The arrival of agents gives us a chance to make sophisticated tools more accessible, provided we do not confuse easier interaction with permission for deeper captivity.

Abundance in Practice · Essay 3 of 5. Previous: The Acceptance Gap · Next: The Cost of Leaving.

Abundant intelligence needs instruments that make its work dependable. We explore that relationship between agents, computation, and ownership in the Masters of Automation newsletter.

all signal, no spam.