The New Enterprise Software Architecture

INTRODUCTION

‍"Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning." — Winston Churchill

Over the past three decades in enterprise technology, I have watched the industry confidently declare the end of a particular architecture more than once. We declared the death of client-server and mainframe... the end of on-premise software with internet/cloud... we bid farewell to desktop software with mobile/smartphones. Now, with relatively recent breakthroughs in AI, we are seeing the markets unfairly punish solid technology and profitable businesses, unable to separate fear from greed, creating a binary environment of AI vs. not AI, in a fog called ‘SaaSpocalypse’. It is a fog where marketing departments feel pressure to ‘AI-wash’ every product and website, where VCs are punished for not investing in companies with ‘.ai’ in their name, and where entrepreneurs who have spent decades building technology businesses are told their companies are worth very little.

Having built, bought, and used enterprise software through these architectural shifts, I do see real differences in various architectures, but I see many more similarities. Client-server software is still here: the ‘thin client’ browsers of the late '90s may have been very different from client software of the time, but the browsers of today have become as ‘thick’, fully featured and offline-capable as the client software of the 1980s. Mobile and desktop software experiences are converging — think about how often you use a tiny browser on your phone to access a full web application, or how frequently you find yourself using what looks like an ‘app’ in a giant desktop browser. Despite a massive cloud infrastructure market, customers demand on-premise versions of software that can run in their labs, buildings, datacenters, or within the borders of their countries. Now, we are in the midst of a dramatic deployment of chatbots into homes and businesses. When I peel back the covers, more than a few enterprise AI software tools today look like the mainframe architectures of the '70s and '80s (a dumb text-based terminal connected to a giant building-sized brain somewhere).

So, the architecture of software has evolved, but one thing remains the same:  a human needs to do some work, and part of that work is hard for the human to do quickly, cheaply, or accurately, so the human uses software to help — a request is typed, clicked, or selected on a computer, sent over the network to another computer, database, or other service that does the heavy lifting, and a response is delivered back to the human via an email, a mobile app, a browser, a thick/thin client, some cloud software, etc. Some of the requests take one simple step or calculation before returning an answer to the human (e.g., check shipping status), and some require 100+ pre-configured steps in a workflow that runs across ten different systems and databases in a company (e.g., multi-channel fraud detection), each step with its own inputs and outputs. For the foreseeable future, this will continue to be the model.

I have no doubt that AI will render software unrecognizable in 10-15 years in unpredictable ways. However, with any new disruptive technology, we tend to overestimate the impact in the short term and underestimate the impact in the long term. I believe we are in the overestimation phase of AI, especially in the enterprise tech world. Does this mean we should not remain wildly optimistic about the role of AI in enterprise software? No. In fact, it’s quite the opposite: in order to bring forward the downstream benefits of AI, we must continue to invest, buy/build/partner, and embed AI into software architecture. This is a profound architectural shift — and possibly the greatest architectural shift I have ever seen — in enterprise software, and I do see important new pieces of the ‘stack’ that are here to stay. In this post I will discuss three of these architectural layers from my ongoing research and Brighton Park's recent investments in AI-enabled software:

1. ‍The use of AI harnesses: In the past 3 years, powerful AI models have become available to use as a service or download for free, but they remain probabilistic in nature, and the deterministic nature of enterprise work requires harnesses to control and direct the work of the models.
2. Domain-specific data: All base models are trained on publicly available data, so the value of proprietary, domain, company, and use-case specific data has never been higher or more useful in making enterprise software work better and get better over time with more usage.‍
3. Changing role of humans: Humans will likely remain in the picture as users of software, but what they are doing with the software is changing from inputting data and clicking on buttons and forms to managing exceptions and unblocking / coaching the software when it gets stuck. 

‍

‍

1. THE USE OF AI HARNESSES

"AI today is unbelievably intelligent and then shockingly stupid." —Yejin Choi

 The reason the latest AI models seem magical and human is because they are in fact human in one very important way: even when you pin the settings down, two nearly identical inputs can still produce very different outputs. AI models can give different answers to the same questions, and come to a wide range of conclusions given the same input and data. Ironically, this superpower in consumer applications is a crippling Achilles heel in the enterprise market.

An AI model that is right 92% of the time is a marvel in a demo and a liability in a reconciliation process, because the enterprise does not grade on a curve. The invoice is either coded to the right account, or it is not. The claim is either adjudicated correctly, or it lands in an appeal 45 days later. The trade either settles, or somebody spends a Saturday finding out why it didn’t. Most work that happens in companies is deterministic by nature and often by regulation, and we are now asking a machine that is probabilistic by design to do that work.

This is not a new problem in technology. We have spent 50 years wrapping unreliable components in software that makes them behave. Packet delivery across a network is lossy and out of order, so we built TCP on top of it and handed applications a reliable stream. Disks fail, so we built journaling file systems and RAID. Concurrent writes corrupt data, so we built transaction managers, locks, and two-phase commit, and then taught a generation of developers to reason in terms of ACID without ever thinking about the failure rates of small moving pieces with magnets reading and writing data on a metallic platter deep inside the computer. In each case the durable value did not sit in the raw component. It sat in the layer that made the raw component safe to build a business on.

The harness is that layer for AI. In practice, it is the code that assembles the right context before the model is asked anything, that gives the model tools to call into systems of record rather than inviting it to recall from memory, that decomposes a job into steps small enough to check, that validates each output against a schema or a business rule or a second model, that retries, that falls back, that knows when to stop and hand the work to a person, that enforces which identity is allowed to take which action, and that writes down everything it did in a form an auditor will accept. None of that is glamorous, but all of it is the product and can be the bulk of the defensible IP of an AI-enabled software company.

‍Daloopa, where Brighton Park led a $47 million Series C in May, shows what that grounding requirement looks like in practice. The failure mode Bin this domain is unforgiving. A model that hallucinates a revenue line by a single digit does not produce a slightly wrong answer; it produces an error that propagates through every forecast period and every derived ratio downstream. So, the harness cannot permit the model to recall the number. It has to force the model to retrieve it, and then it must prove and source exactly where the number came from. Daloopa links each datapoint back to its original source document, which turns provenance from a nice-to-have feature into the validation mechanism itself. A human or an agent can click from the figure straight back to the filing that produced it. The effect is measurable. In a published benchmark, grounding an AI agent in Daloopa's structured data rather than web-based retrieval improved accuracy by as much as 71 percentage points. A gap that size is not a story about model selection. It is a story about what the harness hands the model before the model is allowed to answer.

Daloopa’s plug-in architecture for Claude, Excel and other enterprise applications points to another change in the shape of software architectures. Daloopa has a user interface, but a growing share of what it sells is consumed by other software. The harness calls it, an agent reads the answer, and no human ever opens a screen. For 30 years the interface was the product and the API was a feature you exposed so that partners could integrate. In an AI-enabled architecture that relationship inverts. If the model must retrieve rather than recall, something has to sit on the other end of the retrieval, and that something is a business whose product is an endpoint rather than a screen. Technically, this is not new either. EDI, SWIFT, the market data feeds that FactSet and Bloomberg built businesses on, and later Twilio, Stripe, and Plaid were all API-led companies long before the phrase was in circulation. What has changed is who is calling. The caller used to be another program, written by a developer who read the documentation and made a deliberate integration decision once, and then left it alone for 5 years. The caller is now increasingly an agent making that decision at runtime, and it will choose whichever source is accurate, fast, and able to show its work. That changes what you are selling, how you price it, and what you have to prove before anyone will use you.

There is one more reason the harness matters, and it is the reason Brighton Park spends time on it during diligence: the models change underneath you. Versions get deprecated, behavior shifts on an upgrade, and a prompt that worked in March degrades in June for reasons nobody can fully explain. Teams that have built real evaluation suites, and who treat them the way we once treated regression tests, can adopt a new model in a week. Teams that have not adjusted to this new reality are afraid to touch anything. When investors or others dismiss an idea as a ‘wrapper’ (meaning that the business is not much more than a UI/UX that sends your work to a frontier model), a robust and domain-aware harness is usually the layer that might be missing or immature in that company.

2. DOMAIN-SPECIFIC DATA

"Life is like a snowball. The important thing is finding wet snow and a really long hill." — Warren Buffett

Every frontier model has read approximately the same internet, so the base layer of general knowledge is now something close to a commodity, available for a few dollars per million tokens or free on a laptop. Every model knows what a prior authorization is, what a bill of lading is, and how revenue recognition works under ASC 606. What no base model knows is how your company actually does any of it.

The gap shows up immediately in production. A model understands the general concept of a claim denial. It does not know that your second-largest payer denies a particular code roughly 40% of the time for a reason nobody ever wrote down, and that your team figured out 6 years ago that attaching one specific document up front avoids the whole cycle. That knowledge is not on the internet. It is scattered across your transaction history, your ticket notes, your call recordings, your exception logs, and the memory of 3 people who have been there a long time.

We find it useful to think about four categories of domain-specific data:

1. ‍Transactional data (i.e., the records themselves, which most companies have in volume.)‍
2. Process data (i.e., exhaust data from the actual work like what got routed where, who approved it, what got reworked and how many times.)
3. ‍Outcome data (i.e., what happened next and whether the decision turned out to be correct.)‍
4. The vocabulary (i.e., the internal terminology, acronyms, informal jargon and formal ontologies and the accumulated list of edge cases that make a domain a domain.)

Outcome data is the scarcest and the most valuable, and it is the category most enterprise software has been quietly discarding for 20 years. We logged that a field changed. We did not log why it changed, who overrode whom, or whether the override was right. A great deal of the engineering work we see right now is retrofitting instrumentation onto products that were never designed to learn from themselves. It is unglamorous, it takes two or three quarters, and it is the precondition for models to do more of the work in reliable ways.

This is where the flywheel people describe becomes real, and Brighton Park's investment in Oro Labs illustrates why the most valuable data is often not the documents. Procurement inside a global enterprise is a maze of intake forms, approvals, supplier onboarding, compliance reviews, and ERP workflows spread across disconnected systems. The system of record captures the transaction. It does not capture how the decision actually got made: who was routed to whom, which approval sat for 9 days, which policy exception was granted and on what grounds, which supplier was onboarded twice because 2 business units did not know about one another. That is the process data described above, and for 30 years it has been leaking out of the seams between systems. Oro built an orchestration layer that sits above ERP, P2P, and related systems as a system of engagement, standardizing intake, routing work intelligently, and embedding policy and risk controls into the flow of work. Sitting in that position means Oro observes the process rather than the receipt. The founding team spent years inside these workflows before starting the company, and it shows in the design: the intelligence is embedded in the workflow itself rather than layered on top of procurement, which is precisely what makes the accumulated context usable rather than merely stored. No base model has any of this. A model can tell you what a purchase order is. It cannot tell you that at your company a software purchase touching customer data will stall in security review unless it is routed a particular way.

This is why Brighton Park's first two questions in diligence are whether the data flywheel is instrumented and whether the customer contracts permit it to turn. A master services agreement written in 2016 often does not grant the right to use one customer's data to improve a model that serves all customers. Companies that have designed for this from the beginning have a structural advantage over companies now retrofitting it, and the gap is wider than it looks from the outside.

A model can be swapped out in a weekend. A harness can be rebuilt in two quarters by a good team. More than 10 years of labeled outcomes in a narrow domain, with the rights to use them and the instrumentation to keep adding to them, cannot be reproduced on any timeline that matters to a startup. The market is currently pricing many incumbents as though their data were a liability, but in a fair number of cases it is the single most defensible thing they own, and the question is not whether they have it but whether they are organized to use it.

‍

3. CHANGING ROLE OF HUMANS

"Weak human + machine + better process was superior to a strong computer alone." — Garry Kasparov

 The most common prediction in the current fog is that the human disappears from the software. What we actually observe is that the human moves. We have seen this before. When the spreadsheet arrived, it did not eliminate accountants. It eliminated the arithmetic, and it moved the work up the stack toward judgment, modeling, and explanation. There are more accountants today than there were in 1979, and their work looks almost nothing like it did. The same pattern held in aviation. Autopilot did not remove the pilot; it changed what the pilot was for, and the hard part of training shifted from flying the aircraft to knowing when to take the aircraft back.

Architecturally, the consequence lands hardest on the user interface. For 30 years, the central design problem in enterprise software was data entry: forms, fields, tab order, validation rules, dropdowns, and the endless work of making a 40-field screen tolerable. If the software now does the data entry, the central design problem becomes review. That is a genuinely different discipline. It means queues rather than screens, ordered by risk rather than by date. It means showing confidence and provenance, so a human reviewer (or, in some cases as the tech improves, an AI agent) can see not only what the system concluded but how it got there. It means diffs, one-click acceptance, one-click correction, and an audit trail that survives contact with a regulator.

In this new model where fewer humans are doing different and more exception-handling work higher up the stack, counting seats and screens gives way to something closer to span of control: how many units of work can one qualified person supervise in a day, and at what error rate. That is the number a CFO can act on, and it is why pricing in this category keeps drifting toward consumption and outcomes even in companies that would rather keep selling seats. After all, the human user is doing 2 jobs, whether or not the product acknowledges it. She is resolving the case in front of her, and she is generating exactly the labeled outcome data discussed previously and creating a human feedback loop for the software to improve. Software that captures only the first and throws away the second is leaving its most valuable asset on the table.

Well-built software products could one day charge even more than they can in a per-seat model. Tesla is delivering to the market a car that gets better over time. The software has learned how to drive from owners over hundreds of millions of miles and can now handle daily driving better than its human teachers in most situations. But still, when the car is about to do something dumb, the driver has an opportunity to nudge it and correct it. Immediately, a prompt and a mic comes on and gives the driver an opportunity to explain why they took control. That feedback, along with thousands of data points from sensors, GPS and cameras on the car are sent in a packet to Tesla’s software for training. Users of Tesla’s FSD (Full Self Driving) feature are now paying more for the same car they already paid for by signing up for a monthly recurring subscription to the FSD feature for $99. Often, these early adopters are comparing $99 per month to the cost of a private human driver. If that is the case, FSD is a steal; Tesla could charge orders of magnitude more before feeling resistance.

‍Orbital, the AI-native platform for real estate legal work Brighton Park backed earlier this year, has built the human feedback mechanism into its org chart. Alongside its engineers, the company employs practicing real estate attorneys whose full-time job is refining how the system reasons. They watch what their product produces against live title reviews, lease abstractions, and covenant analyses, find the places where the output drifts from what a partner at a law firm would actually sign off on, and rewrite the instructions until it stops drifting. This is not a QA function bolted on after release. It is the mechanism by which decades of accumulated professional judgment get encoded into software, one correction at a time, across the more than 200,000 property transactions the platform supports each year. The lawyers using the product generate the signal. The lawyers on Orbital's team convert that signal into system behavior. The loop closes because somebody is paid to close it. There is a hiring implication here that surprises people, and Brighton Park has started asking about it directly in diligence: the scarce role in an AI-native software company is frequently not the ML engineer. It is the domain expert who is credible enough to know what good looks like and precise enough to write it down.

From an engineering point of view, a critical part of the new software architecture design becomes how to calibrate what gets escalated and how to preserve enough context for a human reviewer to make a real decision in 30 seconds. This is a first-class engineering problem rather than a configuration setting. The companies that treat it as a setting produce very good demos but very disappointing renewals. Especially in regulated industries, a named human being is going to remain accountable for consequential decisions for a long time. Lending, clinical, and trading contexts all have decades of regulatory scaffolding built around the premise that someone can be asked to explain a decision. That is not a temporary constraint waiting to be optimized away, and software designed as though it were will not get through procurement.

Fifty years ago, a human sat at a terminal, typed a request, and waited for a building-sized mainframe to answer. Today a person sits at a chat window, types a request, and waits for a building-sized datacenter to answer. A lot remains the same. Perhaps what has changed the most is what we are asking the human to contribute, and the software that wins the next decade will be the software built around the answer to that question.