This article builds directly on the earlier argument that airlines sell seats while passengers buy trips. That earlier piece focused on the weakness of the current model. Airlines optimize the seat to fit internal economics, while the customer judges the trip as a whole.

This article takes the next step. If that diagnosis is right, artificial intelligence does more than optimize airline operations. It helps expose an entirely different business model.

The seed idea is straightforward. Airlines move economically active customers into cities. Those customers spend money after arrival. If that spending can be influenced, attributed, and shared, then the fare is no longer the only meaningful source of revenue. The airline begins to monetize customer movement and destination demand, not only transportation.

The deeper implication is more significant. In an Empowered Customer model, customer-generated revenue does not merely subsidize the seat. It can accumulate as shared capital. Over time, that capital can finance routes, secure fleet capacity, and eventually support customer-owned aviation infrastructure through a cooperative model.

That does not mean a new entrant starts by buying aircraft. It means a new entrant starts by owning demand, trust, and recurring economic activity strongly enough that fleet access becomes financeable later. AI matters here because it helps surface the model faster and more fully than a single strategist working alone. A seed idea becomes an executable commercial system.

Introduction

Industries often look fixed until someone changes the unit of value.

Taxi firms looked durable until the market stopped centring the licensed cab and started centring the ride. Hotels looked durable until the market stopped centring the room inventory and started centring the stay. Search looked durable until the market stopped centring indexed pages and started centring conversational access to answers.

Airlines face a similar exposure.

From the inside, the business still appears rational. Seats are countable. Seats fit yield management. Seats fit route planning, ancillary pricing, loyalty rules, aircraft configuration, and quarterly reporting. If you run an airline, it is understandable that the seat becomes the dominant unit of thought.

The customer does not think that way.

The customer wants to get somewhere, do something, and extract value from the trip. The aircraft seat is only one component in that larger outcome.

That distinction was the heart of the earlier article. Airlines sell seats. Passengers buy trips.

This article asks a different question.

If the customer is the real economic unit, what happens when AI helps us explore the business model consequences of that more aggressively than incumbent airlines do themselves?

The Problem

The present airline model tends to stop commercial imagination too early.

It asks how to improve revenue per seat, increase density, manage labour, increase ancillary income, and improve utilization of expensive assets. Those are legitimate questions inside a capital-intensive business.

They are also inward questions.

They assume the primary commercial problem is extracting more value from the act of carrying a person.

A different question sits outside that frame.

What is the economic value of bringing this particular person into this particular city at this particular time?

That question changes everything.

Once asked seriously, the airline begins to look less like a transport provider and more like a mover of demand. The customer arrives with spending power, companions, preferences, future travel potential, and social influence. Their economic relevance does not end at landing. In many cases, it begins there.

The weakness in the current model is not that airlines do not understand travel. It is that they still treat transport as the primary commercial event.

How the Industry Arrived Here

This narrow framing did not happen by accident.

Airlines learned to manage what they could measure with precision. Aircraft utilisation, route profitability, seat load factor, fare classes, baggage fees, loyalty redemptions, catering costs, fuel exposure, crew rotations, maintenance schedules, and gate timing all reward disciplined operational thinking.

Seats fit this machinery perfectly.

That is why the industry became so good at optimizing around them.

Yet industries often mistake what is easy to manage for what matters most strategically. The operational unit quietly becomes the business’s mental model.

The same pattern appeared in earlier infrastructure shifts.

Companies once defended copper networks because copper was how connections worked. Enterprises once defended internal data centres because racks and servers were how applications ran. Then the model changed. Customers did not want copper. They wanted a phone. Businesses did not want racks. They wanted software.

Airlines face the same kind of reframing risk.

Customers do not want a seat in the abstract. They want the ability to move, arrive, spend, connect, and live.

Where the Current Model Breaks Down

The current model begins to break down when a new entrant stops asking how to improve the seat’s economics and starts asking how to participate in the customer’s economics.

That is a different commercial frontier.

Consider the familiar internal logic of the incumbent airline.

• Add density to the cabin.

• Increase ancillary charges.

• Improve yield on the route.

• Tighten staffing and turnaround.

• Lower acquisition cost through better distribution.

Each move improves a local metric.

Now consider a different logic.

• Reduce fare pressure by monetising destination spending.

• Increase loyalty by returning part of that value to the customer.

• deepen merchant participation by proving attributable demand.

• convert repeat travel into recurring downstream revenue.

• use customer-generated economic activity as the basis for capital formation.

The first model optimises the transport container.

The second model monetises the person moving through it.

That is the point at which incumbents become exposed. They keep refining yesterday’s economics while a different model begins to form over the horizon.

The Insight

The strategic insight is simple.

Airlines do not only move passengers. They move purchasing power.

Every arriving traveller represents downstream economic activity. Restaurants. Retail. Events. Attractions. Transport. Services. Hotels. Local experiences. Repeat visits. Group spending. Professional introductions. Referrals.

If the airline influences where that activity goes, then the airline already holds commercial leverage beyond the fare.

The missing layer is not transportation. It is attribution.

If the airline can direct a customer toward participating merchants, verify the visit or transaction, and settle a revenue share, then it has created a revenue layer linked to customer movement rather than only to transportation.

This is where AI matters.

AI did not invent the desire to rethink airline economics. It did something more important. It helped surface the full consequences of a partial insight. A human subject matter expert can sense the opening. AI can rapidly expand the scenario, pressure-test the logic, connect it to adjacent patterns, and expose the business model sitting behind the intuition.

That matters because incumbents often do not get displaced by a better version of the old model. They get displaced when someone sees the new model first.

The Proposed Model

The next model is not simply an airline with stronger ancillaries.

It is a customer-centred destination commerce network that uses travel as acquisition and customer movement as the trigger for revenue.

The model has five layers.

1. The Ticket as Customer Acquisition

The fare is no longer only transportation revenue.

It becomes the price of acquiring a customer into a revenue network that extends beyond the flight itself.

2. The Destination as the Start of Monetisation

Landing is not the end of the transaction.

It is the beginning of the next commercial phase. The airline now has the opportunity to influence where the customer eats, shops, books, visits, and returns.

3. Attribution as the Control Layer

The technology does not need to be exotic.

QR codes, merchant identifiers, simple mobile flows, and clean settlement mechanisms are enough to prove whether the airline influenced the customer’s visit or purchase. The model depends less on technical sophistication than on disciplined attribution and merchant trust.

4. Recurrence as the Real Revenue Multiplier

A seat is sold once per trip.

A customer relationship can generate value many times. Before travel. During the trip. At the destination. On the next trip. Through recurring merchant usage. Through colleagues and friends who adopt the same model.

This is where the economics begin to compound.

5. Cooperative Capital Formation

The most important extension sits here.

If customer-generated revenue is shared back into a cooperative structure, then the economic activity of the members begins to finance the transport network they use. At first, this may subsidise fares. Later, it may secure route guarantees, reserve capacity, or support leased fleet access. Over time, it may help finance aircraft ownership.

That is when the airline stops looking like a company selling seats and starts looking like customer-owned mobility infrastructure.

Why This Is More Dangerous Than a Better Loyalty Programme

A traditional loyalty programme rewards frequency.

This model rewards economic participation.

That is a much stronger position.

The customer is not merely collecting points from flights. The customer is helping generate the revenue that supports cheaper travel, stronger routes, and shared capital. The psychological frame changes from passenger to participant.

That creates a deeper moat.

• Customers stay because the model gives them visible economic value.

• Merchants stay because attributable demand is more valuable than generic advertising.

• Routes strengthen because demand is tied to recurring participation, not one-time ticket pricing.

• The capital base strengthens because customer activity feeds the system that serves the customer.

This is closer to a cooperative platform than to a classic airline brand.

Why Distressed Aircraft Matter, but Only Later

One tempting conclusion is that bankrupt airlines make aircraft cheap, so the answer is simply to wait for distress and buy planes.

That view is incomplete.

Distressed aviation assets create openings, but they do not create a business model on their own. Aircraft without demand, route rights, operations, trust, and customer gravity are still heavy assets.

The more important sequence runs in the opposite direction.

First, build the demand system.

Then let customer activity create recurring revenue.

Then let shared capital improve the ability to lease, finance, or eventually acquire fleet capacity when the economics are favourable.

In other words, the real advantage is not cheap metal first. It is customer-owned demand first.

That makes fleet access a financing question later rather than the central strategic barrier at the beginning.

Practical Application

This model would not start as a full airline replacement.

It would begin where the economics are easiest to prove.

A focused route. A destination-heavy market. A merchant network with high discretionary spend. Clear attribution. Visible customer reward. Strong repeat traffic.

The initial loop is straightforward.

• The customer books travel.

• The platform directs the customer toward participating merchants.

• The customer engages using a simple attributable mechanism.

• The merchant pays because the traffic is measurable.

• The customer receives value back through subsidy, rewards, or cooperative participation.

• The revenue that is not returned immediately accumulates as shared capital.

That loop does three jobs at once.

It lowers the practical cost of travel.

It increases customer gravity because the relationship becomes economically richer after arrival.

It builds the basis for a cooperative transport model without requiring full airline ownership on day one.

What Else Must Be True

Several additional factors matter if this model is to move from intriguing to durable.

Governance Must Be Trustworthy

If customers are meant to generate and share in the value, the capital structure cannot look like a disguised extraction model. The cooperative mechanics, payout logic, reserve policies, and asset ownership rules must be transparent.

Merchant Economics Must Be Strong

Merchants will not participate because QR codes are simple. They will participate because attributable demand produces better economics than other customer acquisition channels.

The Model Must Survive Fraud and Noise

Attribution systems attract gaming. Merchant claims, customer scanning behaviour, duplicate attribution, and false reward loops all require disciplined controls.

Route Density Still Matters

A customer-centred model does not repeal aviation physics. Routes still need enough demand concentration and predictable spend patterns to support the economics.

Regulation and Operations Do Not Disappear

Even if the long-term destination is a customer-financed cooperative airline, aviation still requires certification, maintenance, crew standards, insurance, route rights, and operational discipline. The model changes who finances movement and how value is captured. It does not eliminate the realities of safe air transport.

Implications for Architects and Leaders

Architects should see this as more than a payments idea or a referral platform.

It is a new system boundary.

If the customer becomes the economic unit, then the architecture must support identity, merchant participation, event capture, attribution, reward calculation, capital accounting, and governance visibility. The system is no longer optimising a seat transaction. It is modelling an economic relationship.

Leaders should see the same pattern at the strategic level.

The most serious threat to an incumbent airline may not be another carrier with cheaper fares. It may be a model that monetises the customer more intelligently than the airline monetises the seat.

That is the warning.

Industries rarely lose because they are weak inside their own frame. They lose because they do not leave the frame in time.

Closing Perspective

The earlier article argued that airlines quietly weaken loyalty when they optimise the seat instead of the trip.

This article pushes that argument further.

If the seat is not the true unit of value, then the airline may not be the final form of the business either.

A different model becomes imaginable.

One where travel acquires customers into a commerce network.

One where destination spending becomes part of route economics.

One where recurring customer activity builds shared capital.

One where the people creating the economic value begin to finance the infrastructure that serves them.

That is why this matters.

The real strategic risk is not only that incumbents might miss a better ancillary idea. It is that AI helps surface a different business model before incumbents realise the boundary has moved.

Airlines still sell seats because seats fit the old logic of the industry.

The more powerful future may belong to the model that treats the customer, and the customer’s economic activity, as the real asset.

Every era spends money on the infrastructure it assumes is necessary.

The telephone era was spent on copper, poles, switches, and physical reach. Mobile changed the delivery model. In many countries, especially parts of Africa, adoption leapt toward mobile while fixed-line build-out stayed low. The cloud later changed where applications run and who carries much of the infrastructure burden. Agile changed how software teams learned by shortening feedback loops.

Now, agentic AI is changing something deeper. It is changing the production economics of software itself.

The next advantage will not come from merely buying AI tools. It will come from redesigning software delivery around compressed cycles, stronger architectural intent, and faster release of business value.

Introduction

If you want to understand where software is going, it helps to stop looking at software for a moment.

Look up.

Above many streets, even now, the old logic of communication is still hanging in the air. Wires. Poles. The visible remains of a time when reaching a person meant physically reaching their house. The network had to travel to the building before the conversation could begin.

That model made sense for its time. It was expensive. It was labour-intensive. It was slow to expand. It was also necessary.

Then the model changed.

The purpose did not change. People still wanted to talk. Businesses still wanted to connect. Families still wanted access. What changed was the infrastructure model underneath the outcome.

That shift matters because businesses often confuse today’s delivery model with permanent reality. They spend on the current system as if it were the only possible one. Then a new model arrives and makes yesterday’s investment look less like an asset and more like a drag.

That is the real story here. Not telephones. Not cloud. Not AI in isolation.

Capital allocation.

Where money was spent. Why was it spent there? And what happens when the model changes?

The Problem

Most organizations do not miss the future because they are foolish. They miss it because the current operating model still appears rational from the inside.

A landline company could defend every mile of copper it laid.

An enterprise with a private data centre could defend every rack, every cooling system, every network switch, every backup strategy, and every operations team.

A software department with thirty people, layered approvals, sprint rituals, and long release cycles can still defend its structure today.

Each of these systems made sense when the bottleneck was what the system was designed to relieve.

That is the trap.

The moment the bottleneck shifts, the entire cost structure must be reinterpreted.

What used to be prudent now looks heavy.

What used to be necessary begins to look inherited.

What used to be a moat begins to look like ballast.

Historical Context and Existing Approaches

For most of the twentieth century, communications meant fixed infrastructure. The network reached the person through a physical line build-out. That required exchanges, maintenance, installation crews, and last-mile reach into homes and businesses.

Mobile did not eliminate infrastructure. It changed the form of it. The economics moved toward towers, radios, spectrum, and handsets. The important point is not that the infrastructure disappeared. It is that a new infrastructure model changed the cost of access and the speed of expansion.

That mattered especially in countries that never built out large fixed-line networks. In parts of Africa, mobile adoption surged while fixed-line adoption remained low. The world did not stop needing communications infrastructure. It changed the form of the infrastructure required to deliver the outcome.

The customer side of that story matters even more than the carrier side.

The customer did not wake up wanting copper in the ground. The customer wanted a phone.

That distinction is easy to miss and hard to overstate.

People rarely want the infrastructure. They want the outcome that the infrastructure makes possible.

The same pattern showed up again in enterprise software.

For a long time, serious software meant internal infrastructure. Data centres. Servers. Storage. Power. Cooling. Disaster recovery. Network operations. Security layers. Backup systems. Internal support teams. A company that wanted a line of business applications often had to carry much of the machinery required to run them.

Then the cloud changed the frame.

Again, the business did not want racks. It wanted applications.

It wanted order processing, claims handling, billing, customer service, reporting, integration, workflow, and digital reach. The infrastructure burden had become part of the price of getting the outcome. Cloud changed that relationship.

Then, software teams did something important in response to business pressure. They changed how they worked.

Agile did not appear because developers suddenly fell in love with ceremonies. It emerged because organizations needed working software sooner, needed feedback sooner, and needed scope constrained tightly enough to inspect progress repeatedly.

That was a rational response to the production economics of the time.

Where Those Approaches Break Down

Here is where the old lesson starts to matter again.

Agile shortened the feedback loop. It did not remove the labour economics underneath the loop.

A sprint still assumed scarce human throughput.

The organization still assumed that analysis, design, implementation, testing, review, and release had to be paced around the rate at which humans could manually transform intent into code.

That assumption is now under pressure.

Not because AI is magical. Not because quality no longer matters. Not because software somehow writes itself.

Because the production boundary is moving.

Today, coding agents can already research repositories, assemble plans, modify code, run tests, and prepare work for human review. That does not mean software delivery becomes effortless. It means the economics of software production are no longer anchored to the same pacing assumptions.

The mistake many organizations will make is the same mistake made in previous transitions.

They will treat the new capability as an add-on inside the old operating model.

They will bolt AI onto a labour-centric delivery system and call that innovation.

That is like treating a mobile network as a nicer version of a landline.

It misses the point.

When the infrastructure model changes, the winning move is rarely to replace the old model. The winning move is to redesign around the new economics.

The Insight

This is where the story stops being about telecom and starts being about software production.

The real lesson of infrastructure history is not that technology gets better over time.

It is that each era quietly teaches us what the next era will stop paying for.

The world stopped paying for universal fixed-line build-outs as the default for personal communication.

Enterprises stopped carrying all runtime infrastructure as the default answer to business applications.

Now organizations will start paying less for slow, labour-bound software production as the default answer to digital change.

That does not mean expertise becomes irrelevant.

It means expertise moves.

The scarce resource is no longer keystrokes.

It is an architectural judgment.

It is context discipline.

It is deciding what should be built, in what order, with what boundaries, under what controls, and with what evidence that the result is safe to release.

AI does not remove the need for software architecture.

It raises the cost of weak architecture.

When execution accelerates, ambiguity scales with it.

So does waste.

So does rework.

So does plausible noise.

The New Service Surface

There is another downstream effect that matters just as much.

Infrastructure does not automatically own loyalty.

The wire company may have laid the line. The carrier may have carried the call. But the real winner is often the one that captures the customer’s daily use case.

That is why the smartphone changed so many industries at once.

People did not adopt smartphones because they wanted mobile banking. They adopted them because mobility changed the economics of connection. The device was always with them. It connected them to other people. That was enough to make the phone indispensable.

Then the service stack began to pile up.

Camera.

Maps.

Banking.

Payments.

Tickets.

Identity.

Messaging.

Authentication.

Flashlight!

At that point, the device stopped being just a phone. It became the place where services arrive.

That changes loyalty.

No one feels deep attachment to the company laying wire down the street if another player captures the experience, the interaction, the convenience, and the daily usefulness. The infrastructure provider risks becoming invisible. Necessary, but interchangeable.

That is the warning for every industry now.

AI plus mobile is not simply another feature combination. It is a new delivery surface with a new entry speed. When those two combine well, a competitor does not have to rebuild your whole value chain. They only need to capture the customer-facing layer where convenience, judgment, and utility converge.

That is how markets get taken.

Not always by replacing the full stack on day one.

By entering at the point of highest customer utility and then expanding outward.

The Proposed Model or Pattern

The next operating model for line of business software should be understood as a software production infrastructure.

Not tooling in the narrow sense.

Infrastructure.

That model has five parts.

Intent before implementation

The first job is to make the business intent precise enough that software can be produced against it rapidly. If intent is vague, faster execution only produces vaguer output at scale.

Architecture before acceleration

When software cycles compress, architecture becomes more valuable, not less. Clear boundaries, defined contracts, release criteria, and decision ownership stop speed from turning into confusion.

Agents as production capacity

Agentic AI should be treated as production capacity, not as a toy for individual developer convenience. If an agent can research, plan, modify code, and prepare reviewable work, then the organization is dealing with a new production unit.

Validation as the control layer

The faster software is produced, the more important validation becomes. Tests, review, observability, rollback discipline, and release gates serve as stabilizers for compressed execution.

Value as the buying unit

This is the mental shift most firms are not ready for.

If AI folds time, then time stops being a reliable buying unit.

The business should not think first in terms of hours, roles, and effort buckets. It should be thinking in terms of value delivered, risk reduced, and learning cycles completed.

Practical Application

This matters most in line-of-business applications because that is where software historically became heavy.

A request enters the business.

It becomes an analysis.

Then the backlog.

Then prioritization.

Then a sprint plan.

Then implementation.

Then test coordination.

Then review.

Then release scheduling.

Then deployment.

Then user feedback.

Then another request.

Every one of those steps was shaped by the assumption that production was scarce and slow.

Agentic AI does not erase those steps. It compresses several of them and forces the organization to decide which steps still deserve to exist in their current form.

That is the practical question leaders should be asking right now.

Not, should we use AI.

That question is already stale.

The better question is this.

If a meaningful slice of software work can now move from intent to reviewable implementation far faster than our current operating model assumes, which parts of our delivery system are still protecting value, and which parts are only protecting habit?

That is where real transformation begins.

Implications for Architects and Leaders

Architects need to stop thinking only about application architecture and start thinking about production architecture.

How does work enter the system?

How is intent stabilized?

How are agents directed?

How is context carried?

How are outputs validated?

How is release confidence established?

Leaders need to stop treating AI as a productivity perk and start treating it as a change in the economics of delivery.

That shift will alter budgeting, staffing models, release cadence, governance, and vendor expectations.

It will also change the market’s pricing pressure.

The company that can move from idea to releasable software far faster than its competitor is not merely operating more efficiently.

It is learning faster.

That matters more than coding faster.

Because markets reward organizations that reduce the time between insight and response.

Closing Perspective

Look up at the old wires, and the lesson is still there.

Every age builds the infrastructure it thinks it needs.

Then a new model arrives and exposes the old spend as history.

The landline era spent reaching the house.

The mobile era is spent reaching the person.

The on-premises era spent on hosting the application.

The cloud era is spent on consuming the application.

Now the next shift is underway.

Organizations will increasingly spend not only on where software runs, but also on how software is produced.

That is the frontier agentic AI is pushing into.

Not a better autocomplete box.

A different production model.

The companies that understand this early will not merely write code faster. They will reorganize capital, talent, architecture, and release discipline around a world in which software cycles compress sharply and repeatedly.

The rest will continue to fund yesterday’s bottlenecks.

And they will call that prudence right up until it becomes drag.

Continue the Conversation

The next competitive threat may not arrive as a better version of what you already know. It may arrive through a new service surface that captures the customer relationship before you realize the boundary has moved. That is what mobile did to many industries. AI will accelerate the same pattern. If you want to examine how your business can use AI before someone else uses it against you, I provide focused assessments and roadmap planning to help leadership teams identify where the market is shifting, where delivery is too slow, and what to do next.

Next week, I will move from theory to implementation and look at BackTheApp.software, a company building an AI-driven factory line for application delivery. It is based on a simple premise. If AI changes the production economics of software, then organizations need a new operating model for turning business intent into working applications quickly and with control. If that question is already pressing on your business, this is exactly the conversation I help leadership teams work through.

Industries often believe their structure is fixed until a competitor outside the traditional model arrives and defines the customer problem more accurately.

Uber did not win by owning the taxi network. Airbnb did not win by owning hotel inventory. Each gained ground by reframing the customer need and using technology to meet it in different ways.

The same risk exists in air travel. Airlines still tend to optimize around the seat, because the seat fits their internal economics. Travellers optimize their trip because it is what they are trying to complete.

When an industry defines value more narrowly than the customer does, it creates space for a challenger to come from over the horizon and take share by aligning more closely to the real objective.

That is the argument here. Airlines do not build durable loyalty by filling seats more efficiently. They build it by helping people complete trips well.

Introduction

Many companies still define their business by what they sell, bill for, and manage internally. That sounds reasonable. It is also where the problem begins.

An airline will often behave as if its product is a seat. Revenue management, route economics, fare classes, ancillary fees, boarding groups, and cabin density all reinforce that view. The organization learns to optimize the economics of moving occupied seats through a network.

The passenger experiences something else entirely.

The passenger is not buying a seat as an isolated unit of value. The passenger is buying a trip. The trip begins before boarding. It includes booking, clarity, comfort, timing, baggage, disruptions, recovery, arrival in a usable state, and arrival with their luggage. It includes whether the journey feels manageable, fair, and worth repeating.

That difference matters more than many companies admit. When the business defines its service more narrowly than the customer defines the outcome, optimization begins to undermine loyalty. The company improves what it measures internally while slowly weakening what the customer remembers externally.

This is not only an airline problem. It is a general business problem. Airlines make it easy to see. They provide one of the clearest examples of what happens when the internal unit of revenue becomes smaller than the customer’s unit of value.

This article examines that gap. It argues that airlines do not primarily compete on seats, even when their systems suggest they do. They compete on the quality and coherence of the trip. When they forget that, loyalty becomes fragile.

The Problem

The problem is not that airlines want to make money from seats. Of course they do. The problem is that the seat becomes the dominant design constraint while the trip becomes secondary.

Once that happens, decisions that look rational inside the airline begin to look irrational from the passenger’s point of view.

Reducing leg room is a useful example. Internally, the logic is clear. More seats increase revenue potential per aircraft. The plane becomes more productive. Unit economics improve. The decision fits the management model.

From the passenger’s perspective, the logic reverses. The journey becomes less comfortable. Fatigue increases. Stress rises. The experience becomes less desirable even if the flight still arrives on time.

The airline has improved the economics of the seat while degrading the quality of the trip.

That is not a minor difference. It reveals a structural misunderstanding of where value lives.

Passengers do not usually evaluate airlines by asking whether the airline extracted more yield from the aircraft. They ask whether the trip felt worth it. Would they choose the carrier again? Would they trust it for a longer route, a family holiday, a business meeting, or a tightly connected itinerary? Would they recommend it without apology?

A narrow service definition pushes the organization toward local optimization. A broader definition of customers reveals whether those optimizations are destructive.

This is where many discussions about loyalty go wrong. Companies often treat loyalty as a marketing outcome. They speak about brand preference, points programs, promotions, and retention campaigns. Those things matter, but they arrive later. Loyalty begins much earlier, at the point where the company decides what business it is really in.

If an airline believes it is in the business of selling seats, then it will optimize seat economics. If a passenger believes they are buying a trip, then they will judge the airline by trip quality. When those definitions diverge, the relationship weakens.

How the Industry Arrived Here

This narrow framing did not appear by accident. Airlines operate capital-intensive businesses. They manage fleets, routes, gates, crews, fuel costs, maintenance schedules, labour constraints, regulatory requirements, and intense pricing pressure. They have strong reasons to think in units that are measurable, controllable, and financially precise.

Seats fit those who need.

Seats can be priced, forecast, segmented, upgraded, discounted, bundled, and compared. Seats align with route planning. They align with inventory systems. They align with yield management. They align with the dashboards executives review.

This made sense. It still does, to a point.

The problem is not that airlines built operational models around the seat. The problem is that many organizations quietly allowed the operational model to become the strategic model. The thing that was easiest to manage became the thing that defined the business.

That pattern appears far beyond aviation. Banks organize around products even though customers live their financial lives. Telecom firms organize around service lines even though customers experience connectivity. Healthcare organizations organize around departments even though patients experience continuity of care. In each case, the company defines value in terms of internal accountability. The customer defines value according to the outcome they are trying to achieve.

The airline example is especially revealing because the mismatch is so easy to understand. The seat is not meaningless. It is simply incomplete. It is a component of the trip, not the trip itself.

Once a company mistakes the component for the whole, it begins making technically rational yet relationally damaging decisions.

Where the Seat Model Breaks Down

The seat model breaks down wherever the customer experiences the airline as a sequence rather than as a transaction.

A trip is not one moment. It is a chain of moments. The passenger moves through planning, purchase, preparation, check-in, airport navigation, boarding, in-flight experience, arrival, baggage recovery, and onward movement. Without their luggage, the trip is not complete, even if the aircraft landed exactly on schedule. If something goes wrong, the trip also includes disruption handling and recovery. The airline may break these into separate systems and teams. The passenger does not.

This is where narrow service definitions begin to impose hidden costs.

A tighter seat pitch might improve aircraft economics, but it worsens the physical experience of the journey.

A fee that makes sense in a pricing model might feel punitive in the context of an already stressful trip.

An efficient boarding process for gate control might still feel chaotic or unfair.

A delay message that satisfies an internal communication requirement might still leave the passenger uninformed.

A missed connection handled in accordance with policy might still undermine confidence in the airline.

Each decision can be defended locally. The relationship is damaged cumulatively.

This is the central issue. Companies often optimize moments. Customers remember sequences.

An airline can be operationally competent at many individual points and still produce a poor trip. In fact, this is common. The airline may hit internal targets for turnaround time, seat utilization, ancillary revenue, and policy compliance. Yet the customer still leaves feeling handled rather than served.

That matters because trust does not form through isolated transactions. It forms through repeated experiences of coherence. The passenger asks, often without saying it aloud, whether this airline helps me complete trips well. Not whether it sold me a ticket. Whether it helps me travel well.

When the answer becomes no, loyalty does not disappear all at once. It thins. The customer becomes more price sensitive. More willing to switch. Less forgiving of mistakes. Less open to premium offers. Less likely to advocate for the brand. The financial signal appears later. The relational weakening happens first.

The Real Insight

The deeper insight is simple.

Airlines do not earn loyalty by transporting bodies efficiently. They earn loyalty by helping people complete trips well.

That is a different business definition.

It changes what leaders measure. It changes what architects design for. It changes what product teams optimize. It changes which operations are treated as success.

Once the trip becomes the real unit of value, many familiar industry habits start to look incomplete.

Cabin design is no longer only a density problem. It becomes part of a journey quality problem.

Communication is no longer merely an information-delivery problem. It becomes part of a confidence problem.

Baggage is no longer only a logistics problem. It becomes part of a continuity, dignity, and trip completion problem.

Disruption handling is no longer only a policy problem. It becomes part of a trust recovery problem.

This shift matters because it repositions loyalty from the edge of the business to its middle. Loyalty stops being something the marketing team tries to stimulate after the fact. It becomes a consequence of whether the organization consistently supports the customer’s real objective.

That objective is not to occupy a seat.

It is to complete a trip.

This is where many executives need to be more direct with themselves. A company does not become customer-centric because it says the customer matters. It becomes customer-centric when it defines its service in terms of the customer’s goal rather than the company’s operational context.

For airlines, that means moving from seat thinking to trip thinking.

A Better Model: Define Service at the Level of the Customer Objective

If the trip is the real product, then the business needs a different model.

The first change is conceptual. The company must define service in terms of the customer’s objective. In aviation, the customer’s objective is not merely to be flown. It is arriving in the right place, at the right time, in the right condition, with enough confidence and continuity that the journey feels successful, and with their luggage.

That broader definition creates a more honest frame for decision-making.

The airline should ask questions like these.

• Does this decision improve the trip, or only improve a local metric?

• Does this policy reduce effort for the passenger, or merely shift effort onto them?

• Does this change make the journey feel more coherent or more fragmented?

• Does this recovery process restore confidence, or only close the case operationally?

• Does this pricing decision feel fair in the context of the whole trip?

Those questions sound simple. They are not. They force the organization to evaluate decisions based on relational consequences, not just operational efficiency.

A trip-based model also changes where measurements should be taken.

Instead of relying only on lagging metrics such as churn, loyalty program engagement, or post-flight satisfaction, the organization should look for signals of relational strain inside the trip itself. Rebooking friction. Repeated clarification requests. Escalation frequency. Complaint clustering around fairness. Disruption handling drop-off. Baggage continuity failure. Effort accumulation across touchpoints.

These are not minor service details. They are early evidence that the organization’s design is drifting away from the customer’s objective.

A trip-based model also exposes the weakness of treating business units as independent customer realities. The passenger does not care which team owns the app, the boarding process, the baggage flow, or the disruption desk. Those divisions are internal. The trip is external. It is experienced as one journey, one relationship, one test of competence.

That means the company needs more than efficient departments. It needs relational coherence.

Practical Application for Airlines

An airline that took the trip seriously would begin to evaluate decisions differently.

It would still care about cost and utilization. It would still aggressively manage network economics. But it would stop pretending that maximizing seat efficiency is the same as maximizing customer value.

The cabin strategy would change first. The question would no longer be limited to how many passengers fit. It would include the degree of compression that begins to damage the trip enough to weaken long-term preference.

Service design would also change. Instead of treating each touchpoint as a separate function, the airline would treat the passenger journey as one managed sequence. Booking, alerts, check-in, seat assignment, boarding, baggage, and recovery would be judged by whether they preserve continuity.

Disruption handling would become central rather than peripheral. A delayed or cancelled flight is not merely an operational exception. It is a defining trust event. The same is true when the passenger arrives, but their luggage does not. Passengers remember how the airline behaves when the journey breaks. Recovery quality often matters more than routine efficiency because it reveals whether the company sees the passenger as a problem to route or a trip to restore.

Pricing would also be viewed differently. Airlines have every right to segment services and monetize optionality. The issue is not whether extra services cost more. The issue is whether the pricing model fractures the trip so aggressively that the passenger feels nickel-and-dimed, constrained, and managed rather than helped. Once that happens, the company has improved revenue extraction while weakening relationship quality.

This is the key practical point. A trip-based model does not forbid monetization. It disciplines it. It asks whether the business is monetizing in ways that support the journey or quietly degrade it.

Share The Business Advantage Blog

What This Means Beyond Airlines

The airline example matters because it reveals a pattern shared by many sectors.

Businesses often define value in terms of what they control. Customers define value according to what they are trying to achieve.

The bank thinks in accounts. The customer thinks in budgets.

The telecom provider thinks in service lines. The customer thinks of reliable communication and perhaps secure living.

The insurer thinks in policies and claims categories. The customer thinks in recovery and protection.

The hospital thinks in departments. The patient thinks in care.

The website thinks in menus. The visitor thinks in intent.

In every case, loyalty is constrained by the same mistake. The company draws the service boundary too narrowly. It organizes around the thing it sells rather than the outcome the customer is pursuing.

That creates a hidden ceiling. The company may still perform well for a time. It may even grow. But its loyalty model remains fragile because it is built on a partial understanding of value. Customers stay while conditions are convenient. They leave when alternatives reduce friction, improve coherence, or more clearly respect the broader objective.

This is why a customer-centred strategy requires more than better messaging. It requires a harder question.

What business are you really in from the customer’s point of view?

If the answer differs sharply from your internal design, then your loyalty problem may have started long before marketing ever touched it.

Implications for Architects and Leaders

Leaders should take this seriously because the issue is not cosmetic. It affects what gets funded, measured, and optimized.

When a company defines its service too narrowly, every team inherits the same distortion. Finance pushes for the wrong efficiency. The product improves the wrong features. Operations enforces the wrong policies. Technology integrates the wrong boundaries. AI learns the wrong objective function.

That last point is becoming more important.

AI systems will optimize for the signals organizations provide. If the system is trained to improve yield, it will improve yield. If it is trained to reduce service cost, it will reduce service cost. If it is trained only around narrow transactional metrics, it will accelerate narrow transactional behaviour.

It will not protect loyalty unless loyalty has been defined in operational terms that reflect the customer’s real objective.

For airlines, that means the trip must become visible as a measurable design object. Not a slogan. Not an aspirational brand idea. A real operating concept.

Architects should care because this is a boundary problem. The customer experiences one journey. The enterprise is built with many systems. The work of architecture is not only integration between applications. It is the design of coherence across the sequence that the customer actually lives through.

Executives should care because this is a strategy problem. A company that optimizes a narrower unit of value than the customer cares about is leaving advantage on the table. It is inviting competitors to win not by inventing a new market, but by defining the existing one more truthfully.

Closing Perspective

Airlines make the lesson visible because the mistake is so easy to name.

They think they sell seats. Passengers buy trips.

Once that distinction is clear, the broader business implication becomes hard to ignore. Companies weaken loyalty when they define service around internal containers rather than customer outcomes. They improve local efficiency while degrading the lived experience of value.

The issue is not whether operational excellence matters. It does. The issue is whether operational excellence is pointed at the right object.

A seat is part of a trip. It is not the trip. A product line is part of a relationship. It is not the relationship. A department is part of an enterprise. It is not the customer’s experience of it.

The companies that endure will be the ones that define their business at the level of the customer’s real objective. They will still manage costs. They will still optimize operations. But they will refuse to confuse what is easy to measure with what is most important to protect.

In aviation and far beyond it, loyalty does not come from serving the company’s definition of value more efficiently.

It comes from serving the customer’s definition of value more honestly.

For organizations that want to understand where those definitions collide in the real world, the useful signal is often not the complaint alone. It is the emotional event underneath it. The moment the customer’s lived objective runs into the company’s narrower design. That is where relational weakening begins. Capturing those moments, systematically and at scale, is part of what CustomerGravity.cloud is built to explore.

Organizations are deploying AI to optimize internal systems.

Speed increases. Automation increases. Analytics improve.

Yet one dimension of business performance remains largely unmeasured.

The strength of the relationship between people and the organization.

For two decades, companies relied on Net Promoter Score as a proxy for this relationship. NPS reduced a complex human experience to a single number. The score indicates movement but rarely explains the events that produced it.

That limitation existed because organizations lacked the infrastructure to capture structured relational signals.

That constraint is now disappearing.

Agentic AI enables the capture and structuring of relational signals generated during real interactions between people and organizations.

This capability introduces a new category of business infrastructure.

Relational Intelligence Signal Ecosystems (RISE).

RISE systems capture structured relational signals and transform them into measurable indicators of relational strength.

The goal is straightforward.

Detect the rising temperature before the organization becomes the frog in the pot.

Introduction

Organizations measure many aspects of performance, yet one critical dimension remains largely invisible.

Financial systems measure revenue, margins, and cost control. Operational systems measure throughput, reliability, and delivery speed. Marketing systems measure impressions, engagement, and conversions.

These systems generate enormous volumes of data.

Yet none of them measure the strength of the relationship between people and the organization.

Most companies infer relational health indirectly through lagging indicators such as declining engagement, reduced purchasing activity, or customer churn.

By the time these indicators appear, the relationship has already deteriorated.

RISE systems attempt to measure this missing dimension directly.

RISE captures structured signals that reveal how trust and expectations evolve across interactions between people and institutions.

If this category matures, it introduces a new measurement layer for modern organizations.

A layer focused on relational dynamics rather than operational activity.

The Structural Problem

Organizations lack a reliable system for measuring relational strength.

Most tools measure consequences rather than relational movement itself.

Customer satisfaction surveys collect feedback after an interaction occurs. Response rates remain low, and insights arrive long after the experience that generated them.

Net Promoter Score attempts to simplify relational measurement with a single question about the likelihood of recommendation. The metric provides directional insight but compresses complex relational dynamics into one number.

Social listening platforms monitor public conversations across digital networks. These systems observe reactions once experiences become public discourse.

Review platforms follow the same pattern. Reviews capture reactions after experiences occur and emphasize reputation rather than structured relational insight.

These approaches share a common limitation.

They measure reaction rather than relational movement.

The relationship changes first.

The metrics respond later.

The Emergence of RISE

Relational Intelligence Signal Ecosystems (RISE) attempt to close this measurement gap.

RISE systems capture relational signals as interactions occur rather than collecting opinions long after the experience.

Each interaction between a person and an organization contains an implicit comparison.

Expectation meets reality.

This moment produces a relational signal.

When captured in structured form, these signals become analyzable data.

A RISE ecosystem aggregates relational signals across thousands or millions of interactions. Patterns begin to emerge that traditional systems cannot detect.

Trust erosion becomes visible earlier.

Positive reinforcement becomes measurable.

Relational friction can be traced to specific operational behaviours.

The result is a new measurement layer focused on relational strength.

Design Requirements for RISE Systems

For RISE to function effectively, several structural capabilities must be in place.

Structured Signal Capture

Relational signals must be captured in a structured form.

Free text feedback introduces ambiguity and limits comparability. Structured relational signals enable analysis across large datasets.

Signal Taxonomy Governance

Signals require consistent classification.

A shared taxonomy ensures relational signals are categorized using a common vocabulary. Without governance, relational data becomes fragmented and difficult to analyze.

Trust Event Modelling

Each relational signal should describe three elements.

What occurred.

What was expected.

How the experience affected trust.

This structure converts individual experiences into measurable trust events.

Signal Weighting

Not all signals carry equal importance.

Minor friction should not carry the same weight as a major breach of trust. Signal weighting allows RISE systems to distinguish between small inconveniences and structural relationship damage.

Cross-Sector Comparability

If RISE becomes a meaningful measurement layer, organizations must be able to analyze relational patterns across industries.

Comparability enables benchmarking and broader relational insight.

Platforms Exploring the RISE Category

Several types of platforms address parts of this emerging ecosystem.

Each approaches relational insight from a different perspective.

Customer Experience Platforms

Customer experience systems analyze internal workflows and customer journeys.

These platforms improve operational processes that influence experiences but primarily measure operational performance rather than relational strength.

Social Listening Platforms

Social listening platforms monitor public conversations across digital networks.

They identify sentiment patterns and reputation risk after events become visible in public discourse.

These tools capture signals after relational events have already propagated outward.

Reputation Monitoring Platforms

Reputation monitoring platforms track ratings, reviews, and brand perception.

They provide insight into public visibility and perception, but rarely capture structured relational events in real time.

RISE Platforms

A smaller category of systems focuses on the capture of relational signals itself.

RISE platforms attempt to capture structured trust signals directly from interactions between people and organizations.

These signals form the foundation of a relational measurement layer.

Platform Focus: CustomerGravity.cloud

CustomerGravity.cloud represents an implementation aligned with the RISE model.

The platform focuses on capturing relational signals directly from individuals and structuring them into trust events.

Each signal describes a moment where expectations encountered organizational behaviour.

Signals are categorized and weighted to generate a measurable indicator of relational intensity between people and institutions.

CustomerGravity does not replace operational or financial analytics.

Instead, it introduces a complementary measurement layer.

A relational layer that observes movement in trust before traditional performance indicators respond.

If reliable relational telemetry becomes available, organizations may gain early insight into shifts in loyalty, emerging dissatisfaction, and long-term brand stability.

Strategic Implications of RISE

If RISE mature as a category, several strategic implications emerge.

Enterprise Governance

Executives gain visibility into relational deterioration before financial signals appear.

Early detection allows organizations to intervene before trust erosion becomes revenue loss.

AI Training Inputs

Artificial intelligence systems require structured signals to produce meaningful analysis.

RISE signals provide rich training inputs that describe how human expectations interact with organizational behaviour.

Experience Design

Organizations gain the ability to design systems based on measurable relational signals rather than retrospective survey results.

Operational improvements can be guided by real relational telemetry.

Corporate Strategy

Relational strength may emerge as a strategic metric alongside revenue and operational efficiency.

Organizations that manage relational dynamics effectively may develop durable competitive advantages.

Open Questions

Several challenges remain as the RISE category evolves.

Measurement Consistency

Can relational intensity be measured consistently across organizations and industries?

Reliable measurement requires disciplined taxonomies and signal weighting models.

Signal Ownership

Relational telemetry introduces questions of ownership.

Customers, organizations, and independent platforms all have interests in how relational signals are captured and used.

Governance Models

Neutral governance frameworks may be required to maintain trust in relational measurement systems.

Without governance, relational telemetry risks becoming another proprietary analytics layer controlled by individual vendors.

Adoption

The success of RISE systems depends on both organizational participation and individual contributions to signals.

Without sufficient signal volume, relational measurement will struggle to produce reliable insights.

Closing Perspective

Business infrastructure evolves when organizations recognize that an important dimension of performance remains invisible.

Financial accounting introduced the first measurement layer for modern organizations.

Operational analytics introduced a second layer focused on efficiency and throughput.

RISE represent the potential emergence of a third layer.

A measurement system focused on the strength of the relationship between people and institutions.

Whether RISE becomes widely adopted remains uncertain.

What is clear is that organizations continue to operate without reliable instrumentation for their most important asset.

Trust.

Without measurement, the temperature rises unnoticed.

And companies slowly become the frog.

Built for Search, Not for Listening

Is your website listening, or is it waiting to be found?

If your homepage opens with a hamburger menu in the top corner, your digital architecture was designed for discovery through search, not for understanding intent.

That small icon is not cosmetic. It represents a structural assumption: the company defines the categories, and the visitor must navigate them before expressing what they actually want.

Artificial intelligence is not moving at a normal pace in the market. It is entering industries at a velocity most executive teams have never experienced.

Adoption curves that once took years are now compressing into months. Behavioural habits are shifting faster than strategic roadmaps. Competitive advantages that felt durable are being questioned in real time.

When ChatGPT from OpenAI entered the market, it did more than introduce a new interface. It challenged the behavioural default that sustained Google’s dominance for two decades. Google had world-class AI research. Google had infrastructure. Google had distribution. What it did not have in market form was a conversational interface that redefined how users expressed intent.

That gap allowed a startup to reshape expectations before the incumbent moved decisively. If a company with Google’s resources can be strategically surprised, no organization should assume insulation from similar disruption.

This is not a commentary on who has the best models. It is a business warning about structural assumptions. Most companies have embedded assumptions about how customers arrive, how they navigate, and how demand is captured. Those assumptions were rational when designed. They may now be liabilities.

The question for executives is direct: What structural assumptions inside your digital presence are about to be exposed?

Why Corporate Websites Were Originally Built

To understand the risk, it is necessary to revisit the original purpose of corporate websites.

Corporate sites were not designed as intent engines. They were designed as broadcast platforms.

Their core objectives were clear and logical for their time. They were designed to accomplish the following:

• Establish legitimacy and brand credibility

• Publish information about products and services

• Organize offerings into clear categories

• Support search engine discoverability

• Capture leads through structured forms

This architecture reflected the economics of the search era. Attention flowed through search engines. Ranking determined visibility. Navigation trees mirrored the internal organizational structure. Conversion happened after a visitor self‑segmented into predefined buckets.

The company defined the taxonomy. The visitor adapted.

This model was effective because it aligned with how the internet functioned. Search engines index pages. Users clicked links. Websites guided movement through hierarchical menus. Data about visitor behaviour was inferred from page paths and conversion events.

Nothing about this was careless. It was optimized for the existing environment.

The problem is not that corporate websites were poorly designed. The problem is that they were optimized for a discovery mechanism that artificial intelligence is beginning to intermediate.

When the mechanism of discovery changes, the architecture built around it becomes exposed.

The Structural Assumptions Embedded in the Traditional Model

The hamburger menu is not a design trend. It is an architectural signal.

It reflects a series of embedded assumptions about how demand works.

First, it assumes the company defines the structure of the problem. Products, services, industries, solutions. The taxonomy mirrors internal organization charts more than customer intent.

Second, it assumes the visitor can correctly classify themselves. They must decide whether they belong under Product, Solutions, Industries, Resources, or Support before they express what they want.

Third, it assumes intent can be inferred from behaviour. Page paths, time on site, downloads, and form submissions become proxies for meaning.

Fourth, it assumes friction is acceptable. Navigation depth, gated assets, and multi-step funnels are treated as normal costs of qualification.

These assumptions were efficient when search engines were the primary gateway. The user arrived through a keyword. The site completed the segmentation.

The structure made sense because discovery happened outside the organization.

Artificial intelligence changes that equation.

When the point of entry becomes conversational, the visitor no longer adapts to the company’s taxonomy. They state intent in their own language.

The company’s navigation tree is optimized for classification.

A conversational interface is optimized for customer declaration.

That distinction is subtle. It is also strategic.

Where the Model Begins to Break

The traditional website model begins to fracture under three pressures: complexity, speed, and intermediation.

Complexity increases first.

As organizations expand, product lines multiply. Service variations grow. Geographic and industry segmentation deepens. The navigation tree expands to reflect internal scale. What was once a simple structure becomes layered and dense.

The customer experience does not scale at the same rate.

Visitors arrive with cross-cutting problems. They do not think in product categories. They think in outcomes. When the navigation forces them to translate their problem into the company’s structure, friction rises.

Speed becomes the second pressure.

AI-native competitors reduce the time between question and answer to seconds. Traditional corporate journeys still rely on content exploration, gated downloads, demo requests, and follow-up calls. The gap between expressed interest and meaningful response widens.

In markets where attention is short and switching costs are low, delay is eroded.

The third pressure is intermediation.

Search engines once delivered traffic directly to corporate sites. Increasingly, AI systems answer questions before users even visit a site. If the first answer is generated elsewhere, your website becomes a secondary reference rather than the primary destination.

At that point, the navigation tree is no longer the entry point. It is an internal artifact.

This is where competitive risk emerges.

When customers express intent inside an AI system, and that system learns faster than your organization, the advantage shifts to whoever captures and refines that intent signal first.

The traditional website was built to organize information.

The emerging competitor is built to organize demand.

The AI Interface Model: An Inversion of Structure

AI-native companies did not begin by redesigning navigation. They began by redesigning the entry.

The interface is deceptively simple. One input surface. One conversational loop. No visible taxonomy.

The simplicity hides a structural inversion.

Instead of asking the visitor to choose a category, the system invites the visitor to declare intent in natural language.

Instead of inferring meaning from click paths, the system processes meaning directly from text.

Instead of routing a visitor through predefined funnels, the system adapts the response in real time.

Behind that single text box sits an intent architecture composed of several reinforcing components:

• Classification pipelines that detect topic and task type

• Context tracking across sessions

• Feedback loops that refine responses

• Model routing that balances cost and performance

• Continuous learning from aggregate interactions

This architecture does not treat interaction as marketing telemetry. It treats interaction as product input.

Every question strengthens the system.

Every interaction improves future performance.

This is the inversion.

Traditional corporate sites are optimized for presenting information.

AI-native systems are optimized for the accumulation of intent.

One broadcasts structure.

The other absorbs demand.

When viewed through a business lens, this is not a user experience trend. It is a competitive capability shift.

The Strategic Insight: Intent Is the New Competitive Surface

The visible difference between a corporate website and an AI interface is minimal. The structural difference is profound.

The previous competitive era rewarded organizations that mastered distribution through search. Traffic acquisition, keyword dominance, and funnel optimization were the primary levers of growth.

The emerging era rewards organizations that capture, structure, and learn from explicit intent.

This shift changes what creates defensibility.

In the search era, the advantage came from:

• Ranking above competitors for high-value queries

• Owning category language through content volume

• Driving traffic into optimized conversion funnels

In the intent era, advantage comes from:

• Capturing raw customer questions before they are categorized

• Structuring those questions into reusable intelligence

• Reducing the time between expressed need and meaningful response

• Continuously improving the system based on real interactions

This is not about replacing marketing. It is about redefining the layer where competition occurs.

If discovery increasingly happens inside AI systems, the organization that owns structured intent data will outperform the organization that owns structured web pages.

The strategic implication is direct.

Websites built primarily to present information are assets of the search era.

Systems built to accumulate and refine intent are assets of the next one.

The Executive Question: What Happens When AI Owns First Contact?

The executive risk is not technological. It is positional.

If customers begin expressing their needs within AI systems before visiting your site, the first layer of interaction shifts out of your control.

When that happens, several consequences follow.

First, brand influence weakens at the moment of need. The AI interface becomes the interpreter of your value proposition.

Second, demand data becomes fragmented. The most valuable signals about customers’ questions, frustrations, and emerging needs come from outside your organization.

Third, response speed becomes benchmarked against AI-native standards. Waiting for a form submission and a follow-up call feels slow in comparison to an immediate, context-aware answer.

This creates a new set of executive-level questions.

• Who owns first contact with the customer when AI intermediates discovery?

• Where is structured intent data captured, stored, and analyzed?

• How quickly can the organization respond to unstructured demand signals?

• Is the current digital architecture designed to learn, or only to present?

These are not marketing questions. They are competitive positioning questions.

If an AI-native startup can challenge a dominant search incumbent by redefining interaction, a focused competitor in your industry can challenge you by redefining demand capture.

The issue is not whether AI will affect your sector.

The issue is whether your organization adapts before the new interaction model becomes the default expectation.

What Must Change: From Navigation Architecture to Intent Architecture

Adapting does not require replacing your website with a chatbot. It requires rethinking the architectural purpose of your digital presence.

The shift begins by changing what the organization believes creates value at first contact.

The question is no longer only “Why you?” as a brand statement.

The deeper question becomes:

Why did this person engage with your organization at this moment, and why are you responding in the way that you are?

When intent is captured directly, the organization gains visibility into motivation, urgency, sophistication, risk tolerance, and desired outcome. This enables something more powerful than segmentation. It enables adaptive interaction.

Most corporate sites are optimized to present structured information.

An intent-oriented digital presence is optimized to understand the individual behind the request and adapt accordingly.

That shift has structural implications. It requires organizations to introduce new capabilities into their digital layer. At a minimum, this includes the following:

• Direct intent capture surfaces that allow visitors to express needs in natural language

• Classification systems that structure raw questions into actionable categories and detect contextual signals

• Telemetry pipelines that treat interactions as strategic intelligence rather than marketing exhaust

• Response frameworks that adapt tone, depth, and framing based on detected customer profile and situational context

• Routing mechanisms that connect expressed intent to the correct internal owner in real time

• Feedback loops that continuously refine both the substance and the style of response based on outcomes

These capabilities move the organization beyond static messaging.

They allow the company’s personality to interact intentionally with the visitor.

A cautious procurement lead requires a different interaction pattern than an entrepreneurial founder. A stressed operations manager requires a different response than a researcher exploring options.

When intent architecture is in place, the organization does not merely answer questions. It adapts its posture.

This is not personalization in the marketing sense. It is situational alignment in the operating sense.

Marketing, product, and technology functions must align around learning from demand and expressing a coherent organizational personality across interactions. Silos organized around product lines must become responsive to cross-cutting customer problems and contextual signals.

This is not a cosmetic redesign. It is a repositioning of how the organization listens and speaks.

The companies that treat intent capture and adaptive response as infrastructure will increase satisfaction, strengthen trust, and improve competitive resilience.

Closing Perspective: The Menu Is a Signal

The hamburger menu is not the problem.

It is the signal.

It signals an era in which companies organized information and asked customers to find themselves within it.

That era produced enormous value. It rewarded those who mastered search, optimized funnels, and controlled distribution.

A new era is emerging.

In this one, customers express intent directly. They expect immediate understanding. They expect responses aligned with their context, their urgency, and their level of sophistication.

The competitive advantage shifts from who organizes information best to who understands intent fastest.

This is not a prediction about interface design.

It is a statement about market structure.

If your digital presence is built primarily to broadcast, you are competing on presentation.

If your digital presence is built to capture, structure, and adapt to intent, you are competing on intelligence.

And intelligence compounds.

If it can happen to Google, it can happen to any incumbent that assumes its distribution layer is secure.

The companies that redesign their digital architecture around intent, adaptive response, and coherent organizational personality will not simply look modern.

They will be structurally positioned for the next competitive cycle.

Continue the Conversation: Is Your Organization Listening?

If this argument feels uncomfortably accurate, the next step is not a redesign.

It is a strategic conversation.

Most executive teams cannot clearly answer three questions:

• Where does customer intent first enter the organization?

• How is your unique value proposition expressed in live interactions, not in brand copy?

• Is your company responding with a coherent personality, or with fragmented departmental voices?

These are not design questions.

They are positioning questions.

If you want to examine whether your digital architecture is built for search or for intent, book a focused discussion.

https://schedule.callrichard.direct

The objective is simple.

To determine whether your organization is listening at first contact.

Most Digital Transformation initiatives optimize systems but never validate the customer relationship across organizational boundaries.

This post introduces the Relationship Integration Test, a governance discipline that begins at intent capture. It separates the Operational Layer from the Relationship Layer and argues that the first question an organization asks a customer is the primary integration boundary.

If the enterprise can interpret intent without exposing internal silos, preserve context across divisions, and reduce accumulated effort, relational coherence improves.

If relational coherence improves consistently, the natural question follows: What does that mean for customer loyalty over time?

Introduction: From Diagnosis to Design

In the previous post, we established a structural omission in most Digital Transformation initiatives. Enterprises modernize systems, integrate platforms, and automate workflows. They pass internal integration. Yet they rarely validate whether the customer relationship remains coherent across divisions.

If we accept that diagnosis, the next question becomes unavoidable.

What would a relationship integration test actually look like?

It does not begin in architecture diagrams. It does not begin in a steering committee. It begins at the moment of contact.

The First Question Is the Boundary

A useful contrast clarifies the point. Consider the rise of AI chat interfaces. The entire user experience is often reduced to a single text box. No routing tree. No departmental segmentation. No product-first navigation. Just one prompt.

Why does this work? Because the system is designed to interpret intent before mapping to execution. The burden of translation sits with the system, not the user.

Now consider how many enterprises would accept exposing a single text box as their primary entry point. Most would hesitate. Internally, they would argue that routing precision would suffer, that departments require separation, and that policy enforcement demands structure.

Yet customers accept the text box immediately because it reflects how they think. They arrive with intent, not with organizational categories.

The lesson is not that every enterprise should replace its interface with a chatbot. The lesson is architectural. When intent interpretation precedes operational routing, relational coherence improves.

Every time an organization forces the customer to select a pillar before expressing intent, it exposes internal structure before understanding the use case.

That is where the integration boundary is either strengthened or weakened.

Every organization has a version of this exchange.

Why are you contacting us today?

On the surface, this is a routine operational step. It enables routing. It determines queue assignment. It aligns the inquiry with the appropriate execution pillar.

Structurally, this is the most important integration boundary in the enterprise.

The customer arrives with intent. The organization responds with structure.

The Relationship Integration Test lives in that translation.

If the customer must learn your org chart to be understood, the test fails.

If the organization interprets intent only within departmental definitions, the test fails.

If context resets when the issue crosses internal boundaries, the test fails.

This is not a failure of courtesy. It is a failure of architectural design.

Operational Layer and Relationship Layer

To understand why this boundary matters, we must separate two layers that most organizations conflate.

Operational Layer

The Operational Layer governs how the enterprise runs—systems, processes, policies, automation, reporting lines, and budgets.

Relationship Layer

The Relationship Layer governs how the enterprise is experienced over time: intent capture, context continuity, perceived fairness, accumulated effort, and recovery coherence.

The operational layer can be technically correct and still produce relational incoherence.

A billing system may reconcile perfectly. A support workflow may meet SLA targets. A CRM may contain accurate records.

Yet the customer experiences fragmentation.

The Relationship Integration Test validates the second layer, not the first.

It asks a disciplined question.

When a customer presents a use case, can the enterprise translate it into execution without fragmenting the relationship?

The Use Case, Not the Department

When customers contact an organization, they do not arrive as product holders or departmental units. They arrive with use cases.

I was charged twice. My service stopped working. I need to upgrade. I cannot log in.

These are expressions of intent, not references to organizational structure.

Most Digital Transformation initiatives optimize routing efficiency. They ask how quickly they can move this inquiry to the right pillar.

The Relationship Integration Test asks a different question.

Can the enterprise interpret and convey intent across pillars without placing the burden of translation on the customer?

That is the difference between internal optimization and relational coherence.

Why This Test Was Never Written

The omission is structural.

Product teams optimize within product boundaries. Operations optimize process throughput. IT optimizes system integration. Finance optimizes cost allocation.

No function is accountable for validating the coherence of the relationship across boundaries.

So the first question the organization asks is designed for internal clarity, not relational continuity.

This is not a moral failing. It is a governance gap.

What the Organization Must Consider

When a customer stands in front of the enterprise and answers the question; “Why are you contacting us?”, leadership should be able to ask:

• Are we prepared to interpret intent beyond departmental definitions?

• Do we preserve context when execution crosses pillars?

• Do policies feel consistent across services?

• Does effort accumulate or reset with each transfer?

• Do we treat this individual as a single relationship or as multiple accounts?

These are not call centre questions. They are architectural questions.

If the organization cannot answer them with confidence, it has not written its relationship integration test.

The Implication for Transformation

When intent capture becomes a deliberate integration boundary, Digital Transformation changes character.

Release criteria expand beyond internal readiness. Architecture decisions account for context continuity. Success metrics begin to include relational stability.

The transformation charter shifts from efficiency alone to durability.

The Question That Follows

If the Relationship Integration Test begins to pass consistently, if intent is understood, context preserved, and effort reduced across divisions, what does that mean for customer loyalty?

If loyalty is behaviour over time, does relational coherence become its leading indicator?

In the next post, we will examine whether relational coherence can be measured, whether it produces observable shifts before churn appears, and whether loyalty is less a marketing outcome and more an architectural consequence.

Call to Action

Before moving to metrics, consider your own organization.

When a customer makes contact, does your first interaction reveal your internal structure, or does it absorb it?

If you consistently passed the Relationship Integration Test at intent capture, would your customers behave differently over time?

If the answer is yes, then loyalty may not be a branding problem. It may be an integration problem.

If the Relationship Integration Test begins to pass consistently, if intent is understood, context preserved, and effort reduced across divisions, what does that mean for customer loyalty?

If loyalty is behaviour over time, does relational coherence become its leading indicator?

That is the question we will examine next.

Digital Transformation programs typically modernize systems, integrate data, and deploy AI. They optimize internal execution. They rarely treat the customer experience across the full enterprise as a design constraint. As a result, organizations improve operational performance without explicitly measuring whether customers find the organization clearer, fairer, or easier to deal with over time.

How Digital Transformation Is Typically Scoped

Most Digital Transformation programs focus on improving how the organization operates rather than how it is experienced by customers.

They modernize systems. They move to the cloud. They integrate APIs. They deploy analytics and AI. They redesign workflows.

These efforts are necessary. Many are well executed.

But the customer experience of the transformation is typically not considered.

An enterprise exists because of customers. Revenue, valuation, and long-term viability depend on sustained relationships. Yet Digital Transformation initiatives are often defined, funded, and governed without customers as direct participants in the design.

Projects are scoped around system integration, data consolidation, process efficiency, and technology modernization. Internal stakeholders populate steering committees. Success metrics emphasize cost reduction, uptime, throughput, and adoption.

Customers are studied through research and analytics, but they are rarely treated as architectural actors whose lived experience defines whether transformation has achieved its purpose.

The result is that Digital Transformation can become a program focused on improving the organization rather than on the relationship that justifies the organization’s existence.

Digital Transformation frequently improves how the organization runs internally. It does not always examine whether customers find the organization clearer, fairer, and easier to deal with over time.

Execution Inside, Experience Outside

Large enterprises are structured around product lines, operational units, and financial accountability. This structure enables scale and control.

Consider the telecommunications vertical more broadly.

Large telecom enterprises are typically structured across distinct service domains such as mobile, residential internet, enterprise connectivity, and security services.

Each domain operates with its own systems, targets, budgets, and modernization agenda. A Digital Transformation program may upgrade billing in one unit, automate provisioning in another, and deploy AI-enabled service automation in a third.

From an internal perspective, this is progress.

From a customer perspective, these divisions do not exist.

Customers do not experience separate service domains. They experience a single provider relationship.

Consider a common scenario. A customer calls a telecommunications provider because their service is not working. The automated system responds with options such as:

• Press 1 for Business services

• Press 2 for Mobility

• Press 3 for Residential internet

• Press 4 for Security

The segmentation makes sense internally. Different systems, teams, and revenue lines must be managed.

From the customer’s perspective, the intent of the call is simple. Something is not working. They do not think in terms of organizational structure. They think in terms of their phone number, their home, or their account.

Before they can even describe the issue, they must navigate the company’s internal design correctly.

This is a small but revealing example. The need for separation is corporate. The experience of separation is customer-facing.

A billing issue in one area can influence the perception of the entire company. A service disruption in one product line affects confidence in others.

The enterprise is segmented for management efficiency. The relationship is unified for the customer.

A similar structure exists in banking.

Large institutions typically operate across:

• Retail banking

• Commercial banking

• Wealth management

• Credit and lending

Each domain modernizes independently. Retail improves its mobile app. Commercial accelerates underwriting. Wealth adds AI advisory tools. Credit refines risk scoring.

Each initiative may be successful on its own terms.

Yet the customer evaluates the bank as one institution. A rigid credit decision influences confidence in wealth management. A change in retail fee structure affects perceptions of commercial fairness.

Optimization occurs inside units, trust forms across the whole.

This difference between internal execution and external perception is rarely modelled explicitly in Digital Transformation design.

A Telecom Illustration

Consider a large telecommunications provider undertaking a Digital Transformation initiative.

The program may focus on:

• Modernizing billing platforms

• Migrating legacy systems to the cloud

• Automating service provisioning

• Integrating CRM and support tools

• Deploying AI-driven call deflection

Each of these efforts improves internal execution. Systems become faster. Costs decline. Data becomes more unified. Operational metrics improve.

Yet the customer experience of a telecommunications provider is often defined by a range of variables.

• Clarity of pricing

• Transparency of contract terms

• Fairness of policy enforcement

• Simplicity of resolving issues

• Consistency across services

A company may modernize its infrastructure and still leave customers uncertain about bills, confused by service changes, or frustrated by cross-divisional inconsistencies.

In this case, Digital Transformation has improved how the organization operates. It has not necessarily improved how the relationship feels.

The distinction is subtle but significant.

Operational modernization strengthens internal performance. Relational durability depends on how the enterprise is experienced as a coherent whole.

Many Digital Transformation programs improve execution. Fewer explicitly redesign or instrument the relational model.

The Missing Layer in Transformation Design: The Customer

What many transformation programs lack is a structured way to understand how customers experience the organization before financial consequences arise.

It is not limited to surveys or sentiment analysis. It is the disciplined measurement of how stable the relationship is becoming over time.

Most enterprises already measure extensively.

They track:

• Revenue growth and margin

• Churn and retention

• Engagement and usage

• Net Promoter Score

• Social sentiment after amplification

These indicators are important. They are also mostly reactive.

They surface after behaviour shifts. By the time churn rises or public dissatisfaction becomes visible, relational strain has already accumulated.

Customer experience signals exist inside the organization but are fragmented.

• Repeated policy exception requests

• Cross division complaint themes

• Escalation clustering

• Fee dispute frequency • Service rigidity indicators

These signals are rarely aggregated across product lines. They are rarely categorized as relational risk. They are rarely elevated to executive visibility.

Operational performance is engineered and monitored in real time. Financial performance is governed with precision. Relational durability is often inferred.

The result is that Digital Transformation modernizes systems without explicitly measuring whether trust is strengthening or weakening.

AI and the Acceleration of Bias

This gap becomes more significant as AI is embedded into core operations.

AI systems optimize according to the data and objectives provided.

If trained on efficiency metrics, they optimize efficiency. If trained on engagement metrics, they optimize engagement. If trained on revenue yield, they optimize revenue yield.

Without structured trust signals, AI cannot protect relational durability.

A pricing engine may increase margin while increasing perceived unfairness. A recommendation engine may increase usage while reducing confidence. A service automation tool may reduce cost while increasing frustration.

The system performs well in line with its objectives. The relationship may weaken according to a different standard.

As optimization accelerates, unmeasured relational drift can compound faster than before.

The Architectural Blind Spot

Digital Transformation programs commonly include:

• Cloud migration

• API and integration strategy

• Data consolidation

• Process automation

• Customer journey redesign

• AI deployment

These efforts focus on making the organization faster, more integrated, and more scalable.

They do not always include a layer that measures relational durability across divisions.

Experience design improves moments. Trust forms across sequences of moments.

Relational erosion usually accumulates quietly through inconsistent policy application, pricing opacity, fragmented communication, and algorithmic rigidity.

These are cross-functional effects. They do not neatly fit into a single division.

Without a structured way to measure how customers experience the organization across divisions, the enterprise has no integrated view of cumulative relational strain.

Digital Transformation strengthens execution inside the organization.

It does not automatically strengthen the relationship outside it.

A Forward Looking Question

Enterprises treat financial volatility as a board-level concern. They model risk exposure and stress test scenarios.

What would change if relational drift were treated with similar discipline?

What would system design look like if relational durability were measured as carefully as operational latency or revenue variance?

Digital Transformation has largely focused on internal coherence and performance.

The next evolution may require equal attention to how the organization is experienced as a unified relationship.

If modernization improves execution but leaves relational durability unmeasured, can it truly be called transformation?

Marketing still optimizes for distribution. That solves reach. It does not create customers.

FreeWater demonstrates how efficiently advertising can fund a physical product at scale. Their business model does not address the ongoing relationship with the individual who picks up and uses the bottle.

Social platforms refined this pattern. They built audiences first. Advertisers followed. Creators were paid (a small portion). Platforms kept ownership of the customer.

The next shift elevates the customer to first-class status. Ad revenue becomes the first product delivered to them. Not the only one.

This post is intended to educate and spark a conversation about revenue diversification, innovation, and its application to product promotion and marketing.

Who is the customer

The discussion starts with a simple question.

Who is the customer?

Read more

All content asks for commitment.

The only difference is how much.

A blog post asks for seconds or minutes.

A landing page asks for trust.

A meeting asks for time and reputation.

Joseph Sugarman built persuasion for high-commitment decisions without interaction.

Donald Miller helped popularize clarity and orientation for distracted web audiences.

Most modern content optimizes for one or the other.

Rarely both.

When the goal is conversation, not email capture, structure must earn attention and persuasion must earn time.

In this post, I will combine these ideas and reflect on how content, including blog posts and landing pages, can move readers up the commitment ladder toward a meeting.

Read more

A Shift in How I Work

Over the past few months, my day-to-day work has shifted significantly.

Not because the problems became simpler. They did not.

The shift came from how I approach building software and the amount of material I now review each day.

I am working inside a workflow where iteration speed feels fundamentally different. Design decisions move forward faster. Experiments cost less effort. Feedback arrives earlier. The result is not faster typing. It is faster thinking.

The most surprising outcome has been the reduction in cognitive load. Complex systems no longer demand full mental rehydration every time I return to them. Context stays intact. Decisions accumulate instead of resetting. This alone changes how ambitious a project feels on day one.

Review as the Primary Learning Loop

A large part of this comes from reviewing code, which is faster than writing code or specifications. I now read far more code than I write. Patterns emerge quickly when you review hundreds or thousands of lines per day across multiple domains. You see repetition. You see friction. You see where structure holds and where it collapses. Over time, judgment sharpens. Architecture stops being abstract and starts feeling mechanical in the best sense.

Learning Through Iteration, Not Study

This workflow also reshapes how learning happens. Instead of studying tools in isolation, learning happens as you solve real problems under real constraints. Each iteration compounds. Each review reinforces intuition. Expertise grows through exposure, not memorization.

Measurable Changes in Productivity

The productivity gain is measurable. Fewer false starts. Fewer dead ends. Shorter feedback loops. More parallel progress. The effect feels less like optimization and more like a change in operating model.

What I Am and Am Not Sharing

I am not ready to share internal details or specific mechanics yet. Those ideas are still forming. What I am comfortable sharing is the direction. This is a paradigm shift in how I work. It has changed how I scope projects, estimate effort, and reason about risk.

Considering a Workshop Format

I am considering turning this into a virtual workshop. Not a tool demo. Not a slide deck. A working session focused on mindset, workflow, and decision patterns. The goal would be to help others reduce cognitive load while increasing output on complex systems.

If this is of interest, leave a comment. Let me know what would matter to you.

Some prompts to guide responses.

• Preferred session length
  Short and focused or extended and hands-on.

• Audience background
  Architecture, product, engineering, leadership.

• Format preference
  Live build, guided walkthrough, or structured discussion.

• Primary goal
  Productivity, learning speed, system quality, or decision clarity.

I am still shaping this. If you are curious, add a comment or message me. A brief note on what you want to explore helps determine whether this becomes a focused session or a deeper workshop.

Executive Framing (TLDR)

APIs fail when meaning hardens into routes and versions. Each new path increases coupling and coordination cost.

CloudEvents-style envelopes move meaning into the message. Routes stay stable. Schemas evolve independently. Consumers adapt at their own pace.

If your API represents business facts rather than CRUD operations, design it around events. Keep HTTP as transport. Put intent in the envelope.

Introduction

Most APIs still look the same.

They grow by adding routes. They grow by adding versions. Coordination costs rise as teams encode behaviour into URLs instead of messages.

Version numbers move into paths. Resources bend to fit routing structures. Clients learn behaviour by memorizing endpoints.

This approach feels natural because it aligns with HTTP. Over time it creates structural drag. The API becomes coupled to its routing surface instead of the meaning of what occurs in the business.

There is an alternative. Keep routes stable. Move meaning into the message. CloudEvents-style envelopes enable this shift.

This post compares both approaches and explains why envelope-first APIs create systems that last longer and adapt faster.

The Problem with Route-Centred API Design

Route-based APIs encode meaning in the URL.

Examples are familiar.

• POST /v1/orders

• POST /v2/orders

• POST /customers/{id}/orders

• POST /orders/submit

• POST /orders/submit-v3

Each path implies semantics.

• Which version applies

• Which behaviour executes

• Which payload shape is expected

As change accumulates, teams add routes rather than evolve meaning.

How Coupling Creeps In

When meaning lives in the path, coupling becomes unavoidable.

• Routing logic grows complex

• Versioning becomes structural

• Clients hardcode URLs

• Infrastructure reflects business logic

A small change forces updates across gateways, clients, documentation, and tests. The route becomes a long-lived contract surface that resists change.

This is not an HTTP limitation. It is a modelling decision.

Why This Pattern Made Sense

Route-centric APIs grew from REST and CRUD thinking.

• Resources map cleanly to nouns

• URLs appear descriptive

• HTTP verbs feel expressive

For data retrieval, this works. For business processes, it strains. Businesses react to facts.

• An order was placed

• A payment failed

• A shipment was delayed

These are events, not resources. Routes struggle to express them cleanly.

Where Route-Based APIs Break Down

As systems scale, several stress points appear.

Version Explosion

Minor changes trigger new routes.

• New fields

• New rules

• New processing paths

Teams fork endpoints instead of evolving schemas.

Behavioural Drift

Similar routes behave differently. The path alone does not reveal impact. Clients rely on documentation or tribal knowledge.

Tight Client Coupling

Clients must know exactly where to send each message. URLs encode assumptions that limit flexibility.

A Different Mental Model: Event Envelopes

CloudEvents-style APIs separate transport from meaning.

Routes stay simple.

• POST /events

• POST /publish

• POST /ingest

The message explains itself.

An event envelope carries metadata such as type, source, version, and schema. The receiver reads intent from the message, not the path.

What Changes When Meaning Moves into the Message

Stable Routes

Routes no longer encode version or behaviour.

• Infrastructure remains stable

• Gateways stay simple

• Version churn disappears from URLs

Explicit Semantics

Each event declares what happened and how to interpret it. Behaviour becomes visible and auditable.

Schema Evolution Without Routing Changes

Schemas evolve through identifiers.

• com.company.order.created.v1

• com.company.order.created.v2

The route stays unchanged. Consumers choose what they support.

Practical Comparison

Route-Based Approach

Client behaviour:

• Choose a URL

• Select a version

• Shape payload for that route

Server behaviour:

• Route selects controller

• Controller implies behaviour

• Version branching spreads across code

CloudEvents-Based Approach

Client behaviour:

• Emit an event

• Set type and schema

• Send to a stable endpoint

Server behaviour:

• Receive event

• Inspect envelope

• Dispatch by event type

One model encodes intent structurally. The other declares intent explicitly.

Architectural Benefits

Loose Coupling

Producers publish facts. Consumers decide how to react. Knowledge boundaries remain intact.

Event-Driven Alignment

Events represent things that occurred. This mirrors real business flow.

Easier Client Adaptation

Clients add support for new versions incrementally. URLs remain untouched.

Improved Observability

Event streams form natural audit trails.

• What happened

• When it happened

• Who published it

Where This Matters Most

Envelope-first APIs excel when.

• Multiple consumers exist

• Behaviour evolves independently

• Automation or AI reacts to change

• Systems cross organisational boundaries

Integration platforms and partner APIs benefit early.

How to Adopt a CloudEvents-Based API

This shift does not require reworking existing systems.

Step 1: Introduce a Stable Event Endpoint

Create a single ingestion route such as POST /events. Keep it unchanged.

Step 2: Wrap Existing Payloads

Encapsulate current data inside an event envelope. Preserve existing schemas while adding metadata.

Step 3: Dispatch by Event Type

Replace route-based branching with event-type dispatch. Version handling becomes explicit.

Step 4: Evolve Schemas, Not Routes

Introduce new versions through schema identifiers. Let consumers opt in.

The Architectural Takeaway

APIs fail when meaning hardens into routes and versions. Each new path increases coupling and coordination cost.

CloudEvents-style envelopes move meaning into the message. Routes stay stable. Schemas evolve independently. Consumers adapt at their own pace.

If your API represents business facts rather than CRUD operations, design it around events. Keep HTTP as transport. Put intent in the envelope.

Seeing This Model in Practice: SignalWeaver.cloud

SignalWeaver.cloud applies this envelope-first approach to real integration problems.

Instead of exposing partner-specific APIs with brittle routing and version rules, SignalWeaver accepts business events through stable ingestion endpoints. Each event declares its type, source, and schema in the envelope. The platform routes, audits, enriches, and distributes events based on meaning rather than URL structure.

This allows organizations to:

• Publish business facts once and reuse them across systems

• Add new subscribers without changing producers

• Evolve event schemas without breaking integrations

• Treat events as first-class business telemetry

SignalWeaver is not a replacement for your systems. It sits alongside them, turning existing activity into a coherent stream of business signals.

Call to Action

If this architectural shift resonates, the fastest way to explore it is through a short conversation.

I work with architects, product leaders, and executives to:

• Assess where routing and versioning are creating hidden friction

• Identify events already present in your systems

• Map a practical path toward envelope-based integration

You can book time directly at: Free Booking Calendar

Come with a real problem. We will keep it practical.

In the traditional software development model, the primary bottleneck has often been the speed at which a human can write code. However, the industry is currently undergoing a fundamental shift: the challenge is no longer how to write code faster, but how to manage an electronic partner effectively.

This new paradigm treats software development not as a manual construction project, but as a masterpiece of orchestration. When we shift our focus from line-by-line coding to high-level intent, we unlock a level of productivity that was previously impossible.

The Process: Architecture as the Orchestral Score

To understand this new way of working, consider the analogy of writing a song. The most difficult part of songwriting isn’t the physical act of writing notes; it is deciding what the song is trying to say and where the attention belongs.

In this model, Architecture is the score. It is written before the code and consists of:

• Defining Intent: Clearly deciding what the software is meant to accomplish.

• Setting Boundaries: Establishing clear contracts and sequencing for the work.

• Managing Complexity: Deciding where complexity belongs and where work remains routine.

Once this “score” is clearly defined, the actual execution—the “verses and chorus”—follows naturally. AI agents act as the musicians, executing their specific parts within the constraints provided by the architect.

The Exponential Impact on Speed and Productivity

The reason this method leads to exponential gains is that it enables parallel execution across multiple agents (when done correctly). Unlike traditional development, which is often linear, this model allows for massive scaling of execution.

1. Scaling Execution, Not Just Labour: Because AI agents work in parallel within defined constraints, the volume of usable code produced increases significantly.

2. Moving Architecture Upstream: By moving the architectural phase “upstream,” the focus shifts to guiding execution before testing even begins. This reduces the risk of producing “plausible noise” and ensures the output is functional and coherent.

3. Focusing on the Result, Not the Goal: The architect focuses on the high-level business problem, allowing domain rules, edge cases, and persistence to follow as a result of the clear intent.

A New Role for the Developer

This shift is not about replacing developers; it is about elevating them. The developer’s role is evolving into that of a conductor or architect, ensuring the “musicians” (the AI agents) play in harmony. By clearly defining the intent and constraints, the developer ensures the final “song”—the software—is exactly what the business needs.

In this new era, intent must lead because execution scales. The faster we can define the score, the faster the orchestra can play.

The difficulty is not model selection or platform choice. The difficulty is understanding where AI should participate in the business, identifying a suitable starting point, and proceeding without introducing unnecessary cost, risk, or architectural debt.

Executives often frame the problem as an AI problem. In practice, it is a visibility and learning problem. Leaders have questions they cannot answer with confidence, or answers arrive weeks later through manual analysis, spreadsheets, and reports assembled after the fact. By the time insight appears, the moment for action has passed.

The corrective step is to stop starting with AI. The more effective starting point is the unanswered business question.

Those questions already map to business events. Business events are factual state changes that occur inside workflows. They signify something that has happened. When treated as first-class signals, they form a continuous telemetry feed of organizational activity.

Today, many organizations process this telemetry using legacy patterns. Data is extracted, reconciled, summarized, and reviewed periodically. This approach is slow, labor-intensive, and disconnected from real-time decision-making. It reflects tooling limitations rather than business intent.

This blog post explains why reframing integration around business events creates a safer and more practical entry point for AI. It explains why event-first thinking reduces integration cost, accelerates learning, and allows AI to participate incrementally without destabilizing core systems.

The sections that follow first focus on why organizations struggle to get started. Only then do they address what changes when events become the foundation for integration.

Why Early AI Initiatives Stall

Organizations seeking to integrate AI into operational workflows often encounter resistance well before the model’s capabilities become relevant. Friction occurs at the integration boundary. Teams quickly discover that meaningful AI use requires far more than prompts and endpoints. It requires a surrounding ecosystem that supports safety, traceability, and control.

Early pilots tend to succeed in isolation. They fail when moved closer to real business activity. The cost and risk profile change as experimentation transitions to operational integration.

The problem is not access to models. The problem is the absence of a low-cost, reversible way to connect AI to real business signals.

The Hidden Cost of the AI Ecosystem

The first serious investment is rarely the model. It is the infrastructure required to make AI participation safe and governable.

The following costs appear early and compound quickly.

• Integration plumbing
• Security and identity
• Audit and traceability
• Triggering mechanisms
• Error handling and retries
• Observability
• Governance
• Partner coordination

Each item represents work that must exist before an agent is trusted with even limited authority. These are not optional concerns. They are prerequisites for operating AI inside a business environment.

This is why many AI initiatives pause or reset after early demonstrations. The organization is forced into a platform built before it has learned what it needs.

From API-First to Event-First Thinking

Most integration strategies still begin with APIs. APIs work well when consumers are known, stable, and tightly coordinated. They degrade as the number of consumers grows and ownership boundaries expand.

The traditional integration pattern follows a predictable sequence.

1. Build an API

2. Teach consumers how to use it

3. Handle consumer-specific logic and exceptions

4. Repeat for every new consumer

This model exposes operational mechanics. Every consumer must understand structure, timing, and failure behaviour. The producer becomes responsible for supporting an expanding surface area of dependencies.

Why APIs Struggle With Agentic Execution

AI agents require clear triggers and bounded authority. Operational APIs provide neither by default.

Several issues surface quickly.

• APIs expose mechanics rather than intent

• Consumers must infer meaning from structure

• Agents embedded into APIs increase blast radius

• Rollback becomes operationally expensive

When AI logic is embedded directly into production APIs, experimentation and operations collapse into the same risk envelope. Learning slows because change becomes costly.

Business Events as a Safer Integration Primitive

A business event represents a factual state change. It records something that already happened. It does not request an action or assume a response.

Examples of concrete business events include.

• OrderPlaced

• PaymentFailed

• InvoiceOverdue

• ShipmentDelayed

• AppointmentBooked

• AccessRevoked

• DeviceOffline

These events are already implicit in systems, logs, and support processes. Treating them as first-class integration signals allows reactions to evolve independently from the systems that produce them.

Business events reduce coupling by separating the declaration of a fact from the decision of what to do about it.

SignalWeaver.Cloud as Signal Infrastructure

SignalWeaver.Cloud is a SaaS platform designed to publish business events and manage subscriptions to those events. It provides a governed signal layer between systems and reactions.

SignalWeaver.Cloud focuses on infrastructure concerns that are repeatedly rebuilt inside organizations.

• Publisher identity and ownership

• Subscription governance and access control

• Delivery tracking and observability

• A default internal subscriber for recording and visibility

SignalWeaver.cloud does not replace internal systems. It does not execute business logic. It does not orchestrate workflows. Its role is to make business signals durable, observable, and governable.

This distinction matters. SignalWeaver.cloud reduces experimentation costs without forcing an architectural commitment to a full AI platform.

Learning Without Modifying Core Systems

Event-first integration enables learning without destabilizing production.

Key properties of this approach include.

• Publishers remain unchanged as subscribers evolve

• Subscribers are independently deployable

• Events can be real or intentionally simulated

• AI participation can begin in passive mode

An AI subscriber can observe, classify, and recommend without executing. Authority is introduced only when confidence exists, and boundaries are defined.

This allows organizations to learn under constraint rather than speculation.

Common Misconceptions

Several misunderstandings often appear early and distort design decisions.

• SignalWeaver.cloud is not an AI platform

• SignalWeaver.cloud is not a workflow engine

• SignalWeaver.cloud does not require broad data access

• SignalWeaver.cloud does not impose vendor lock-in

Events remain portable. Subscribers remain independent. Operational systems remain authoritative.

Model Context Protocol in Context

Model Context Protocol defines how tools and capabilities are exposed to AI agents. It does not automatically convert APIs into safe agent interfaces.

Effective MCP design requires intent.

• Tools represent business capabilities

• Inputs define scope and constraints

• Execution remains auditable and authorized

MCP shifts interaction away from endpoint mechanics toward bounded capability access.

How SignalWeaver.cloud and MCP Work Together

SignalWeaver.cloud provides the trigger and governance layer. MCP provides the tool interface layer. Operational APIs remain the source of truth.

Agents sit outside core systems. They react to events and act only through approved tools.

This separation preserves control while enabling incremental automation.

Concrete Example Flow

Business Event: InvoiceOverdue

Publisher

A finance system publishes InvoiceOverdue when an invoice crosses a defined threshold. The event contains identifiers and a minimal operational context.

Subscribers

Human-oriented subscriber

A finance operations queue receives the event and opens a review task. A person evaluates context and decides the next steps.

AI-oriented subscriber

The AI subscriber begins in passive mode.

• Classifies the overdue invoice

• Summarises relevant account history

• Recommends a follow-up approach

No write actions occur.

Controlled Execution Through MCP

Over time, limited tools are introduced.

• GetInvoiceDetails

• DraftReminderEmail

• CreateFollowUpTask

Each tool enforces boundaries. Authority expands only with evidence.

Cost Control Through Reversibility

This architecture controls cost by limiting commitment.

• No early platform build

• Minimal change to core systems

• Clear rollback by removing subscribers

• Measured expansion of authority

Learning occurs through constrained experiments rather than irreversible design decisions.

A Practical Starting Sequence

An organization can begin within days by following a disciplined sequence.

Select one operational business event:

1. Define a minimal event contract

2. Publish the event as a side effect

3. Enable internal recording and visibility

4. Add one human subscriber

5. Add one AI subscriber in observer mode

6. Introduce bounded MCP tools

7. Review outcomes using delivery and audit data

I agree with the concern raised in the article, and I would go further. AI applied to business is the most disruptive economic force in history. More than the Industrial Revolution. More than electricity. More than the internet. Those shifts changed how work was done. AI changes who is required to do it. It compresses the cost of research, synthesis, and recall to near zero, then leaves humans to decide what matters and what to do next. Fewer people now produce outcomes that once required teams, and this shift targets high-wage cognitive roles first on timelines measured in quarters.

Disruption does not mean disappearance. When automobiles emerged, blacksmiths did not vanish overnight. The skill remained useful, but its role, scale, and economic weight changed permanently. Society adapted without a master plan because demand reorganized around new constraints. AI presents a similar inflection, but faster and broader. The question is not whether work ends. The question is how income, demand, and contribution rebalance while the transition is still underway.

This is where Universal Basic Income (UBI) enters the conversation. We saw a version of this during COVID. Faced with sudden mass unemployment and widespread paycheck-to-paycheck dependency, governments injected cash to stabilize society. That intervention was necessary. Without it, desperation would have turned quickly into unrest, food insecurity, and breakdowns in basic order. The goal was not long-term help or productivity. It was containment during shock.

AI-driven disruption risks creating a similar inflection point. As individuals equipped with AI become far more productive, many roles will appear redundant in the short term. Layoffs are a likely transitional response. In that environment, UBI reappears as a blunt stabilizer rather than a growth strategy. The problem is mistaking an emergency brake for a steering wheel. Long-term reliance weakens incentives and strains funding, as COVID supports have already been signalled by reduced participation and slower rehiring. This is not ideology. It is an observed behaviour.

The real issue is leadership under extreme time compression, not politics and not panic. AI is advancing faster than institutions, companies, and education systems can adapt. There is not enough time to retrain everyone simultaneously, and pretending otherwise creates false confidence. In fast transitions, simplistic answers flourish. They offer temporary reassurance, then fail quietly before moving on. That pattern benefits no one.

What is required is visible leadership and honest modelling. How pricing shifts as productivity rises. How demand expands when services become cheaper. How humans assisted by AI scale work rather than disappear from it. If those models exist, leaders should make them visible. If they do not, assuming stability emerges on its own is not optimism. It is an abdication of leadership responsibility.

To a human, a hallucination means perceiving something that isn’t there. It’s an error of the mind. But for a large language model (LLM), a hallucination isn’t a malfunction. It’s a natural outcome of doing exactly what it was built to do: generate the next most probable word based on the data and context it was given.

In other words, what we call a mistake might actually be the system performing perfectly within its own rules.

Coherence vs. Correctness

Humans measure truth by how well a statement aligns with reality. Models measure success by how coherent their next token is with the previous ones.

When an LLM “hallucinates,” it’s not breaking a rule — it’s following one. It’s optimizing for linguistic probability, not factual accuracy. The gap between those two is where the hallucination lives.

Think of it this way: the model doesn’t retrieve knowledge from a database. It constructs knowledge based on patterns it learned during training. What appears to be a confidently stated fact is, in reality, a beautifully composed guess.

That’s not a bug. It’s the core design.

The Source of Hallucination

Inside the model, meaning isn’t stored as facts but as relationships — vast webs of semantic proximity between words, ideas, and contexts. When prompted, the model navigates this internal geometry to find the most probable continuation of a thought.

Most of the time, this works astonishingly well. But occasionally, that semantic navigation drifts: the model chooses a path that sounds right in language space yet doesn’t exist in the real world. That’s semantic drift — the root of hallucination inside an LLM.

It’s not the model “making something up.” It’s the model following a pattern that statistically fits, even when that pattern misrepresents truth.

Why We Call It an Error

Humans and machines don’t share the same objective functions. When you ask a model a question, you want truth or relevance. When it answers, it wants fluency and coherence.

Those goals only align some of the time. The rest of the time, we see hallucination — not because the model is broken, but because our intent wasn’t fully expressed in a way the model could follow.

We think the model misunderstood us. In reality, we didn’t specify the contract clearly enough.

The Real Problem: Misaligned Intent

Hallucinations are a mirror. They reflect our assumptions about how intelligence should behave.

An LLM doesn’t “know” what you mean — it predicts what people like you tend to mean when using similar words. That’s a subtle but powerful distinction. When its learned context doesn’t match your mental model, it fills the gap with probability — not truth.

So when leaders talk about “eliminating hallucinations,” what they’re really talking about is intent alignment: designing systems where human purpose is encoded as clearly as possible in the model’s context.

What This Means for Business Leaders

If you’re deploying AI in your organization, don’t dismiss hallucinations as simple errors to be “fixed.” Treat them as symptoms of unclear communication between human and machine.

Every hallucination is data — evidence of where intent and design diverge. The more we study those moments, the closer we get to systems that truly understand context, not just language.

In the future, the best AI systems won’t just predict text; they’ll interpret intent. And the best organizations will be the ones that design for that difference, instead of denying it.

Takeaway: A hallucination isn’t a system failure — it’s a signal that alignment still has room to improve. The fix isn’t better syntax. It’s better intent design.

Coming Next — Part 2

When Hallucinations Have Context: RAG’s Fragile Anchor How retrieval-augmented systems shift hallucinations from language to data — and what that means for trust, governance, and system design.

Want more insight like this?

Follow TheBusinessAdvantage.blog on Substack for weekly essays on how technology, architecture, and business strategy intersect to create lasting advantage.

It’s not just about more sales. It’s about smarter, more stable streams of income that deepen the customer relationship, and in many cases, redefine it.

One of the clearest examples comes from an unlikely source: a television show about unexplained phenomena in the Utah desert.

When Curiosity Becomes Currency

Skinwalker Ranch isn’t just a show. It’s a business model experiment hiding in plain sight.

For $12 a month, fans can join the Skinwalker Ranch Insider community, gaining access to live feeds, behind-the-scenes research, and private discussions. It’s more than a fan club. It’s a subscription-based research network, funded by individuals who believe in the mission and want to participate .

Every member isn’t just watching; they’re contributing. They fund the investigation, share ideas, and form a community around a shared sense of discovery. That curiosity becomes currency , a recurring revenue stream built on belonging.

The Strategic Advantage Few Businesses See

When executives talk about diversification, they often think of new products or markets. Rarely do they think of community as a profit centre.

Yet, when built with intent, a community becomes both a revenue stream and a defensive moat.

· It creates emotional switching costs.

· It generates insight loops that improve products.

· It aligns engagement with growth.

Think of Tesla’s referral network or Peloton’s instructor-led culture; each turns participation into a flywheel.

This idea isn’t limited to entertainment or technology. It also appears in everyday commerce.

The Costco Example: Turning Membership into the Moat

Costco flipped the traditional retail model on its head. Instead of relying on high product margins, it earns most of its profit from membership fees, rather than from the markup on goods.

That simple change does three things:

1. It aligns the company’s interests with the customer’s (low prices aren’t a gimmick; they’re the model).

2. It creates predictable, recurring revenue that doesn’t depend on daily sales.

3. It builds a psychological and financial moat; people renew because they belong to Costco, not just because they shop there.

And the moat doesn’t end at the checkout. Costco’s partner network of services, insurance, travel, home installation, and optical care extends that same relationship outward. Each partner pays for access to Costco’s trusted member base, creating a second layer of revenue: referral income built on loyalty.

The Architecture of Belonging

The businesses that win aren’t just selling access; they’re architecting belonging.

· Disney does it with D23 memberships and exclusive drops.

· Patreon lets creators transform free content into paid intimacy.

· Costco monetizes membership over merchandise.

· Skinwalker Ranch turns viewers into stakeholders.

In each case, the product is the relationship, and technology amplifies it.

What Leaders Can Learn

Whether you run a SaaS platform, a consultancy, or a brick-and-mortar business, the principle holds:

1. Treat customers like a community, and your community like customers.
Engagement is no longer linear. Every interaction can deepen a sense of belonging and generate revenue.

2. Monetize access, not just output
Memberships, early access, or insider privileges often yield higher margins and stronger loyalty than one-off transactions.

3. Invest in the infrastructure of belonging early
Build systems, digital or physical, that make customers feel known and valued.

4. Create partnerships that extend your ecosystem
Referral or affiliate programs can transform customer trust into shared growth.

5. Use software to scale participation
Membership apps, loyalty programs, and gated content platforms transform relationships into recurring revenue streams.

The Moat of Participation

Every business today competes for attention. The ones that endure will be those that convert that attention into alignment, and alignment into advocacy.

Revenue diversification isn’t about selling more things. It’s about creating more ways for people to belong.

From a ranch in Utah to a warehouse in Seattle, the pattern remains the same: businesses that treat participation as a profit-building strategy create moats that no competitor can easily cross.

The next competitive advantage isn’t scale or speed; it’s the depth of your customer relationship.

AI has changed how I approach that process. It gives me the freedom to follow my curiosity without judgment. I can explore an idea, test an assumption, or build a prototype on the spot. It’s not about memorizing answers. It’s about discovering new ones through doing.

The proudest thing I’ve done in my career isn’t tied to a title or a product. It’s using curiosity to solve problems that matter. The waste in advertising. The misuse of private data. The quiet trade of user consent to train models that later ignore privacy boundaries.

The Empowered Customer began as a response to those problems. It asked one question: what if data worked for people, not against them? SnapChingIQ put that question into motion, showing how customers could share in the value their data creates. ContentTraker.com extended this idea by giving people control over how AI interacts with their information, while maintaining security and privacy.

For me, learning by doing is the discipline that keeps ideas honest. It forces theory to meet reality. When you design systems that protect privacy or rebalance data ownership, you’re not just learning about ethics, you’re building it into the product.

AI should help people understand, decide, and act with confidence. It should never cross the line of trust.

That’s the business advantage that lasts.

It is worth remembering that the CEO who wrote this is likely not a technical leader. From his perspective, AI represents speed: faster iterations, fewer blockers, and a way to accelerate execution. Everything else, how AI actually works, where it is reliable, and where it is not, is secondary. CEOs are measured on outcomes, not architectures.

But here is the catch: before a human does anything, the framing and understanding of the problem is critically important. With or without AI, people often default into “solutioning” mode before they fully understand the context of the problem. That is why critical thinking skills remain essential. Critical thinking enables us to strip away assumptions, probe the boundaries of the issue, and clearly understand the context before jumping to conclusions.

AI does not replace this step. What it can do is support it. Just as we once celebrated the ability to use the internet (e.g. Google, Bing) to gather perspectives, we should now celebrate AI’s ability to do the same thing, only better. Instead of narrow keyword matches, AI can synthesize across vast domains, highlight connections, and surface how others have solved similar challenges. The scope is broader, the synthesis sharper, and the research faster.

In real estate, the mantra is location, location, location. Value is determined not by the building itself, but by its location. In business, when it comes to AI, the mantra should be context, context, context. Value is determined not by the output itself, but by how well it is grounded in the domain of the problem.

Why context matters more than output

Generative AI will happily produce a convincing answer. Without a grounding in the business context, the domain of the problem, the market constraints, and the nuances of customer expectations, the answer may be irrelevant, misleading, or even dangerous.

AI is at its best when it:

• Accelerates ideation by helping teams explore multiple pathways quickly.

• Sharpens the definition of the problem by reframing its expression.

• Assists in decision-making support rather than decision replacement.

The human layer of domain expertise

Leaders and strategists must provide the guardrails:

• Frame the business problem with critical thinking. AI should not set the agenda; it should help us interrogate it.

• Validate with judgment. AI’s confidence is not a proxy for truth. Business leaders bring experience, values, and a commitment to accountability.

• Leverage for scale, not abdication. When framed well, AI can scale insights, automate lower-value tasks, and create space for higher-order thinking.

Default to AI? Or default to context?

“Default to AI” overlooks the broader implication. The competitive edge is not in using AI everywhere; it is in knowing where and how to apply it. A company that applies critical thinking to frame its domain context, and then uses AI to extend that thinking, will outpace a competitor that blindly pushes buttons.

That is why the mantra is context. Just as location defines the relevance and price of real estate, context establishes the relevance and impact of AI-driven outcomes.

From the perspective of Solution Architecture, the role is about breadth of experience in solving business problems and knowing when and how technology should be applied. The Solution Architect ensures a given project is viable, aligned, and value-driven, avoiding the trap of documenting answers without knowing what is truly possible.

At the same time, Enterprise Architecture provides the broader context. If solution design is the building, enterprise architecture is the city plan. It sets the guardrails and principles that ensure every initiative ladders up to a coherent whole. It translates product strategy into operational direction, guiding AI initiatives so they compound rather than fragment.

The lesson for business leaders is clear: executives do not need to know how AI works. Just as SAP, often criticized as a poor ERP yet sold worldwide, is adopted without most leaders understanding its internals, AI does not require technical fluency at the top. What leaders need is clarity on how strategy, architecture, and now agentic AI come together to solve business problems.

That is the essence of The Business Advantage: applying technology thoughtfully, within a strategic and architectural framework, to solve the right problems.

Credit to: Bandan Singh of Productify for the inspiration of this post.

Git powers almost every software project today. It emerged from necessity. Linus Torvalds crafted it in weeks after the Linux project lost access to BitKeeper. Now, Git is everywhere, from open source to enterprise. Yet it operates without a sustainable funding model. Maintainers carry a silent burden: security patches, bug fixes, and feature requests, all mostly unpaid. What would happen if Git’s maintainers organized into a cooperative to change that?

A Short History of Git

• 2005: Git was born when the Linux project needed an alternative to BitKeeper. Linus built it swiftly with reliability and performance in mind.

• 2008–2010: GitHub launched. Its pull requests, issues, and collaboration features made Git even more accessible.

• Today: Git is universal. Subversion, CVS, and Mercurial are nearly obsolete. Millions of developers work through Git platforms daily.

The Open-Source Funding Problem

Open source was built on reciprocity: beneficiaries give back. That social contract has eroded:

• GitHub, GitLab, Atlassian, Amazon, and Microsoft profit handsomely from Git, yet Git receives minimal direct support.

• Maintainers face burnout, as expectations remain high even without funding.

Recent cases highlight the issue:

• MediatR and AutoMapper: These widely used .NET libraries shifted toward a commercial licensing model, free for individuals and nonprofits, paid for enterprise use to sustain maintainership.

• WiX Toolset: Rob Mensching introduced the Open-Source Maintenance Fee (OSMF), a small fee for commercial users. It’s designed to inject sustainability into a mature open-source project.

Real, World Pilot: WiX Toolset’s OSMF

• Feb 26, 2025: Mensching formally announced the OSMF to address long-standing sustainability challenges, including concerns from the XZ Utils incident about maintainer vulnerabilities.

• April 2025: WiX Toolset v6.0 became the first project to implement OSMF. It required a maintenance fee for official binary releases and certain interaction features, while the source remained freely licensed.

• May 2025: Mensching reported a positive reception. Companies, including Microsoft, paid the fee. Feedback so far suggests education worked better than enforcement, though procurement processes remain a hurdle.

A Cooperative Strategy for Git

If Git’s maintainers launched a cooperative, it could look like this:

1. Membership & Shares

• Contributors (past and present) receive baseline shareholder status.

• Ongoing contributions earn patronage shares, aligned with code, documentation, reviews, and release work.

2. Funding

• Corporate members (Microsoft, GitHub, GitLab, Atlassian, Amazon, etc.) pay scaled annual fees.

• Optional support contracts offer SLAs, bug fixes, or feature work.

3. Governance

• Maintainers direct technical strategy.

• Members vote on resource allocation, fairness adjustments, and budget priorities.

4. Revenue Distribution

• Fees are distributed based on patronage shares.

• Release engineering and security maintenance get guaranteed funding.

Git remains free under GPL; there’s no lock-in. But the responsibility shifts: those who profit from Git fund its sustainability.

Why This Could Work

• Scarcity of expertise: Should maintainers shift support to the cooperative fork, enterprises must follow to stay secure.

• High dependency: Git is too critical to risk running unmaintained.

• Precedent exists: MariaDB forked from MySQL as Oracle took over. The ecosystem followed the maintainers.

The Broader OPEN-SOURCE Crisis

Open source, in many cases, pushes maintainers into untenable positions.

• MediatR and AutoMapper moved to paid licensing.

• Rob Mensching has begun a real-world experiment with OSMF, gaining early participation from major users.

• Git sits at the center of this debate: how do we sustain infrastructure that underpins our industry without compensation?

Closing

Git has transformed how software gets built. But the open-source economy has not kept pace. A cooperative model could reward maintainers fairly, while keeping the software open and thriving.

The real question isn’t whether Git could become a cooperative—it’s whether open source can continue without evolving its funding models.

Call to Action

Does this cooperative approach have merit? Should foundational projects like Git pursue models that ensure companies contribute back to the tools they rely on? I’d like to hear your thoughts.