What Even Is an App?
The app isn't dying. It's dissolving. In the age of agents, software is becoming workflows, sandboxes, tool layers, and capability bundles rather than dashboards and screens.
Programming is not dead. SaaS is not dead. But the shape of the app is changing in ways that are easy to miss if you only look at model demos and vibe-coded prototypes.
If you build software, manage people who build software, or buy software for your organization, the mental model you carry about what an “app” is may need updating.
The Installed Era
It used to be obvious. An app was a binary. You installed it, launched it, it ran on your machine. The delivery medium evolved from tape to disks to downloads to app stores, but the core idea stayed the same: a self-contained artifact with a clear boundary and a clear runtime.
You owned the environment. You owned the machine. The app’s behavior was tightly coupled to that local context.
The SaaS Era
Then the browser became the runtime and the cloud became the computer. You stopped installing things and started subscribing. The app became a destination: A URL, a dashboard you lived inside for hours a day.
SaaS wrapped runtime, infrastructure, identity, UI, integrations, and update pipelines into one subscription. In the agent era, those layers can be recomposed. The runtime might be a local sandbox or a remote dev environment. Integration might be handled by shared tool protocols like MCP. Security might be enforced by constrained execution environments rather than login screens. Updates might live in rule files and workflow definitions rather than traditional releases.
Some SaaS products will shrink because parts of their value can now be recreated with agent-driven workflows. Others will remain durable because they are systems of record with real switching costs, data gravity, and compliance obligations that are not trivial to reproduce.
The Agent Era
Now an app might be a command inside an AI assistant. A workflow triggered from Slack. A background agent that wakes up, modifies a codebase, runs tests, and hands you a pull request (or updated legal contract). It might be a thin control surface wrapped around a reasoning engine. It might be a capability layer that other systems call into without a human ever opening a dedicated interface.
You don’t always open the app anymore. You invoke it.
The browser is no longer the only surface. The CLI is back. Chat is a surface. Internal tools are surfaces. APIs are surfaces. Siri with App Intents could become the universal invocation layer on Apple devices, turning every app into a capability that agents call rather than a screen you tap. The app is drifting away from being a place you visit and becoming something that acts on your behalf.
The “Everyone Is a Developer Now” Problem
More people can generate working code than ever before. Anyone can vibe-code a prototype or a simple internal tool in an afternoon. That part is real and a great step forward.
The illusion is believing that generating code and operating software are the same thing. The difficult parts of software are maintenance, security, permissions, integration sprawl, testing, and compliance. The prototype works on day one. The question is whether it still works on day 300 when three integrations have changed their APIs, a dependency has a CVE, and nobody remembers why that one function exists.
For many use cases, this doesn’t matter. A quick script that reformats a CSV doesn’t need a maintenance plan. But the moment something touches production data, runs on a schedule, or has users other than you, you’re back in engineering territory.
If anything, the rise of agents increases the premium on real engineering. The surface area expands. The blast radius grows. The difference between generating code and operating software gets painfully clear at scale. Because of that, most of us understand that software engineering is changing. We also need to think about how software itself is changing.
Skill-Based Apps
An app can now be a skill bundle installed into an assistant. Consider Claude Code custom commands: a system prompt, a curated set of tools, and rule files that encode conventions about how a codebase or organization works. No dedicated UI at all. The assistant is the platform. The app is the capability injected into it.
A team might package their deployment process as a set of instructions, tool permissions, and guardrails that any team member can invoke by typing a command. Rule files and context scoping aren’t documentation afterthoughts. They are product features. They shape behavior just as much as source code.
Agent-Native Apps
Some systems are agent-native. They have an agent core and a thin control surface. Think of Devin, or Claude Code/CoWork itself, or OpenClaw type systems. The UI exists to show logs, diffs, statuses, test results, and retry controls. It is a control plane. You’re supervising behavior rather than clicking through screens. The experience shifts from interaction to orchestration.
Security becomes intrinsic here. Where can the agent act? What credentials does it hold? What data can it access? Is it isolated from production? An agent-native app is defined as much by its constraints and blast radius as by its features. The execution environment a core product design attribute not just incidental.
Workflow Apps
Other systems interleave deterministic steps with autonomous reasoning. Picture a CI pipeline that doesn’t just run your test suite but interprets a failing test, patches the code, re-runs the affected tests, applies formatting fixes, and produces a clean PR. Or a dev-loop that runs linting before burning tokens on expensive model calls.
Some of those steps are pure code and must always run. Others benefit from model reasoning. Deterministic steps enforce invariants. Agents handle ambiguity and synthesis. The app becomes a state machine that blends strict rules with flexible intelligence.
Validation matters here in a way it didn’t before. Every retry consumes compute and time. Cheap checks should run before expensive ones. The feedback loop architecture is part of the product definition, not invisible infrastructure.
Meta-Apps
As tool counts grow, a new category emerges. When an agent can call dozens or hundreds of tools, you need discovery, curation, permissioning, and governance. You need something that decides which tools are visible in which contexts.
Anthropic’s tool registry for MCP is an early example. So are internal platform teams building capability layers for their AI-assisted workflows. The product is a harness. A registry. An orchestration layer that coordinates other capabilities. These layer is not just ‘infrastructure’ but an actual app to build and run apps.
In-Loop and Out-of-Loop
There is a shift in how you relate to the software you build and the software you use. In-loop systems keep you tightly engaged. You prompt, the model responds, you refine. Most of us work this way with AI tools today.
Out-of-loop systems let you define a task, walk away, and review the result later. One developer can kick off five parallel agents: one refactoring a module, one writing tests, one investigating a bug, one drafting docs, one researching a library migration. You come back and review the outputs.
This changes what an app needs to provide. Out-of-loop apps need good status reporting, clear audit trails, bounded retry budgets, and meaningful diffs. The interface shifts from “workspace you inhabit” to “dashboard you check.” The scarce resource is your attention and judgment about which results to accept, reject, or redirect.
If you manage developers, this is the transition to understand. Productivity stops looking like hours-at-keyboard and starts looking like tasks-defined-and-reviewed.
A Better Definition
An app is no longer just a binary or a website. It is a packaged capability that includes an invocation surface, an execution environment, access to tools and data, context and rules, guardrails and validation, and some form of review or control interface.
It might run locally, in the cloud, inside an assistant or some combination of all of these. But it owns a responsibility and produces outcomes over time.
Where This Leaves Us
The leverage in software is shifting from writing lines of code to designing harnesses, workflows, guardrails, and capability layers. We are moving from apps as destinations to apps as capabilities embedded in systems. The sooner your team updates its mental model, the sooner you can make good decisions about what to build, what to buy, and what to let an agent handle.