The Future of Enterprise Software

How AI Brings Back the Systems-Engineering Discipline – and Decentralisation Makes It Provable

Published by Polity | July 2026
Authors: Alexandre Kotcherguine, Vision Officer & Investor, Polity;
Kevin Riedl, Managing Partner, Wavect GmbH

This article concerns enterprise-software architecture and engineering methodology. It draws on the public record, including peer-reviewed and pre-print research, industry surveys, and vendor and practitioner reporting current to mid-2026. Several of the technologies discussed are early in their maturity curve; claims about them are characterised accordingly. Figures from a fast-moving field are snapshots and may be restated. Nothing in it constitutes professional, legal or investment advice.

Executive Summary

For two decades, enterprise software pursued agility by breaking things apart. The monolith was decomposed into microservices; the suite was unbundled into a sprawl of SaaS; delivery was accelerated until the architecture that held it all together quietly dissolved. The promised agility often arrived as its opposite – the distributed monolith, a system with all the coupling of the old world and none of its coherence, in which no one owns the whole and every change is a coordination exercise. What was lost in the fragmentation was systems engineering: the discipline of treating the whole as the object of design, with explicit requirements, governed interfaces, architectural integrity and verification against intent. This article argues that the next phase reverses the trend on two fronts at once. First, AI makes the systems-engineering approach affordable again at scale. It extends the governed, specification-first “software factory” from code to whole-system architecture, so that intent can once more be captured, modelled and enforced rather than left to erode. Second, and more consequentially, decentralisation hardens the result: it moves the system’s guarantees from trusted to verifiable – from contracts documented on paper and backed by an organisation’s word, to contracts enforced by cryptographic proof, on-chain attestation and distributed control that no single party can silently override. The factory builds the system; the chain proves it behaves. The honest caveats are given in full: verifiable computation remains far more expensive than execution, it arrives first in high-stakes, low-volume settings rather than everywhere at once, and for much of an enterprise’s interior the institutional trust it already runs on remains the right tool. The case made here is not that cryptographic proof replaces audits and contracts, but that it extends assurance across the boundaries those instruments cannot reach. But the direction is clear, and it lands on familiar ground: regulated on-chain finance, the domain in which Polity works, is precisely where provable architecture is demanded first and adopted soonest.

The Age of Fragmentation

The dominant enterprise-architecture movement of the 2010s had a clear and largely sound motivation. Monoliths had grown into “big balls of mud” – tightly coupled, hard to change, slow to deploy – and microservices promised an escape: decompose the application around business capabilities, give each service an independent deployment, and let teams move in parallel. For many organisations, at first, it worked. But the pattern was widely adopted as a default rather than a considered trade, and the result, repeated across the industry, was a characteristic failure mode that practitioners came to name precisely. The “distributed monolith” has, in one widely cited description, the operational complexity of microservices without the architectural independence: services separated physically but coupled logically, depending on one another’s database schemas, requiring synchronised deployments, calling each other in long chains, so that a change in one breaks three others and every release is a coordination exercise (1). The organisation gained more repositories, more pipelines, more logs, more failure modes and more governance overhead – without gaining the ability to move faster.

By the middle of this decade the correction was visible in the data, not merely the trade press. The Cloud Native Computing Foundation’s 2024 Cloud Native Survey of 689 technical decision-makers found that 42 per cent of organisations which had adopted microservices were consolidating services back toward larger deployable units, while adoption of the service mesh – the infrastructure that made microservices tractable at scale – fell from 18 to 8 per cent (2). This was not a wholesale repudiation of distribution; cloud-native adoption overall remained near ninety per cent. It was a correction of premature adoption, and the consolidating teams moved back toward modular monoliths – single deployments with disciplined internal boundaries – reporting substantial reductions in cost and deployment time. Amazon’s own Prime Video team had set the template, reporting an infrastructure-cost reduction of around ninety per cent for one monitoring workload by collapsing a microservices pipeline back into a monolith; the company’s chief technology officer drew the moral plainly, that building evolvable systems is a strategy, not a religion. The lesson drawn was not that distribution is wrong but that it is a destination, not a starting point, and that its benefits are available only to those who maintain the discipline it demands: owned interfaces, versioned contracts, enforced boundaries. That clause – only to those who maintain the discipline – is the whole story. Fragmentation did not fail because decomposition is a bad idea. It failed because decomposition without systems engineering is just entropy with extra steps.

What Was Lost: Systems Engineering

Systems engineering is the older discipline that fragmentation displaced. It treats the system as a whole – not a collection of independently optimised parts – as the primary object of design. Its instruments are requirements that capture intent before construction, interface contracts that govern how parts interact, architectural models that make the whole legible, and verification that checks the built system against what was specified. These are unglamorous practices, and the move-fast culture of the fragmentation era treated them as bureaucratic drag, to be shed in the name of velocity. The irony, familiar from the earlier history of enterprise Agile, is that shedding the discipline did not produce lasting speed; it produced systems that became slower and more brittle precisely because no one was tending the whole.

There is a reason the discipline was abandoned rather than merely neglected: at the scale and pace of modern software, doing systems engineering by hand was genuinely unaffordable. Keeping an accurate, current model of a large system – its components, dependencies, contracts and constraints – was a labour-intensive task that fell out of date faster than humans could maintain it. Model-based systems engineering, the formal discipline of building and reasoning over such models, has long been recognised as powerful and, in the same breath, as too heavy for most organisations to sustain. The whole-system view was a luxury good. So teams stopped buying it, and architecture decayed into whatever the running services happened to be.

Why AI Brings the Discipline Back

The argument of this series’ previous instalment was that AI does not abolish engineering discipline but relocates it – up the stack, from the keystroke to the specification – and that the governed “software factory” works precisely when craft is embedded in the pipeline rather than dispensed with (3). Extend that one level further and the same logic applies to architecture. What made systems engineering unaffordable was the human cost of building and maintaining the whole-system model and of keeping intent, specification and implementation in alignment. That cost is exactly what AI collapses. Large models can now parse vast legacy codebases and extract their implicit business rules and intent into human-readable requirements – turning modernisation from a risky salvage operation into a tractable design problem. The systems-engineering community has begun, in turn, to build AI co-pilots for model-based systems engineering itself, to lower the barrier that kept the discipline out of reach (4).

The result is that the whole-system view stops being a luxury good. A living, versioned specification – the same artefact that disciplines the agentic code factory – becomes the architecture’s source of truth, continuously reconciled against the running system by agents that never tire of the bookkeeping. Interfaces can be generated from contracts and checked against them automatically; architectural drift can be detected as it happens rather than discovered in an incident; the model can be kept current because keeping it current is no longer primarily human work. This is systems engineering returning – not as nostalgia for waterfall, but as a discipline finally made economical. The enterprise system can again be designed as a whole, because the whole can again be held in view at acceptable cost.

The Limit of AI Alone: Trusted Is Not Proven

But AI-restored systems engineering, by itself, reintroduces the problem it solves in a subtler form. A specification reconciled by an agent is still a document; an interface contract enforced by a pipeline is still enforced by whoever controls the pipeline; an audit log written by the system is still as trustworthy as the party that can rewrite it. The whole apparatus rests on delegated trust – the user relies on the deploying organisation to have specified correctly, verified honestly and not tampered with the record. In a single enterprise that may be acceptable. Across the boundaries that define modern systems – between firms, between an institution and its regulator, between a network and its participants – it is exactly the assumption that does not hold. And in the agentic era the stakes rise: when code and even architectural change are generated faster than any human can independently review, “trust us, the system does what the specification says” becomes a claim no counterparty should accept on faith.

The distinction at issue has been crisply drawn in the recent literature as trusted versus verifiable. Trusted systems rely on centralised reputation, institutional audits and internal governance: reliability is enforced by legal agreements and corporate oversight, and the internal computation stays hidden behind the provider’s assurance that it behaved. Verifiable systems operate on the opposite principle – verification over trust – replacing blind faith in a central party with a guarantee anyone can check. That is a different kind of claim about a system: not “we attest that it behaves” but “here is the proof that it did.” (5) Restoring systems engineering tells you the architecture is specified. It does not, on its own, tell anyone outside the specifying organisation that the architecture is true.

How Decentralisation Hardens It

This is where decentralisation does its work, and its primary role in the argument is not topological but evidential. The most important thing a decentralised substrate offers the enterprise system is not that it runs in many places, but that it lets the system’s guarantees be proven rather than asserted. Cryptographic verification turns the architecture’s contracts from policy-on-paper into enforceable, independently checkable facts. A computation can be run off-chain for speed and accompanied by a compact proof, verified cheaply on-chain, that it was executed correctly against a committed model or specification – without revealing the underlying data or logic. Industry practice in 2026 increasingly frames the chain as the accountability and provenance layer for AI-driven systems: a shared substrate for model attestations, decision records and audit logs that cannot be silently rewritten. The question shifts, as one survey put it, from whether a system can produce an output to whether you can prove how it was produced, who is accountable, and whether it holds up under scrutiny.

The mechanism that makes this practical is an asymmetry: computation can be expensive while verification is cheap. A model may run on a cluster for an hour and then hand back a cryptographic receipt that a counterparty checks in milliseconds – certainty about what was computed, without re-running it and without seeing the inputs. The infrastructure is no longer hypothetical, and three categories of it are now in production. General-purpose zero-knowledge virtual machines (such as RISC Zero) compile ordinary programs to a proven instruction set and emit a receipt any party can verify against a contract on a public chain; coprocessors (such as Lagrange and Axiom) prove facts about on-chain state; and machine-learning-specific frameworks (Giza’s on Starknet among them) let an autonomous agent prove that each decision it took genuinely came from the model it committed to, while the weights and the strategy stay private. The use case that makes the stakes concrete is the regulated one: instead of “trust the bank’s risk model,” a lending decision can arrive with a proof that this specific model, with these frozen parameters, evaluated this applicant’s data. The claim about the system stops being a matter of the operator’s word and becomes a fact the regulator, the counterparty or the smart contract can check for itself.

Two further strands reinforce the evidential one. Topologically, distributing a system across independent nodes removes the single points of failure and, more importantly, the single points of control – the places where one party can quietly alter behaviour, suppress a record or override a contract. Constitutionally, decentralised governance supplies an authority layer for the factory itself: the rules under which specifications are amended, agents are authorised and changes are admitted can be made explicit, distributed and themselves auditable, rather than vested in whoever holds the keys. Taken together, the three strands convert the restored architecture from a well-engineered private assertion into a system whose integrity is legible and enforceable from the outside. The factory, hardened this way, does not merely build the system well. It lets the system prove that it is what it claims to be – continuously, to parties who were never asked to trust it.

The Objections: Readiness, and Whether It Is Needed at All

The strongest objection to all of this is not philosophical but practical, and it deserves to be stated at full strength because it is, today, correct. Verifiable computation is expensive. Generating a cryptographic proof of a computation is, by current estimates, orders of magnitude heavier than performing the computation itself – for large models, proving has been reported as thousands of times slower than plain inference. The honest assessments in the field say plainly that proving small-to-mid model inference is feasible, proving large-model inference is partial, and proving full training remains aspirational (6). A sceptic is entitled to conclude that “provable architecture” is, for most enterprise workloads in 2026, a research programme rather than a deployable reality – and to note that a great deal of what is marketed as verifiable AI is closer to aspiration than to shipped capability.

The objection is right about the present and wrong about the trajectory, and the shape of the answer is telling. The overhead of proving has fallen sharply and continues to, as proof systems, hardware acceleration and circuit design improve; lighter-weight proof schemes are appearing precisely to address the cost. More to the point, the technology does not need to be universal to be decisive. The consistent assessment is that verifiable approaches arrive first exactly where they are most needed: in high-stakes, lower-volume settings – regulated decisions, financial settlement, content provenance – that can absorb the proving cost because the value of an independently checkable guarantee is highest there. This is not a weakness in the argument; it is the argument. Provable architecture will not arrive everywhere at once. It will arrive first in the domains where being able to prove the system’s behaviour is worth paying for – which is to say, in regulated finance before consumer apps, and in cross-institutional settlement before internal tooling. The frontier is narrow today and widening, and it is widening from precisely the territory this argument cares about most.

There is a deeper objection still, and it is not about cost. It is that most enterprises do not, in fact, need cryptographic verification at all, because the trust they run on is institutional and always has been: contracts, reputations, regulators, and the audited assurances of firms like the big four. By this account, a SOC 2 report or a trusted execution environment already delivers “good enough” verification, regulators accept those instruments today and replacing a lawyer-and-auditor stack that works with a cryptographer-and-prover stack that is harder to build is a solution in search of a problem. This is the most serious challenge to the argument, and the honest answer concedes a great deal of it. Institutional trust is not going away; for the vast interior of an organisation, where the parties already trust each other, it remains the right and cheaper tool, and the field’s own assessments are candid that cryptographic verification is not yet a drop-in replacement for traditional audit and that the two are complementary for now. But the concession locates exactly where the new layer earns its keep. Institutional trust works precisely where there is an institution to trust and a shared authority to appeal to. It is at the boundaries – between firms that are not within one another’s audit perimeter, between a network and a participant who cannot inspect its operator, between an autonomous agent and the counterparty it transacts with at machine speed – that “trust the firm” has no firm to point to. Verifiable architecture is not a replacement for the audit; it is what extends assurance across the seams that audits cannot reach, and those seams are exactly what a decentralised, multi-party financial system is made of.

Conclusion: Engineered to Be Proven

The future of enterprise software is not another swing of the pendulum between monolith and microservice, centralisation and distribution. It is the recovery of an older seriousness about systems, made affordable by one technology and made credible by another. AI returns the systems-engineering discipline that fragmentation discarded – the whole held in view, intent captured and reconciled, architecture designed rather than accreted – by collapsing the human cost that made that discipline a luxury. Decentralisation then does what neither documentation nor good intentions ever could: it lets the resulting system carry its own evidence, so that its guarantees are not merely specified but provable, not merely trusted but verifiable, not merely enforced by whoever holds the keys but legible to everyone who depends on it.

The two movements are complementary, and each answers the other’s weakness. Systems engineering without verification gives you a well-designed private assertion – better than fragmentation but still resting on someone’s word. Verification without systems engineering gives you cryptographic proofs of an incoherent architecture – mathematically certain statements about a system no one designed as a whole. Together they describe an enterprise system that is engineered to be proven: specified with discipline, built by a governed factory, and hardened by a substrate that turns its contracts into facts anyone can check. For most of the software industry this will arrive gradually, workload by workload, as the proving layer matures. For regulated on-chain finance – where the demand for provable behaviour is not a preference but a condition of operating – it is arriving now. That is the ground on which the future of enterprise software is being built first, and it is the ground on which Polity works.

The fragmentation era asked how fast software could be made to move. The era now beginning asks a harder and more durable question: not how fast a system can change, but whether, at any moment, you can prove what it is. The organisations that thrive will be those that treat that question not as a compliance burden but as the design problem – and build, from the first specification, systems engineered to be proven.

About Polity

This article is part of an ongoing programme of governance and thought-leadership publications developed within the Polity governance model. Polity’s central thesis is that durable outcomes are shaped by governance architecture: the rules, incentives and institutions through which work, value and obligation are formed. The convergence described here – AI-restored systems engineering, hardened by verifiable, decentralised substrate – is a governance problem in exactly this sense: it is the difference between a system that asks to be trusted and one that can be checked. Polity builds infrastructure for regulated digital finance, with governance frameworks designed to bridge decentralised systems and institutional-grade compliance requirements; the question of how to make autonomous, high-throughput software production not merely fast but provable, in environments where assurance is a condition of operating, is one it engages directly.

About Wavect

Wavect GmbH is an Austrian software engineering agency that builds product-led software for startups, scale-ups and enterprises, spanning full-stack development, fractional engineering and product leadership, software quality assurance, and applied work in artificial intelligence, blockchain and zero-knowledge systems. Wavect has provided software development and quality-assurance services to the Polity programme, and co-author Kevin Riedl is a Managing Partner of the firm. More information is available at https://wavect.io.

Disclaimer: This article is published for informational and educational purposes only. It does not constitute professional, legal, financial or engineering advice, nor an endorsement of any methodology, product, protocol, service or organisation. References to named researchers, studies, tools, standards and companies are made solely for analysis and commentary. Several of the technologies discussed – notably verifiable computation and zero-knowledge proofs of model execution – are early in their maturity and their capabilities and costs are evolving; relevant limitations are characterised in the text. All third-party sources are cited for reference; their inclusion does not imply endorsement by, or affiliation with, Polity. Co-author Kevin Riedl is a Managing Partner of Wavect GmbH, which provides software development and quality-assurance services to the Polity programme (see “About Wavect” above); this commercial relationship is disclosed in the interest of transparency and does not affect the independence of the analysis. Views expressed are the authors’ own.

References

1. vFunction (2026) Distributed Monolith Architecture: What It Is, Why It Happens, and How to Fix It. Available at: https://vfunction.com/blog/distributed-monolith-architecture/ (Accessed: 23 June 2026).
2. Cloud Native Computing Foundation (CNCF) (2025) 2024 Cloud Native Survey. (689 respondents; 42% consolidating microservices; service-mesh decline 18%→8%.) Available at: https://www.cncf.io/reports/the-cncf-annual-cloud-native-survey/ (Accessed: 23 June 2026).
3. McIlroy, M.D. (1968) ‘Mass-produced software components’, in Naur, P. and Randell, B. (eds.) Software Engineering: Report on a Conference Sponsored by the NATO Science Committee. Brussels: NATO Scientific Affairs Division, pp. 138–155. Available at: https://www.cs.dartmouth.edu/~doug/components.txt (Accessed: 23 June 2026).
4. Zhang, W., Cockburn, C., Henshaw, M. et al. (2026) ‘MBSE Co-Pilot: A Research Roadmap’, Systems Engineering, 29(1), pp. 20–33. INCOSE / Wiley. doi:10.1002/sys.70011. Available at: https://doi.org/10.1002/sys.70011 (Accessed: 23 June 2026).
5. Chainlink (2026) Verifiable AI vs Trusted AI: Key Differences. (Delegated-trust vs cryptographic-trust distinction; relevance to financial services.) Available at: https://chain.link/article/verifiable-ai-vs-trusted-ai (Accessed: 23 June 2026).
6. Everstake (2026) Blockchain and Verifiable AI: Can AI Be Blindly Trusted? (Feasibility of proving small/mid vs large-model inference; staged 2026–2028 adoption; high-stakes-first pattern.) Available at: https://everstake.one/resources/blog/verifiable-ai-onchain-trust-layer (Accessed: 23 June 2026).

Press and Web Sources (numbered for fact-verification)

Where the body attributes a specific finding to a named study, the primary source is listed under References above. The items below document the secondary reporting and the specific points each supports.

• vFunction (2026). ‘Distributed monolith architecture.’ Operational complexity of microservices without architectural independence; logical coupling; synchronised deployments. vfunction.com
• Pietschsoft / C. Pietschmann (2026). ‘Disposable software is the future.’ Distributed-monolith failure modes; interfaces needing ownership and versioned contracts; change-flow as the real measure of architecture. pietschsoft.com
• XYZBytes (2025). ‘From microservices hell to monolith heaven: the great architecture reversal of 2025.’ Consolidation back toward (modular) monoliths; reported cost and deploy-time reductions. xyzbytes.com
• SoftwareSeni (2026). ‘From microservices consolidation to modular monoliths.’ Modular monolith as enforced internal boundaries; CNCF 2024 Cloud Native Survey consolidation signal. softwareseni.com
• Engenia Technologies (2026). ‘AI software modernization: the 2026 enterprise guide.’ LLMs extracting business rules/intent into human-readable requirements; engineers shifting to constraints and architectural trade-offs; ~75% of enterprises on legacy systems. engeniatech.com
• Wishtree (2026). ‘Microservices architecture for enterprise.’ Clean versioned APIs as agent-callable skills; agentic orchestration of services; distributed-monolith risk without disciplined design. wishtreetech.com
• Blockchain Council (2026). ‘Verifiable AI inference using blockchain.’ Off-chain inference plus on-chain ZK proof; chain as accountability/provenance layer; ‘prove how the output was produced.’ blockchain-council.org
• Chainlink (2026). ‘Verifiable AI vs trusted AI.’ Delegated-trust vs cryptographic-trust; ‘verification over trust’; suitability for high-stakes financial environments. chain.link
• Everstake (2026). ‘Blockchain and verifiable AI.’ Proving cost/latency limits; small/mid feasible, large partial, training aspirational; high-stakes-low-volume-first adoption across 2026–2028. everstake.one
• Phemex Academy (2026). ‘What is verifiable AI?’ TEEs, ZK proofs, provenance standards (C2PA); why smart contracts cannot rely on opaque off-chain AI without a trust-minimising layer. phemex.com
• INCOSE / Wiley (2026). ‘MBSE Co-Pilot: a research roadmap.’ AI-driven model-based systems engineering to lower the adoption barrier for digital engineering. incose.onlinelibrary.wiley.com
• CNCF (2025). 2024 Cloud Native Survey. 689 respondents (±3.8% at 95% confidence); 42% of microservices adopters consolidating to larger units; service-mesh adoption 18%→8%; cloud-native adoption ~89%. Reported via SoftwareSeni / byteiota. cncf.io
• RISC Zero (2026). zkVM documentation and overview. General-purpose zkVM; Rust → RISC-V; STARK receipt with on-chain SNARK verifier; Bonsai proving service; Q1 2026 latency/throughput figures. (Also: Eco / degen0x explainers on RISC Zero, Lagrange, Axiom.) risczero.com
• ICME Labs (2026). ‘The definitive guide to zkML.’ Compute-expensive / verification-cheap asymmetry; Giza LuminAIR verifiable DeFi agents; loan-decision proof example; overhead trajectory (1,000,000×→10,000×); zkPyTorch and Lagrange DeepProve. blog.icme.io