Living software is software that continues to adapt, remember, and act after it is deployed. Where traditional software is frozen at release — changing only when a developer ships an update — living software stays connected to persistent memory, reasoning agents, and scheduled execution, so its behavior keeps evolving in response to goals, data, and events. The term entered formal use in an August 2024 research paper by Jules White of Vanderbilt University (arXiv:2408.01768) and became a recognized category label across analyst, editorial, and product writing in 2025–2026. Taskade Genesis is the first workspace platform built around it as a product category, with 150,000+ apps where projects remember, agents reason, and workflows run.
TL;DR: Living software adapts, remembers, and acts after deployment; static software is frozen at release. The term was formalized in an August 2024 Vanderbilt paper, popularized across 2026 analyst and editorial writing, and applied at scale by Taskade Genesis — 150,000+ living apps coordinated by TSK-1, the Taskade System Kernel.
What Is Living Software?
Living software is an application that treats deployment as the beginning of its life rather than the end. As of July 2026, the term describes systems with three properties that static software lacks: persistent memory (the system retains state, context, and learned behavior across sessions), embedded intelligence (AI agents reason over that memory to decide what should happen next), and continuous execution (workflows act on triggers and schedules without a human redeploying anything). A conventional application does exactly what it was programmed to do until someone ships a new version; a living system narrows the gap between what its owner wants and what it currently does, on its own.
The contrast has been drawn several ways by different authors. Jules White's founding paper frames it as goal-to-action translation: instead of developers hard-coding every behavior in advance, agentic AI decomposes natural-language goals into concrete actions — API calls, data operations, workflow steps — at runtime. Writer Jack Cheng, in the most-read editorial treatment (Every, April 2026), contrasts "living" software with "tool-like" software: a tool waits inertly for a skilled operator, while a living system participates in the work. Product manifestos such as Aaron White's living.software draw the line as "dead software vs living software" — fixed feature sets versus goal-oriented adaptation.
Disambiguation
"Living software" as defined here should not be confused with several similarly named things that share its search results: assisted-living and senior-living management software (care-facility tools such as scheduling and EHR systems, unrelated to this concept), Living Software, Inc. (an unrelated company name), or artificial life and self-modifying code — older computer-science lineages in which programs literally rewrite their own instructions, a mechanism living software may use but does not require. The nearest academic ancestor is the field of self-adaptive systems, discussed under Origins below.
Origins & Sources
The term has a traceable lineage from pre-LLM academic work through a 2024 research paper to mainstream 2026 usage. The provenance, with dates:
- Philosophical epigraph — Alan Watts: "the more a thing tends to be permanent, the more it tends to be lifeless." White's 2024 paper opens with this line, framing permanence — the defining virtue of shipped software for seventy years — as the property to overcome.
- 2012 — Research on self-adaptive systems formalizes software that modifies its own behavior in response to its environment, including multi-level reference models for adaptation logic (arXiv:1209.1628). The concept of software that changes itself predates large language models by more than a decade; what was missing was a general mechanism.
- August 2024 — Jules White (Vanderbilt University) publishes "Building Living Software Systems with Generative & Agentic AI" (arXiv:2408.01768) — the earliest formal use of the term in its current sense. White defines living software systems as adaptive, context-aware systems powered by generative AI that dynamically evolve to meet user goals, with agentic AI translating goals into API-level actions.
- 2025 — Vendor and product usage emerges. Aaron White's "Living Software: a Manifesto" sets out six principles (goal-oriented reasoning, adaptive execution, fluid interfaces, personalization, continuous improvement, proactive anticipation). In November, the Live-SWE-agent paper (arXiv:2511.13646) demonstrates a software agent that autonomously evolves its own implementation at runtime while solving real-world software problems.
- October 13, 2025 — Taskade launches Taskade Genesis with The Origin of Living Software, applying the idea to the workspace: projects become memory, agents become intelligence, automations become execution.
- January 2026 — 2025 in Review: The Year of Living Software marks the first full year of the category in production, with the app count crossing six figures.
- March 2026 — Analyst adoption. Peter Bendor-Samuel (Everest Group) describes enterprise software becoming "living systems" that evolve through constantly ingested data and tribal knowledge, naming "systems of work" as the third era after systems of record and systems of engagement (Forbes, March 20, 2026).
- April 17, 2026 — Editorial popularization. Jack Cheng's "Living Software" essay in Every contrasts living with tool-like software and notes the compression of software evolution: the jump from MS-DOS to Windows 3.0 took nine years, while AI products now ship comparable behavioral shifts in weeks.
- July 2026 — Introducing TSK-1 names the kernel that coordinates living software at scale in Taskade.
| Date | Work | Contribution to the term |
|---|---|---|
| 2012 | Self-adaptive systems reference model (arXiv:1209.1628) | Pre-AI ancestor: software that adapts its own behavior |
| Aug 2024 | Jules White, Vanderbilt (arXiv:2408.01768) | Earliest formal definition; goal-to-action translation via agentic AI |
| 2025 | living.software manifesto | Six principles; "dead vs living software" framing |
| Oct 2025 | Taskade Genesis launch | First workspace platform built around the category |
| Nov 2025 | Live-SWE-agent (arXiv:2511.13646) | Working demonstration of self-evolving software |
| Mar 2026 | Bendor-Samuel, Forbes | Analyst framing: "systems of work" as the third era |
| Apr 2026 | Jack Cheng, Every | Editorial popularization; living vs tool-like software |
How Is Living Software Different From Traditional Software?
The defining difference is what happens after release. Traditional software — whether hand-coded, low-code, or AI-generated — ships as a static artifact: its behavior is fixed until a person changes it. Living software ships as a running system: it holds state, watches for events, and adjusts behavior without a redeployment cycle. Both can receive updates; only one changes itself between updates.
The same drift is visible as a state machine. A static app's natural trajectory after launch is decay — credentials expire, APIs change, data outgrows assumptions — a failure pattern examined in detail in why AI-generated apps break:
Jack Cheng's living-vs-tool-like distinction covers the interaction side of the same divide:
| Dimension | Tool-like software | Living software |
|---|---|---|
| Posture | Waits for a skilled operator | Participates in the work |
| State | Forgets between sessions | Remembers across sessions |
| Change | New version ships new behavior | Behavior evolves between versions |
| Interface | Fixed menus and screens | Conversation, goals, adaptive views |
| Failure mode | Does nothing wrong or right on its own | Can act wrongly on its own — needs oversight |
The last row is worth keeping honest: agency cuts both ways, which is why living software raises governance questions static software never did (see Criticism and Limits).
What Is the Difference Between Living Software and SaaS?
SaaS is a delivery and business model — centrally hosted software sold by subscription — while living software is a behavioral model, so the two are not strict opposites; a living system can be sold as SaaS. In practice, though, the term is used to mark a generational break, because most SaaS products are static: hundreds of separate tools, each holding its own copy of a company's data, each changing only when its vendor ships an update. Everest Group's Peter Bendor-Samuel frames the shift as a third era of enterprise software:
| Systems of record (~1990s–2000s) | Systems of engagement (~2010s) | Systems of work (2020s→) | |
|---|---|---|---|
| Primary job | Store transactions | Connect people to data | Do the work |
| Example shape | ERP, CRM databases | SaaS web and mobile apps | Agent-run living systems |
| Change mechanism | IT release cycles | Vendor update cycles | Continuous adaptation |
| Knowledge | Schemas | Dashboards | Evolving memory and context |
| Human role | Data entry | Operator | Goal-setter and reviewer |
The economic backdrop makes the debate concrete. As of 2026, large enterprises run an average of 600+ SaaS applications and spend roughly $280M a year on them, and roughly $300B in public SaaS market value was wiped out as shares fell heading into February 2026 on AI-disruption fears (CIO.com, March 2026); the median EV/revenue multiple for public SaaS companies fell to about 5.1x by December 2025, down from a pandemic-era peak of 18–19x (UncoverAlpha). Microsoft CEO Satya Nadella has argued that business applications are "essentially CRUD databases with business logic," that "the business logic is all going to these agents," and that the very notion of discrete applications may collapse (Windows Central).
None of this means SaaS disappears — subscription delivery is likely to persist — but it explains why "living software" emerged as a label: it names what the surviving software is expected to do differently. The full debate is covered in Will vibe coding kill SaaS? and the living software era.
How Does Living Software Work?
The core mechanism, per White's 2024 paper, is goal-to-action translation: a user states an outcome in natural language, and an agent layer decomposes it into concrete operations — API calls, data reads and writes, workflow steps — executed against live systems, with results written back to persistent memory so the next decision starts from updated state. Three capabilities have to be present at once:
- Persistent memory — the system's own state, records, and accumulated context survive between sessions, forming the substrate agents reason over (see agent memory).
- Agentic reasoning — one or more AI agents plan against goals rather than executing fixed scripts, including multi-agent coordination for larger tasks.
- Autonomous execution — automations fire on schedules and triggers, so action does not depend on a human being present.
At the research frontier, the loop extends to the software's own implementation: Live-SWE-agent (arXiv:2511.13646, November 2025) is a software agent that autonomously evolves its own scaffolding at runtime while solving real-world software problems — a working instance of software improving itself in production rather than between releases. Related mechanisms in agent systems include self-monitoring of goals and learning loops.
What Are Real Examples of Living Software?
As of July 2026, examples span vehicles, developer tooling, and end-user applications. Each illustrates a different slice of the definition — continuous updating, self-evolution, or post-creation persistence:
| Example | Domain | What stays alive | Source |
|---|---|---|---|
| Volvo Trucks OTA program | Vehicles | Fleet software updates itself by default; trucks on latest software rose from 25% to 80%+ in six months, with under 1% of customers opting out | Volvo Trucks, Mar 2026 |
| Live-SWE-agent | Research | The agent's own implementation evolves at runtime | arXiv:2511.13646 |
| AI app generators | App building | Creation is continuous and conversational; Lovable hit a $500M annualized revenue run rate in June 2026 and reportedly entered talks at a $13.2B valuation | TechCrunch, Jul 2026 |
| Taskade Genesis apps | Workspaces | Memory, agents, and automations keep running after the prompt ends — 150,000+ apps | Community gallery |
The scale of the adjacent generation wave matters for context: 25% of Y Combinator's Winter 2025 startups had codebases that were 95%+ AI-generated (per YC's Jared Friedman). Generation, however, is only the first half of the definition — a generated app is not living unless something keeps running it afterward, the gap analyzed in why AI-generated apps break and surveyed across tools in free AI app builders.
How Living Software Works in Taskade
Taskade Genesis implements living software through Workspace DNA — three parts that map directly onto the definition's three requirements:
- Projects are Memory ▲ — data, records, and context persist in connected projects that form a single memory graph.
- Agents are Intelligence ■ — AI agents and multi-agent teams reason over that memory and decide what happens next.
- Workflows are Execution ● — automations act on those decisions, on triggers and schedules, long after the chat ends.
Coordinating all three is TSK-1, the Taskade System Kernel — the intelligence layer that coordinates models, memory, agents, and workflows into a running AI workspace. TSK-1 is a kernel, not a model: it sits above 15+ frontier models from OpenAI, Anthropic, Google, and open-weight providers, and keeps the whole system turning. You describe what you want to Taskade EVE, and the kernel runs the Taskade Genesis loop: memory feeds intelligence, intelligence triggers execution, execution updates memory.
The distinguishing design decision is scope of memory. Most modern platforms have memory features — an app builder can attach a memory document to an assistant; an automation platform can run scheduled jobs. That memory lives per app or per agent. Taskade runs one shared memory across every app, agent, and automation in the workspace, so the whole system reads and writes the same living context — and reaches outward through 100+ bidirectional integrations.
| Capability | Generated software (typical) | Living software (Taskade) |
|---|---|---|
| Memory | Per-app or per-agent: memory documents, assistant threads | One shared memory across apps, agents, and automations |
| Intelligence | A single assistant responds when asked | Multi-agent teams reason over shared, living context |
| Execution | Scheduled jobs configured per workflow | Workflows fire from the same shared state the agents read |
| Changes | Edit code or config, then redeploy | Describe the change in chat; the running app updates |
In practice: a non-technical operations manager describes a client dashboard in one prompt and shares the link the same day. A week later, the app has remembered every record entered since launch, agents post an end-of-day summary of open work, and automations have sent the week's invoices — with nothing redeployed. That is the difference between a generated artifact and a living dashboard; building this way is what vibe coding grows into when the output stays alive. A step-by-step walkthrough is in Learn Taskade.
Related Terms
Living software sits inside a cluster of adjacent 2020s concepts, most with their own wiki entries:
| Term | Relationship to living software |
|---|---|
| Agentic AI | The mechanism: agents that plan and act toward goals power living systems |
| Self-adaptive systems | Pre-AI academic ancestor; adaptation logic without LLM reasoning |
| Self-modifying code | Older, narrower: programs rewriting instructions; a possible mechanism, not a requirement |
| Vibe coding | The creation method — conversational building; living software is what the output becomes if it persists |
| Autonomous apps | Application-level framing of the same idea |
| Autonomous workflows | The execution layer viewed on its own |
| Agentic workspaces | The environment-level framing: the workspace as the runtime |
| Auto-updating software (OTA) | Necessary infrastructure, not sufficient: updates flow automatically, but behavior between updates is still fixed |
Criticism and Limits
Living software inherits the open problems of agentic AI, and a neutral account has to include them. Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls; the same research estimated that only about 130 of the thousands of vendors claiming agentic capability were substantively real, a pattern Gartner calls "agent washing" (Gartner press release, June 25, 2025; the figure was still being debated in Forbes as of July 2026). Gartner's forward estimate on the other side of the ledger: 15% of day-to-day work decisions made autonomously by 2028, up from 0% in 2024.
| Concern | Evidence | Implication |
|---|---|---|
| Project failure risk | 40%+ of agentic AI projects predicted canceled by end-2027 (Gartner) | Adaptivity alone is not business value |
| Agent washing | ~130 real agentic vendors of thousands claiming (Gartner) | Category label outpaces category substance |
| Trust gap | Developer trust in AI code accuracy fell from ~40% in 2024 to ~29% in 2025, even as daily AI use became the norm (survey aggregate) | Human review remains load-bearing |
| Accountability | Software that acts can act wrongly | Living systems need audit trails and human-in-the-loop controls |
Two structural criticisms recur. First, autonomy without accountability: a system that changes its own behavior needs observability, permissions, and rollback that static software never required — the governance surface grows with the agency. Second, definitional inflation: because "living" is evocative, vendors apply it to anything with an AI feature; the useful test is whether the system's behavior tomorrow depends on what it did and learned today, without a human shipping the change.
Frequently Asked Questions About Living Software
What is living software?
Living software is software that continues to adapt, remember, and act after it is deployed. It combines persistent memory, AI agents that reason over that memory, and workflows that execute on triggers and schedules — so behavior keeps evolving between releases, instead of being frozen at release the way static software is.
Who coined the term living software?
The earliest formal use in the current sense is Jules White of Vanderbilt University, in the August 2024 paper "Building Living Software Systems with Generative & Agentic AI" (arXiv:2408.01768). The underlying idea traces to self-adaptive systems research from the early 2010s, and the term spread through vendor manifestos, analyst writing, and editorial essays across 2025–2026. Taskade did not coin the term — it is the first workspace platform built around it as a product category, starting with the Taskade Genesis launch in October 2025.
What is the difference between living software and SaaS?
SaaS is a delivery model — centrally hosted software sold by subscription — while living software is a behavioral model describing what the software does after deployment. A living system can be delivered as SaaS. The contrast people usually mean is static SaaS (fixed behavior, vendor update cycles) versus systems that adapt continuously through memory, agents, and automation.
Is living software the same as AI agents?
No. AI agents are a component; living software is the whole system. An agent reasons and acts toward goals, but a living system also requires persistent memory for the agent to reason over and an execution layer that keeps acting on triggers and schedules. Agents without memory and execution are a chat feature, not living software.
How is living software different from automatic software updates?
Automatic updates (such as over-the-air updates in vehicles) change software without user action, but between updates the behavior is still fixed by the vendor. Living software changes its own behavior between updates, based on its memory, goals, and events. OTA infrastructure is a building block — Volvo Trucks moved its fleet from 25% to 80%+ on latest software in six months — but auto-updating alone does not make software living.
What is an example of living software?
A Taskade Genesis app is a working example: one prompt creates a live app whose projects keep remembering data, whose agents post summaries and make decisions, and whose automations send messages and update records on schedule — with no redeployment. Research examples include Live-SWE-agent (arXiv:2511.13646), a software agent that evolves its own implementation at runtime.
What is the difference between living software and vibe coding?
Vibe coding describes how software gets created — describing outcomes in natural language and letting AI produce the implementation. Living software describes what the result is if it keeps running afterward. A vibe-coded app that ships as a static artifact is generated software; it becomes living software only when memory, agents, and execution stay attached after creation.
Do AI-generated apps keep working after they are built?
Only if something keeps running them. Generated code with no runtime decays: API tokens expire, dependencies break, webhooks fail silently, and data outgrows assumptions. This is the most common failure mode of the app-generation wave. Living software addresses it by making the workspace itself the runtime, so the app's memory, agents, and automations stay active after the build.
What are the risks of self-updating software?
The main risks are unaccountable action (a system that changes its own behavior can change it wrongly), cost and value drift (Gartner predicts over 40% of agentic AI projects will be canceled by end-2027), and inflated claims ("agent washing" — only about 130 of thousands of self-described agentic vendors were substantively real per Gartner). Mature living systems mitigate these with audit trails, permissions, and human-in-the-loop review.
Can non-technical people run living software?
Yes — that is much of the point. Because the interface is natural language, an operations manager or founder can describe an app, refine it in conversation, and let the system handle memory, reasoning, and execution. In Taskade Genesis, one prompt creates the app and follow-up chat updates the running system, with no code, hosting, or deployment pipeline to manage.
What are self-adaptive systems?
Self-adaptive systems are the academic ancestor of living software: software engineered to monitor its environment and modify its own behavior in response, formalized in research such as the multi-level adaptation reference model (arXiv:1209.1628, 2012). They predate large language models; agentic AI supplied the general-purpose reasoning that earlier adaptation logic lacked.
How much does it cost to build living software?
In Taskade, a living app can be built free. Paid plans start at $10/month for Pro with annual billing, and every plan includes the same core loop — projects, agents, and automations — so cost scales with team size and usage rather than with the capability to build.
Learn More
- TSK-1 (Taskade System Kernel), the kernel that coordinates living software
- Workspace DNA, memory, intelligence, and execution
- The Taskade Genesis Loop, how one prompt becomes a running system
- The Living Trinity, projects, agents, and workflows as one organism
- Taskade EVE, the shell you talk to
- The App Builder and the Taskade Genesis wiki for the full category map
Ready to build software that stays alive? Start with a prompt or clone a live app.