We've been hearing the phrase "Post-Software" start to surface in conversations with technology leaders. It sounds like the kind of thing someone says right before announcing the robots have won. But the people using it aren't being dramatic. They are trying to frame a vision of the future that is, as yet, uncertain.

We think it's one of the most important strategic concepts technology leaders need to grapple with soon. So here's our attempt to articulate it.

The companies that win the next five years won't be the ones that built the most software. They'll be the ones that will have delivered better sustainable outcomes.

The Problem With Software

Software exists to get computers to do things humans want them to do. For decades, it was the only mechanism available. Building it properly was expensive. Maintaining it as needs change was and is expensive. Customising it to fit the specific, idiosyncratic way a particular team actually works? That's expensive too. Usually too expensive to justify.

So the compromise became the norm. Instead of fitting the right software to the process, organisations fit a compromised process to the software. SaaS is the embodiment of this. It effectively locked organisations into someone else's workflow logic.

The results are familiar. Teams fighting systems that don't reflect how they actually work. Processes quietly distorted to satisfy software constraints, not business goals. And hundreds of small compromises, made invisibly, that collectively re-define how an organisation operated.

What's Coming Next?

At first, Generative AI initially looked like a solution to this. If software becomes cheaper to build, more organisations can afford bespoke tools. And that's true. To a point. But it's still thinking in software terms. It's still asking: how do we use AI to produce better, fastersoftware?

The instinct to use AI as a faster path to software is understandable. We have a new capability so we map it onto the problems we already know how to frame. The trouble is, however, that agentic AI doesn't just accelerate software production. It makes software optional.

An agent doesn't need a fixed, deterministic set of instructions to do useful work. It can reason about a task, call tools, loop until it achieves the right result, and record what it learned. When a precise outcome is required, it can write the software to do that precisely. But the output of the overall process isn't software. Software is just one component. The rest is reasoning, tooling, data, communication, and accumulated learning.

This is the shift that many AI strategies are missing: the unit of value is no longer the application. It's the capability the organisation has built to do a particular thing well.

In the old world, a company looking to move faster would source software that fits its needs. In the new world, someone builds an agent by assembling a mix of skills, harnesses, data pipelines, and decision logic to achieve a business outcome. It's not an app. It's not a just workflow. It is an ability. It's an outcome the organisation has built the ability to deliver.

And what this means is that engineering is no longer just a software question. It's an operating model question. The organisations that will fall behind are the ones applying AI within the existing software paradigm: running point-solution pilots, measuring individual ROI in isolation, and treating each agent or automation as a standalone tool rather than a contribution to something larger.

The organisations that pull ahead will be the ones that ask a different question from the outset: what ability or outcome are we trying to achieve? It's not "does a tool solve a problem," but "does it improve us?"

So What Does This Mean in Practice?

This doesn't mean software disappears. It means software becomes one tool among many, and the question "should we build or buy software?" gets replaced by a broader one: "what does our organisation need to be capable of, and what's the right combination of agents, data, tooling, and process to get there?"

That's a harder question. It requires a different kind of thinking than traditional software procurement or even DevOps transformation. It requires technology leaders to reason about operating models, not just technology stacks. Not about which AI tools to adopt, but about how to build the operating model that makes those tools compound into something durable.

If you're working through what this shift looks like for your organisation — or if you think we've got it wrong — we'd genuinely like to hear from you.