The Abstraction Shift: How Software Keeps Moving Up

Software is acquiring a new abstraction layer. That is why its vocabulary is expanding.

A phrase like timed multi-round web lookup sounds like a narrow product feature. It is more useful as a specimen of a larger shift: a system can search, inspect evidence, reformulate a query, and decide when to stop.

The same shift appears in agents, tool calling, context engineering, retrieval, memory, evaluation, orchestration, interoperability, and computer use. These terms are not interchangeable, but they cluster around one architectural change: a model can participate in application control flow.

The vocabulary is changing quickly. It is tempting to treat that as a terminology problem, learn the definitions, maintain a glossary, and keep up with the next announcement. A more durable approach is to ask what changed in the system and what remains familiar.

This series uses yesterday to establish lineage, today to examine patterns already affecting architecture and engineering, and tomorrow to consider emerging directions without presenting them as settled predictions. A phrase can disappear while the architectural pattern it names continues to develop.

The vocabulary is changing because the architecture is changing.

The software abstraction boundary is moving

For most application software, people have traditionally defined both the capabilities of a system and the logic that determines when those capabilities are used.

In simplified form, the earlier shape and the AI-native variation are shown in the control-flow diagram below.

Real software has never been perfectly deterministic. Distributed systems fail. Networks behave unpredictably. Search, heuristics, machine learning, concurrency, and external dependencies have always introduced uncertainty.

Even so, the control flow of most business applications was largely specified by engineers. The system could be complex without deciding for itself what operation should happen next.

AI-native software introduces a different arrangement. We can place a model inside the control loop and allow it to participate in decisions about what happens next.

That does not make conventional software irrelevant. It changes where some of the decision-making takes place, and it makes the boundary between deterministic and probabilistic behavior an architectural concern.

The abstraction boundary moves when a model participates in application control flow.

Once a model became an active participant in control flow, engineers needed names for the surrounding pieces.

What information should the model receive? How should that context be assembled? What capabilities may it invoke? How does it choose among them? How does state persist across decisions? How do we evaluate an output when there is not always one correct answer? How do we constrain actions that may have real-world consequences?

Terms such as context engineering, tool calling, agents, memory, evals, guardrails, MCP, deep research, and orchestration are labels forming around those questions.

The vocabulary explosion is not the story. It is evidence that a new abstraction layer is forming.

New terms do not mean entirely new ideas

Consider tool calling. A model identifies a need for an external capability, selects an operation, constructs arguments, invokes the capability, receives a result, and continues.

If you have worked with distributed systems, part of this sounds familiar. Tool calling resembles RPC, except that the caller choosing what to invoke may be probabilistic.

That comparison is useful, but it is not complete.

Traditional RPC does not infer from a natural-language goal which operation should run. It does not normally choose among available functions semantically, or generate parameters because a description suggested that a particular function was appropriate.

So tool calling is neither entirely new nor simply RPC with a new label. The important question is:

What part is old, what part is new, and where does the analogy break?

That is the question I will use throughout this series.

Old ideas still matter

The same pattern appears in other parts of the emerging AI application stack.

Agent memory brings back familiar questions about state, persistence, retrieval, lifecycle, consistency, and forgetting. The difference is that the system may decide what to remember, what to retrieve, and how to use the result in a probabilistic context.

Model gateways resemble API gateways in the same way: they still route requests and provide a layer for policy and observability. Model providers add different concerns on top, though, around cost, latency, context limits, model capability, nondeterminism, and fallback behavior.

The relationship between agent orchestration and workflow orchestration is similarly close, and similarly incomplete. It holds right up until a worker can interpret a goal, select its next action, and behave differently for the same input.

Computer use has a lineage through browser automation and robotic process automation. The shift is that a model can interpret an interface semantically rather than follow only a fixed sequence of selectors or coordinates.

Sometimes the older analogy gets us surprisingly far. Sometimes it stops being useful almost immediately. Both outcomes matter because they tell us where the engineering has actually changed.

Historical analogies are useful starting points, but they are not equivalences.

The comparison works in both directions

For an experienced engineer, a historical comparison can make a new abstraction easier to place:

Tool calling resembles RPC, but the caller can reason about which tool to use.

For someone earlier in their career, the comparison can work in the other direction:

What is RPC?

That question turns a modern AI concept into an entry point to decades of software architecture and computer science.

We should not explain AI-native software as though everything before it is obsolete. We should also not explain traditional software engineering as though nothing fundamental is changing. The useful work is connecting the two.

Build a vocabulary map, not a vocabulary list

No one can productively memorize every new AI term. A better approach is to place terms into a small number of architectural areas:

models and inference;
context;
retrieval;
tools and capabilities;
agents;
memory and state;
orchestration;
evaluation and observability;
guardrails and security;
protocols and infrastructure.

Then a new term does not arrive as an isolated acronym. It has somewhere to go, and we can ask how it relates to the rest of the system.

That is the difference between a vocabulary list and a vocabulary map: a list only helps with recognizing a term, while a map helps with deciding what to do about it.

The goal is to build a map of relationships, not a list of isolated definitions.

Not every concept deserves the same depth

There is too much material for anyone to learn everything deeply. I will use three levels throughout the series:

KNOW

Recognize the concept, understand why it exists, and follow a conversation about it.

UNDERSTAND

Understand how it works, its architecture, its tradeoffs, and its failure modes.

BUILD

Implement or experiment with it at least once because hands-on experience materially improves understanding.

Most emerging terminology belongs in KNOW. A smaller set deserves UNDERSTAND. Very few concepts need to reach BUILD.

Knowing the appropriate depth may now be nearly as important as knowing the term itself.

Follow concept deltas, not AI news

There is more AI news published every day than anyone with an actual job can reasonably consume. New models launch, benchmarks move, companies introduce agent frameworks, and someone declares software engineering dead.

Trying to follow all of it does not necessarily improve our mental model.

A more useful question is:

What changed in my mental model?

A product release may not change anything, while a new abstraction, protocol, capability, or failure mode usually does.

Those changes are the concept deltas worth tracking, because they change how we understand the system, not merely what appears in a news feed.

This series

That is what The Abstraction Shift: How Software Keeps Moving Up will explore.

Articles in the series

Each article will take one concept from the vocabulary of AI-native software and ask:

What does it mean?
Why does it exist?
What did we do before?
What capability changed?
What is genuinely new, newly composed, or simply newly named?
Where does the historical analogy break?
How does it work under the hood?
What changes because of it?
What can go wrong?
Should you KNOW it, UNDERSTAND it, or BUILD it?
Is the term likely to survive?
Where does it fit in the larger map?

The audience is broader than experienced engineers, even though that is the lens I bring to the work. The series is for people who build, design, manage, study, or are curious about modern software systems: engineers, enterprise architects, product leaders, technology executives, students, and technically curious readers.

The historical comparisons are meant to work for more than one kind of reader. An experienced technologist can use them to place an unfamiliar abstraction against something already understood. Someone earlier in a technology career can use the same comparison in reverse, as an entry point into decades of prior architecture. A technology leader can use the pattern to separate durable architectural change from terminology that will not outlast the current news cycle.

This is not intended to be another AI glossary. It is an attempt to reconstruct the emerging software stack one concept at a time, starting from the vocabulary that keeps showing up in conversations about it.

The next article in the series takes the first concept from the roadmap: the loop that starts when search stops being a single request and becomes a timed, multi-round process a model runs on its own.

Sources

This opening article is a framing essay rather than a technical reference article. Sources will be added to the individual vocabulary posts as each concept is researched.