The Future of Enterprise Software

How AI Can Assist Systems Engineering, and Cryptography Can Verify Selected Claims

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 was fully reviewed on 2 September 2026 against public research, official documentation, industry surveys and practitioner reporting. Several technologies discussed remain early. Vendor performance and adoption statements are identified as such, and figures from this fast-moving field are snapshots rather than guarantees. 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 often became difficult to see. One failure mode was the distributed monolith, a system that bears microservice operating complexity while retaining tight coupling. What fragmentation can lose is systems engineering: treating the whole as an object of design, with explicit requirements, governed interfaces and verification against intent. This article argues for two qualified possibilities. AI-assisted analysis can reduce some of the work required to recover and maintain that whole-system view, but current MBSE research still requires human oversight and does not demonstrate autonomous system modelling at enterprise scale. Cryptographic proofs and tamper-evident ledgers can make selected computations and records independently checkable. They do not prove an entire architecture, the truth of its inputs, the suitability of a model or regulatory compliance. These mechanisms can complement audits and contracts at carefully chosen cross-organisational boundaries, but their adoption order and economics remain workload-specific rather than settled.

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.

The official CNCF survey does not support an industry-wide reversal from microservices to monoliths. Its 2024 results reported 89 per cent cloud-native adoption, while service-mesh adoption moved from 50 per cent in 2023 to 42 per cent in 2024 amid operational-complexity concerns (2). This indicates continued cloud-native use alongside selective simplification, not the previously reported claim that 42 per cent of microservice adopters were consolidating or that service-mesh use fell from 18 to 8 per cent. One concrete case remains instructive but narrow: Prime Video reported a 90 per cent infrastructure-cost reduction for one monitoring workload after consolidating components into a monolith. Werner Vogels used the case to stress that there is no one-size-fits-all architecture and that building evolvable systems is a strategy rather than a religion (3). The evidence supports choosing boundaries for the workload, not declaring distribution or consolidation universally correct.

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.

Maintaining an accurate model of a large system, including its components, dependencies, contracts and constraints, can be labour-intensive and prone to drift. That does not show that systems engineering was broadly abandoned or unaffordable. A 2026 MBSE research roadmap instead identifies practical adoption barriers, infrastructure costs and limited evidence of fully automated, scalable solutions for large modelling environments (4). The constraint is therefore organisational and technical, not a universal rejection of the discipline.

Why AI Brings the Discipline Back

This series’ previous instalment argued that AI shifts some engineering effort from implementation towards specification. At architecture level, models can assist with code mapping, summarisation, traceability and consistency checks. They do not reliably recover unstated business intent or turn legacy modernisation into a routine design exercise. The 2026 MBSE Co-Pilot paper is explicitly a research roadmap: it says current tools often cannot complete model generation and refinement without substantial human intervention, and it retains human design authority even at its highest proposed assistance level (4).

A living, versioned specification that is reconciled with the running system is therefore a design goal, not an automatic result of adopting AI. Agents may propose interfaces, flag suspected drift and update model drafts, while accountable engineers validate requirements, context and safety consequences. Whether this lowers total cost depends on model quality, tooling, review effort and organisational practice. AI assistance can make systems-engineering work more tractable, but the evidence does not justify calling the discipline universally economical or primarily autonomous.

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.

Institutional assurance and cryptographic verification make different claims. Contracts, audits and governance provide accountability around an organisation and its controls. A cryptographic proof can let a verifier check one encoded statement without relying solely on the operator’s assertion. Its force is limited to that statement and its assumptions. Restoring systems engineering can make an architecture explicit; neither a specification nor a computation proof makes the architecture as a whole “true.”

How Decentralisation Hardens It

Cryptographic verification can make a precisely encoded computation independently checkable. If a statement binds the intended program or model and committed inputs, a receipt can show that the encoded computation produced the claimed output (5). Zero knowledge can conceal a private witness when the proof system and statement are designed for that property. None of this establishes that an input was true, a model was appropriate or fair, or the wider business process complied with law. A blockchain can provide a shared, tamper-evident record under its validation, consensus and governance assumptions; NIST describes such ledgers as tamper evident and tamper resistant, not unconditionally immutable or trust-free (8).

Developer tooling is real, but its maturity and scope are mixed. RISC Zero documents receipts for verifying execution of a specified program (5). Axiom currently offers an invite-only hosted proving API for OpenVM rather than the broad production coprocessor claim previously made here (6). Lagrange has open-sourced DeepProve and reports end-to-end proofs of LLM inference, but its performance and production-volume statements are vendor-reported and benchmark-specific (7). These systems do not prove an enterprise architecture as a whole. In a lending example, a proof could show that a committed model processed committed input; a regulator would still need assurance about identity, data quality, model governance and legal compliance.

Distribution can reduce some single points of failure or control, but it does not eliminate them automatically. The result depends on node independence, consensus, governance, key management, upgrade authority and external data sources. Decentralised governance can make amendment and authorisation rules more visible, while still concentrating effective control in token holders, operators, multisignature signers or administrators. Architecture must therefore state exactly which guarantee is decentralised and which actors or dependencies remain trusted.

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

Proof generation adds computation and operating cost, but the overhead varies substantially by workload, proof system, hardware and security target. The earlier blanket statement that large-model proving was thousands of times slower, while only partial proofs were feasible, is not a durable summary. Lagrange now reports an open-source, end-to-end LLM-inference construction (7). That is a meaningful technical development, but it does not by itself establish production economics for arbitrary models, prove training, or make vendor benchmarks directly comparable.

High-stakes, lower-volume uses are a plausible priority when the value of independent verification exceeds its cost. They are not a measured or inevitable adoption sequence. Regulated decisions, financial settlement and content provenance have different latency, privacy, legal and threat-model requirements. A team should evaluate the exact statement to prove, the party that verifies it, proof-generation resources and the failure modes left outside the proof instead of assuming that regulated finance must precede consumer or internal applications.

SOC 2 reports, trusted execution environments and cryptographic proofs answer different questions. A proof may establish that encoded computation occurred; it does not establish governance-control effectiveness, lawful input collection, model suitability or overall compliance. Conversely, an audit does not independently replay every computation. Institutional assurance therefore remains necessary, and cryptographic evidence can complement it at a cross-organisational boundary only when a concrete threat model and verifier justify the added system.

Conclusion: Engineered to Be Proven

The future of enterprise software need not be another swing between monolith and microservice, or centralisation and distribution. AI assistance can reduce some effort required to map systems, maintain specifications and detect inconsistencies, while accountable engineers retain design authority. Cryptographic systems can attach independently checkable evidence to selected computations and records. They cannot make an architecture as a whole provable or remove the need to assess inputs, governance, dependencies and compliance.

These approaches can complement each other, but they describe a design direction rather than a settled future. Systems engineering supplies the context needed to decide which invariant is worth proving. Verification supplies evidence only for the statement actually encoded. In regulated on-chain finance, developer tools and pilots exist, while legal fit, operational controls and production economics remain implementation-specific. The useful question is therefore not whether an organisation can prove what its entire system is, but which consequential claim a counterparty needs to verify and what remains trusted outside that proof.

The durable design question is not only how fast a system can change, but which of its consequential claims another party must be able to verify. Strong organisations state that claim precisely, identify the remaining trust assumptions, and choose evidence proportionate to the risk.

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-assisted systems engineering combined with evidence for selected computations, is a governance problem in this sense: every proof has a scope, a verifier and residual trust assumptions. Polity builds infrastructure for regulated digital finance, with governance frameworks intended to bridge decentralised systems and institutional compliance requirements.

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 and verification notes

Fully reviewed on 2 September 2026. Vendor performance and adoption statements are treated as vendor claims.

1. vFunction (2026), Distributed Monolith Architecture: What It Is, Why It Happens, and How to Fix It. Practitioner definition of the distributed-monolith failure mode. vfunction.com (Accessed: 2 September 2026).
2. Cloud Native Computing Foundation (2025), CNCF Research Reveals How Cloud Native Technology is Reshaping Global Business and Innovation. Official 2024 survey summary: 89% cloud-native adoption and service-mesh adoption moving from 50% in 2023 to 42% in 2024. cncf.io (Accessed: 2 September 2026).
3. Vogels, W. (2023), Monoliths are not dinosaurs. Official discussion of the Prime Video monitoring-workload case, including the reported 90% infrastructure-cost reduction and the linked archived team post. allthingsdistributed.com (Accessed: 2 September 2026).
4. Zhang, W., Cockburn, C., Henshaw, M. et al. (2026), ‘MBSE Co-Pilot: A Research Roadmap’, Systems Engineering, 29(1), 20–33. Current limitations, human oversight and the proposed assistance levels. doi.org/10.1002/sys.70011 (Accessed: 2 September 2026).
5. RISC Zero, Developer Documentation. Receipts certify that a specific program produced a specific output without revealing private inputs when the proof is configured accordingly. dev.risczero.com (Accessed: 2 September 2026).
6. Axiom, OpenVM Proving API Documentation. The current hosted proving API is invite-only. docs.axiom.xyz (Accessed: 2 September 2026).
7. Lagrange (2026), Inside DeepProve: Proving an LLM End-to-End. Official engineering update and vendor-reported end-to-end LLM-inference proof results. lagrange.dev (Accessed: 2 September 2026).
8. NIST (2018, current resource), Blockchain Technology Overview, NISTIR 8202. Blockchain as a shared, tamper-evident and tamper-resistant ledger whose guarantees depend on validation and consensus. csrc.nist.gov (Accessed: 2 September 2026).