The AI Software Factory needs an operating system for everything it creates

Anthropic's AI-Native SDLC Playbook lays out six stages: Plan, Design, Build, Test, Deploy, and Maintain.

It's a useful frame for what changes when agents become real contributors. Intent becomes a versioned artifact. Agents turn it into a design and a plan, write the code, run the tests, review the results, and move it toward production. Human attention shifts to the decision and approval points where judgment still matters.

The six stages look equal in the diagram. They aren't.

Plan, Design, Build, Test, and Deploy all happen around a change. A complicated change might take weeks, a review a few hours, a deployment minutes. Each of them ends.

Maintain starts when the software survives the other five. It can run for the next 10 or 15 years.

Maintain inherits everything the other stages produce

Every pass through the first five stages adds something to the stack. A service, a feature, an API, a database, a workflow, an agent. It reaches production and joins everything already there.

From that point on, the company owns it.

The software keeps running while the world around it moves. Versions age. Dependencies shift. APIs change underneath you. Support windows close. Teams reorganize, and the ownership that was obvious at launch takes actual archaeology to reconstruct three years later.

None of this needs a new product decision. It happens even if nobody touches the code.

Which is why Maintain can't be the last task in a delivery pipeline. The first five stages handle one change. Maintain accumulates the output of every change that ever made it through.

And the better the factory gets, the heavier that side of the ledger gets. Companies won't use a 5x or 10x jump in creation capacity to build the same software faster. The bar for what's worth building drops. More internal tools, more integrations, more narrow services, more infrastructure holding it all together.

An agent can create one of those systems in an afternoon. The company might operate it for a decade. The creation cost happened once. The maintenance obligation starts immediately and doesn't stop until the thing is turned off.

Most of the stack never went through the factory

Even that undersells Maintain, because companies are on the hook for far more than the software they write.

A real stack is assembled: internal code, open source, cloud infrastructure, managed databases, runtimes, libraries, container images, third-party APIs, SaaS platforms, models, agents, and whatever arrived through years of growth and acquisitions. The company didn't write most of it. It doesn't control the roadmap, the release schedule, or the support policy behind any of it.

It owns the consequences anyway.

A maintainer ships a breaking major. A cloud provider changes a service or ends support for one. An API introduces a new contract. A runtime ages out. A managed platform changes its pricing or its operating model. An internal standard moves because the business, the regulator, or the security posture moved.

None of these events happened inside the company's software factory. The work they create lands inside it all the same.

So autonomous Maintain has to cover two different categories at once: technology the company created, and technology it merely chose to depend on.

The AI-native SDLC can give an agent excellent context about a repository and the change being made in it. Maintenance needs a working model of the entire stack, including the parts that don't live in a repository at all. What's actually running. Where. What depends on it. Who owns it now. Which policies apply. What's changing around it, and how long the company has to respond.

That model can't be rebuilt from scratch every time a ticket shows up. It has to stay current on its own.

Autonomous execution doesn't make Maintain autonomous

Anthropic describes Maintain as the stage where the loop can start without a person invoking Claude. A trigger kicks off an investigation, Claude diagnoses what happened, new intent gets created, and the work moves back through the SDLC.

That's real progress. It also starts after something became a trigger.

A large part of maintenance exists before there's a ticket, an alert, an incident, or a carefully written task. It exists because the stack changed, the world around it changed, or the relationship between the two changed.

Detection isn't the hard part. Large companies already own plenty of products that produce findings, alerts, lifecycle notices, and inventory records. The hard part is turning that pile into the right maintenance decisions.

A lifecycle change can touch thousands of components without being thousands of independent tasks. Some of those systems will be gone before action is needed. Some move together. Some are blocked on prerequisite work owned by another team. The same technical fact can be urgent in one part of the company and irrelevant in another.

A finding says something is true. A maintenance decision says whether the company should act, when, toward what target state, what has to move first, and what outcome proves the obligation is gone.

By the time a coding agent receives a clean task with the right scope, repo, constraints, and tests, most of the hard work already happened. Someone decided this was the right change, on the right systems, at the right time.

Agents will get much better at making those changes. That makes the deciding system more important, not less. When execution is cheap, a bad maintenance decision propagates across hundreds of systems exactly as fast as a good one.

Maintain needs an operating system, not another queue

Making Maintain autonomous means something has to carry responsibility for the state of the stack over time.

It has to hold a current model of what the company runs, wired to dependencies, ownership, usage, policies, external technology changes, and business context. From there it can see where the current state is drifting away from the state the company needs.

Still not enough. It then has to decide what matters now, group related obligations into coherent programs of work instead of ticket confetti, respect dependencies and sequencing, and pick the execution path. Some work goes to an engineer with the investigation already done. Some arrives as a ready-to-review pull request. Some goes to an engineering agent the company already trusts. A smaller set of well-understood changes runs automatically inside predefined boundaries.

All of those will coexist in the same enterprise. The right level of autonomy depends on the system, the change, the environment, and how much the company trusts the result. The executor varies. Responsibility for the outcome doesn't.

And it doesn't end at merge. Maintenance is about the state of the real environment, so the system has to check that the expected change actually happened, that every affected part of the stack reached the target state, and that nothing else broke along the way.

Otherwise the company has automated activity, not maintenance.

That's a much bigger role than parking an agent at the end of a backlog. It's the operating system that continuously turns change across the technology estate into maintenance decisions the company can defend and outcomes it can verify.

This is what we mean by MaintenanceOS

At Draftt, we're building MaintenanceOS as the system responsible for the state and evolution of the enterprise tech stack.

It covers software written by people, software written by agents, and technology the company never wrote but depends on anyway. It continuously understands what exists, what's changing, what needs attention now, and what has to happen next.

From there it coordinates the right execution path. Draftt may make the change. An engineer may own it. The work may go to Claude, Devin, an internal engineering agent, or whichever executor fits the task.

We expect enterprises to run many engineering agents. They'll be good at different things, and they'll keep improving. MaintenanceOS gives them the thing they don't have on their own: enterprise-wide understanding of what maintenance should happen, why it matters, what it affects, which constraints apply, and what result has to be verified.

The coding agent is part of the execution layer. MaintenanceOS decides what work belongs in that layer and carries the obligation until the stack is actually where it needs to be.

Maintain is not simply Stage 6

Anthropic is right to put Maintain inside the AI-native SDLC, and right that it's the stage that closes the loop.

The next step is recognizing the six stages aren't born equal. Five of them operate around individual changes. Maintain outlives every one of those changes and inherits all of their output, plus the cloud infrastructure, open source, dependencies, APIs, and platforms that never passed through the SDLC in the first place.

As the factory speeds up, that responsibility compounds. More software enters production, more technology gets pulled in to support it, and more of the stack changes on timelines the company doesn't control. The answer can't be a proportional increase in dashboards, findings, tickets, migration projects, and people manually connecting the dots.

The AI Software Factory needs an operating system for everything it creates and everything it depends on. That's MaintenanceOS: the permanent system responsible for keeping the tech stack in the state the company needs, for as long as the company owns it.

The AI-native SDLC changes how software gets built. MaintenanceOS takes responsibility for the much longer period after it ships, so the stack can increasingly maintain itself.