They ask:

How do we add AI to email?

How do we add AI to CRM?

How do we add AI to support tickets?

How do we add AI to the call center?

Those questions start too late.

They begin after the company has already forced the customer’s intent into a product, channel, workflow, queue, or department.

That is downstream thinking.

To use AI well, start before the software.

Start before the inbox.

Start before the ticket.

Start before the call center.

Start before the CRM.

Start before the application decides what the customer means.

The real question is much simpler:

When a customer has a thought, what happens next?

That is where loyalty starts.

A customer thinks:

I have a question.

I need help.

I want to buy something.

I need to change something.

Something isn’t working.

Something doesn’t feel right.

At that moment, the company either becomes easier to trust or easier to replace.

The customer should not have to learn the company’s organizational chart.

They should not have to understand which department owns their problem.

They should not have to decide whether their issue belongs in sales, support, operations, billing, product management, or legal.

They have intent.

The company should be ready to receive it.

Most companies have forgotten this.

They view customer contact as cost.

Cost becomes something to reduce.

The result is predictable.

More forms.

More queues.

More knowledge bases.

More ticket numbers.

More chatbots.

More deflection.

More friction.

The company believes it has become more efficient.

The customer feels the company has become harder to reach.

AI should not make that problem worse.

AI should not become a more sophisticated wall between the customer and the company.

AI should help organizations understand intent earlier.

Not after the customer has entered the maze.

Before the maze exists.

The only company I have found that seems to understand this is FreshBooks.

Here is why.

Their support experience does not feel like deflection.

It does not start with:

Search the knowledge base.

Open a ticket.

Talk to a bot.

Wait for a response.

Choose the correct department.

Prove your issue matters.

FreshBooks gives you two clear options:
Ask or call. We are here.

That sounds simple.

It is not.

It signals how the company thinks about the customer.

A call is not treated as an interruption.

A call is not buried behind reception.

A call is not treated as support’s problem.

A call is treated as important to the company.

That is why I am loyal.

Not because FreshBooks has accounting software.

Many companies have accounting software.

I am loyal because when I have a thought, a question, or a problem, I trust they are ready to receive it.

That is the point most companies miss.

The customer’s intent does not begin when a ticket gets created.

It does not begin when an email lands in an inbox.

It does not begin when a call enters a queue.

It begins when the customer has a thought and knows it.

At that moment, the company either earns trust or loses it.

FreshBooks earns it because they make the next step obvious.

Ask.

Call.

We are here.

This is where I believe AI has the potential to change business.

Not by making existing software smarter.

Not by helping employees work through tickets faster.

Not by generating better responses after a problem has already occurred.

The opportunity is much earlier.

The opportunity is to create an intent layer.

A layer that helps organizations detect, understand, route, and learn from customer intent before it becomes trapped inside departments, workflows, and software applications.

The customer does not think in departments.

The customer does not think in workflows.

The customer does not think in terms of tickets.

The customer thinks in outcomes.

That distinction matters.

Consider the airline industry.

An airline believes it sells seats.

The customer believes they purchased transportation.

The customer wants to travel from one place to another with reasonable comfort, safety, timing, cost, and dignity.

When an airline designs a seat with inadequate legroom, the company often treats the issue as a capacity, revenue, or product decision.

The customer sees something different.

The customer sees a company that forgot human beings have legs.

That is not a seat problem.

That is an intent problem.

The company optimized around its internal view of the world.

The customer judged the experience based on the outcome they were seeking.

By the time a complaint arrives, the company is already far downstream from the original intent.

Support hears the complaint.

Product reviews the feature.

Finance reviews the numbers.

Operations reviews capacity.

Marketing reviews loyalty.

The customer wonders how nobody noticed the obvious.

AI gives organizations an opportunity to move upstream.

To pay attention sooner.

To recognize intent before it becomes frustration.

To recognize patterns before they become complaints.

To understand customers before they become tickets.

The companies that win with AI will not necessarily be the companies with the most AI features.

They will be the companies that listen earlier.

The companies that move closer to the moment a customer has a thought.

The companies that make it easy to express that thought.

The companies that treat customer intent as a signal for the entire organization, not a problem to be routed into a queue.

That is where the real AI opportunity begins.

Before the software.

They are building managed agent execution systems.

GitHub has Copilot agents.
OpenAI has Codex.
Anthropic has Claude Code.
Google has Antigravity 2.0 and Managed Agents.

The direction is clear.

Agents are being assigned work. Agents are running in the background. Agents are changing files. Agents are opening pull requests. Agents are starting to operate as parallel software workers.

That is a major shift.

It also creates a management problem that most organizations are not ready for.

The Current Vendor Pattern

The leading platforms are converging on the same operating model:

• Isolate the agent

• Give it repository context

• Let it plan the work

• Let it change files

• Let it run tools

• Produce a diff or pull request

• Let a human review before merge

Google’s May 2026 I/O announcements make the shift more visible.

Antigravity 2.0 is no longer framed as one assistant helping one developer. It is moving toward agent orchestration, subagents, hooks, scheduled work, sandboxed execution, and managed agents.

That matters.

The market is moving from developer assistance to managed parallel development capacity.

That is the good news.

The bad news is that most organizations still think the control point is the pull request.

It is not.

The pull request is downstream.

By the time the pull request exists, the agent has already made decisions. It has selected files. It has crossed boundaries. It has interpreted scope. It has changed code. It has created merge risk.

Review catches some of that.

It does not govern the work before the damage exists.

Git Records the Collision. It Does Not Prevent It.

Git is excellent at source control.

It records history. It tracks branches. It detects merge conflicts. It supports rollback. It supports pull requests.

But Git is not an architect.

Git does not know which agent should own Program.cs. Git does not know whether one agent is changing onboarding while another changes authentication. Git does not know whether two agents are changing different files that depend on the same interface. Git does not know whether a small view change depends on a service change in another worktree.

Git tells you about the collision later.

For a human team, that is painful but survivable.

Humans move at human speed.

An agent does not.

One unmanaged agent is a risk. Ten unmanaged agents are a delivery hazard. Fifty unmanaged agents are not a team. They are uncontrolled concurrency.

Worktrees Are Isolation, Not Coordination

Git worktrees are useful.

They let multiple branches exist beside each other without constant checkout switching. That is useful for agent work because each agent gets its own folder, branch, and task.

But isolation is not coordination.

A worktree says:

This branch has its own working directory.

It does not say:

This agent owns these files. This agent must not touch those files. This file is already leased. This task overlaps another task. This change crosses an architectural boundary. This branch is drifting from the integration branch. This merge conflict is predictable now.

That missing layer is the real problem.

The Big Players Are Building the Runtime

The big players are building the runtime.

That includes:

• Agent workspaces

• Cloud sandboxes

• Repository access

• Tool execution

• Branch creation

• Pull request generation

• Background task execution

• Multi-agent orchestration

• Hooks and agent configuration files

• Permission models

• Review workflows

This is necessary.

It is not sufficient.

The runtime answers:

How does the agent do the work?

The enterprise still needs to answer:

Should this agent be allowed to do this work right now?

That is where the AI Harness belongs.

The AI Harness Is the Missing Control Layer

The AI Harness is not another chatbot.

It is not a prompt library.

It is the control system around agentic software delivery.

The AI Harness should know:

• Which agents are active

• Which tasks they own

• Which worktrees they are using

• Which branches they created

• Which files they are allowed to change

• Which files are already leased

• Which files are architectural choke points

• Which changes are drifting toward conflict

• Which tasks overlap

• Which pull requests are safe to review

• Which work requires human approval before the agent continues

Without this layer, organizations rely on downstream merge conflicts as their safety system.

That is weak design.

Merge conflict detection is an alarm.

It is not traffic control.

File Leases Should Become Normal

Before an agent edits a file, it should request a lease.

Example:

Agent A requests:

Views/EmployeeMasters/OnBoardingEmployee.cshtml

The AI Harness approves it.

Agent B then requests the same file.

The AI Harness denies it.

That denial is not friction.

It is control.

The same rule should apply to high-risk files:

Program.cs appsettings.json Dependency injection setup Authentication code Authorization code Shared interfaces Database migrations Project files Build scripts Deployment configuration

These files should not be casual agent targets.

They are architectural choke points.

A senior developer or solution architect should decide when those files are in scope.

Scope Is the New Senior Developer Skill

In agentic development, the quality of the task matters as much as the quality of the model.

A bad task creates bad motion.

“Fix onboarding” is too broad.

A safer work order says:

• Change activation link failure handling

• Modify only the onboarding employee view and related controller path

• Do not change authentication

• Do not change configuration

• Do not change shared email services without approval

• Do not change dependency injection

• Run the named tests

• Produce a pull request with a short explanation

That is the difference between delegation and abdication.

Untrained users will not naturally write work orders this way.

They will tell the agent to fix the problem.

The agent will search the codebase, infer scope, change files, and produce code that looks plausible.

That is where the danger starts.

Cloud Adoption Was Hard. Agent Adoption Will Be Harder.

Many companies still have not learned how to use cloud providers well.

They moved servers into the cloud and called it transformation.

They bought services but kept old operating models.

They created cost surprises, security gaps, brittle deployments, and unclear ownership.

Agentic development carries the same risk, but faster.

Companies will buy coding agents and assume productivity follows.

It will not.

Without governance, agents amplify both skill and confusion.

A strong engineering culture will use agents to accelerate bounded work.

A weak engineering culture will use agents to generate larger piles of unmanaged change.

The difference will not be the model.

The difference will be control.

Pull Requests Are Not the Finish Line

A pull request is useful.

But a pull request is downstream.

By the time the PR exists, the agent has already made decisions:

It selected files. It crossed boundaries. It introduced dependencies. It interpreted requirements. It created merge pressure. It consumed review capacity.

Review matters.

Review alone is not enough.

The AI Harness needs earlier signals:

• What files did the agent read?

• What files did the agent plan to change?

• What files did it actually change?

• Did it change files outside approved scope?

• Did another active task touch related files?

• Does the branch still merge cleanly?

• Does the change affect a high-risk architectural path?

• Did the agent modify configuration, security, or build behavior?

• Did the agent create hidden coupling with another branch?

This is how agentic work becomes manageable.

The Safe Operating Model

A safer workflow looks like this:

1. The architect breaks work into bounded tasks.

2. The AI Harness assigns one task to one agent.

3. The AI Harness creates the branch and worktree.

4. The agent receives allowed paths and blocked paths.

5. The agent requests file leases before edits.

6. A watcher tracks actual file changes.

7. The AI Harness compares actual changes against approved leases.

8. The branch is continuously checked against the integration branch.

9. Tests and static checks run before PR creation.

10. High-risk changes require human approval before merge.

This is not bureaucracy.

This is the minimum control layer needed when the workforce includes tireless parallel code writers.

The Real Enterprise Risk

The risk is not that agents write bad code.

That risk already exists with people.

The larger risk is unmanaged speed.

An agent does not need a coffee break. An agent does not wait for the next standup. An agent does not naturally understand team ownership. An agent does not know which files are politically, architecturally, or operationally sensitive unless the system tells it.

That means the organization must supply the boundaries.

If the architecture is weak, agents expose it.

If the work is poorly scoped, agents expand the mess.

If ownership is unclear, agents collide.

If the branch strategy is weak, agents accelerate drift.

If review discipline is weak, agents push more work into a broken gate.

What the Serious Teams Will Do

Serious teams will not let agents roam the repo.

They will create controls:

• Agent task intake

• Path-level ownership

• File leasing

• Worktree assignment

• Branch naming rules

• Merge simulation

• Test gating

• PR templates

• Change-risk scoring

• Human approval for architectural files

• Audit logs of agent activity

They will treat agents like powerful junior developers with speed, memory, and tool access.

That means supervision matters.

The future is not “give every employee an agent and hope Git catches the problems.”

The future is controlled agentic delivery.

The Real Question

The question is not:

How many agents can we run?

The question is:

How many agents can we control?

A solution architect should not celebrate unmanaged parallelism.

More agents do not automatically mean more progress.

Twenty agents changing code without coordination is not a high-performance team. It is a collision engine.

The companies that win with agentic development will not be the companies that let the most agents loose.

They will be the companies that build the best harness around them.

Agents need autonomy.

Software delivery needs control.

The AI Harness is where those two realities meet.

Jeff Adamson’s LinkedIn post framed the opportunity well: most Canadians did not choose their bank. They inherited it. Banking should be a relationship to be earned.

That is the right opening. The respectful challenge is this: Neo should not answer that opportunity by becoming a better account company or a better credit card company. Those are useful products, but they are not the real relationship.

Neo is already close to the answer. Its loyalty and cashback model connects customer spending to merchants. Its public positioning recognizes that the future of banking may not be a bank. Its merchant network gives it a way to become more than another fintech product bundle.

The risk is that the credit card becomes Neo’s version of the airline seat. It is countable, monetizable, and easy to market, but it can also become too small a definition of value.

The bigger opportunity is to make Neo a customer-first financial and local-commerce membership platform for Canada. The card and account should be rails. The customer relationship should be the product.

That also means the means of engagement can be broader than today’s artifacts. A card records a transaction. A customer-led phone interaction can signal intent, merchant interest, and local economic demand before a purchase happens.

Costco is a useful analogy. Costco sells products, but strategically it sells membership. The warehouse proves the value of the membership. Neo can do the same thing with financial services, merchant rewards, customer advocacy, and local economic participation.

If Neo can put the customer first, diversify revenue sources, support local merchants, and create a real customer-voice layer, it can become something much more than a neo bank. It can become the Canadian standard for customer-first money movement and local merchant advocacy.

Dear Jeff

When I asked whether you would be interested in an article that applied the same logic from my airline piece to banking, your answer was yes.

This is that article.

The airline’s argument was simple. Airlines sell seats, but passengers buy trips. The mistake occurs when the company optimizes the internal artifact rather than the customer’s actual objective.

Banking has the same problem.

Banks sell accounts, cards, loans, fees, rates, statements, and digital access. Customers are trying to manage money inside a life. They are trying to pay bills, raise families, build stability, recover from shocks, support their communities, avoid embarrassment, reduce anxiety, and make better decisions.

The account matters. The card matters. The savings product matters.

But each is only a component.

The customer does not experience their financial life as a product catalogue. They experience it as an ongoing relationship with money.

That distinction matters because it changes what Neo should become.

Neo does not need to market itself as a bank. In fact, it should be careful not to. The Canadian market already has enough institutions that behave like banks, talk like banks, price like banks, and ask customers to accept the same old account-first logic with a cleaner interface.

Neo has a chance to do something better.

The LinkedIn Post Already Names the Gap

Your LinkedIn post says:

Most Canadians didn’t choose their bank. They inherited it.

That is a powerful marketing insight because inheritance is not loyalty. It is inertia. It is a relationship carried forward because changing feels difficult, not because the customer feels understood.

The post also says banking should be a relationship to be earned, not an inheritance to be managed.

That is exactly the right frame.

The strategic question is what actually earns the relationship.

A better credit card can earn attention. A better account can earn trial. A better rate can earn comparison traffic. None of those automatically earns a relationship.

A relationship is earned when the customer believes the company understands what money means in their life. It is earned when the company helps customers make better decisions, supports the merchants they care about, avoids unnecessary fees, resolves problems without humiliation, and makes them feel that their voice matters before they are forced to go public.

That is why the marketing roles in the post are so revealing.

Integrated marketing matters. Marketing analytics matters. Lifecycle analytics matters even more. If Neo wants to understand what happens after sign-up, then it is already moving beyond acquisition into the real customer relationship.

The question is whether Neo will let that insight reshape its business model, or will mainly use it to sell more financial products.

What Neo Already Has Right

Neo’s public message is already pointing in the right direction.

The company asks what the future of banking looks like if it is not a bank. It describes Canadians as underserved by the current financial system. It talks about smarter spending, saving, rewards, insights, and partnerships.

That is not ordinary bank language. It is closer to a platform thesis.

Neo is also structurally interesting because it is not simply a branchless version of the big banks. It works with regulated financial partners for accounts, uses Mastercard rails for card acceptance, and builds its own customer experience, merchant network, and rewards model on top.

That structure can be seen as a limitation if the goal is to look like a traditional bank.

But it can also be an advantage if the goal is to stop thinking like one.

The most important part is the merchant network.

Neo’s loyalty program is not just a rewards feature. It is a signal that Neo understands something important: customer spending does not end inside the financial product. Money goes somewhere. It lands with merchants. It shapes local economies. It strengthens or weakens communities.

That is the opening.

Most banks treat rewards as an afterthought attached to a card. Neo can treat rewards as proof of a broader relationship between customers, money, and merchants.

Where Neo Can Still Get Pulled Back Into Bank Thinking

The danger is that the credit card becomes Neo’s version of the airline seat.

It is countable. It fits interchange economics. It fits acquisition funnels. It fits promotional marketing. It fits product comparison pages. It fits the financial model.

That does not make it the correct strategic center.

If the customer must use the Neo credit card for the merchant relationship to become meaningful, then the card is still acting as the gatekeeper. The relationship is constrained by the artifact.

That may work commercially in the short term, but it limits the larger opportunity.

There is a broader data question here, too.

Neo can learn from card and account activity, but that keeps the relationship anchored to financial artifacts. A more customer-first model would also let the customer use the phone as a permissioned engagement surface.

The card records the transaction. The phone can become a customer-led signal.

When a customer chooses to engage with Neo at a local merchant, even before making a purchase, they help Neo understand intent, interest, and local economic demand. That is valuable precisely because it is not surveillance. It is the customer using Neo to further their own goal: making their money work better for the businesses and communities they want to support.

This matters because being in a merchant location and browsing without buying is powerful information. It can mean price friction, uncertainty, missing inventory, weak offer design, comparison shopping, or simple curiosity. A completed transaction tells one story. A permissioned engagement signal can explain the demand that did not convert.

The privacy line has to be clear.

This should not mean background location tracking. It should not mean selling customer data. It should not mean turning the phone into a monitoring device. The value is in a customer choosing to scan, check in, save an offer, ask a question, join a local program, or otherwise identify intent on their own terms.

That gives Neo a better signal-to-noise ratio without requiring the customer to apply for another account or route every interaction through a card. It also gives local merchants a cleaner picture of interested demand without forcing them into the economics of paid ads, platform dependency, or blind discounting.

The same is true of accounts.

Accounts are necessary. They hold money, move money, and satisfy regulatory and operational requirements. But when a bank or fintech treats the account as the first-class citizen, the customer becomes secondary. The business begins asking how to sell another account, fund another account, or attach another feature to an account.

The customer is asking a different question.

How do I make my money work better for my life?

That is the question Neo should own.

The Canadian Context Matters

Canada is a complicated market for this conversation.

Many Canadians do not love their banks. They tolerate them. They need them. They trust the system enough to keep using it, but that is not the same as feeling respected by it.

The frustration is not limited to banking. Canadians often feel similar pressure in telecom, health access, insurance, and other concentrated markets where choice exists on paper but power still feels centralized.

People can switch providers and still feel trapped inside the same pattern.

That feeling matters.

A company that wants to challenge Canadian banking should not only ask whether it can offer a better card or account. It should ask why Canadians feel so little affection for institutions that handle such personal parts of their lives.

The answer is not only fees. It is not only product design. It is not only about app quality.

It is the absence of respect.

Customers often feel that the institution understands the account better than it understands the person. It understands the transaction better than the context. It understands compliance better than consequence. It understands profitability better than dignity.

That is the gap Neo can enter.

The Customer Should Be the First-Class Citizen

A customer-first financial model starts with a different data shape.

The customer is not a container for accounts. The customer is the main object. Accounts, cards, merchant offers, savings goals, credit products, disputes, support cases, local preferences, and financial insights attach to the customer.

That customer may be the purchaser or the seller.

The household trying to manage money is a customer. The local merchant, trying to survive, serve, and grow, is also a customer. A customer-first Neo should make both sides stronger without forcing either side to become subordinate to the card or account.

That sounds like a software distinction. It is really a business distinction.

If the account is first, the business optimizes account behaviour. If the card is first, the business optimizes card usage. If the customer is first, the business optimizes financial confidence, purchasing power, loyalty, community value, and long-term trust.

That leads to a different operating model.

Neo would not ask only, “ How do we get more spending on the card?

It would ask, how do we help this customer make better use of every dollar?

Neo would not ask only, “How do we grow account balances?”

It would ask, what financial outcome is the customer trying to create, and how can our products quietly support it?

Neo would not ask only, “How do we increase merchant participation?”

It would ask, how do we make local merchants more visible, more trusted, and more economically relevant to the customers around them?

That is a different company.

The Costco Lesson

Costco is useful because it separates what the company sells from what the customer thinks they are buying.

On the surface, Costco sells groceries, electronics, clothing, tires, pharmacy items, travel, fuel, and household goods. But strategically, Costco sells membership. The warehouse proves the value of the membership.

That difference is everything.

Costco can price aggressively because the point is not to maximize margin on every item. The point is to make the membership feel obviously worth renewing. Customers return because the relationship keeps proving itself.

Neo should study that pattern carefully.

If Neo makes the card the hero, it is competing inside the card market.

If it makes the account the hero, it is competing inside the account market.

If it makes membership the hero, it can compete at a different level.

The Neo membership would not merely mean a subscription fee. It would mean belonging to a customer-first financial and local-commerce network where customers receive economic advantage, merchant relevance, service confidence, and a voice.

The card becomes one rail.

The account becomes one rail.

The merchant network becomes one proof point.

The membership becomes the relationship.

Revenue Diversification Is the Strategic Unlock

This is not an argument against revenue. It is an argument for better revenue.

If Neo relies too heavily on card usage, the business will keep steering customers back to the card even when the broader relationship could be more valuable. The company will be tempted to optimize the artifact because it drives revenue.

A customer-first model should diversify revenue streams so that Neo can afford to serve customers at a price point that traditional competitors cannot match. (read that twice!)

That is where the Costco comparison matters again. The strategic power comes from using one economic engine to make the customer-facing experience more compelling than competitors can match.

For Neo, that could mean several reinforcing revenue layers.

• Merchant-funded demand generation, where local businesses pay because Neo can prove it influenced real customer activity.

• Membership revenue, where customers pay directly only if the value is obvious, recurring, and materially better than normal banking.

• Financial product revenue, where accounts, cards, mortgages, savings, and investments still exist, but are adopted because they fit the customer’s life rather than because they were pushed as products.

• Merchant services revenue, where local businesses receive tools, visibility, analytics, campaign support, and customer relationship infrastructure they cannot build alone.

• Permissioned customer-intent insight, handled carefully and transparently, where aggregated signals help merchants and communities understand demand without turning the individual customer into an exploited data product.

• Service and advocacy value, where Neo wins trust by helping customers resolve financial friction instead of leaving them to fight alone through call centres, forms, and escalation paths.

The point is not to bolt on revenue streams randomly.

The point is to make the customer relationship valuable enough that Neo is no longer forced to extract all value through a single product rail.

Local Merchants Should Be the Strategic Center

This is where Neo can become more than a fintech.

Local merchants need help. They are competing against national chains, global platforms, online marketplaces, delivery intermediaries, paid search, social media algorithms, and now AI-mediated discovery.

The local merchant is often the one with the weakest technology position and the strongest community value.

That is a dangerous imbalance.

If local merchants disappear, local economies weaken. Money leaves the community more easily. Customer choice becomes thinner. Streets become less interesting. Employment becomes less personal. The economy becomes more efficient in a way that feels worse to live inside.

Neo’s merchant network gives it a way to intervene.

The company could position itself as the de facto standard for local merchant advocacy in Canada. Not a directory. Not just cashback. A real economic operating layer that helps customers discover, support, reward, and stay connected to local businesses.

Imagine the message changing from:

to:

That is a stronger position.

It gives customers a reason to care beyond points. It gives merchants a reason to participate beyond discounting. It gives Neo a mission that is larger than financial product acquisition.

It also fits the Canadian moment.

Many people do not want every dollar to flow upward into multinational platforms that know how to extract attention but do not reinvest meaningfully in local life. They want convenience, but they also want their communities to survive.

Neo can make that choice easier.

CustomerGravity.cloud: The Missing Door

There is another part of customer-first design that most corporations still avoid.

Customers need a door.

Not a support queue. Not a chatbot loop. Not a generic complaint form. A real door where the customer can express what happened, why it matters, what impact it had, and what pattern it may reveal.

This is where CustomerGravity.cloud matters.

CustomerGravity.cloud is the recognition that customer experience is not only satisfaction data collected by the company. It is market force expressed by customers when the relationship breaks down.

Media programs like CBC’s Go Public exist because customers often run out of institutional options. When a story becomes public, corporations frequently move faster. Not always because the facts suddenly changed, but because the exposure changes the consequences of ignoring the customer.

That should tell every corporation something uncomfortable.

The customer did not need drama.

The customer needed a door.

A truly customer-first Neo should build that door before the market forces it open from the outside.

This does not mean every complaint is automatically correct. It means every serious customer signal deserves a structured landing place, a fair process, pattern detection, and visible accountability.

The goal is not to embarrass the institution. The goal is to prevent avoidable frustration from becoming public distrust.

If Neo wants to be different from Canadian banks, this is one of the places where different has to become operational.

A Different Marketing Position

The marketing opportunity is not simply to say Neo is better than a bank.

That is too small.

Neo should say something closer to this:

Your money should work for your life, your community, and your future. Neo helps Canadians manage money, earn more value from everyday spending, support local merchants, and be heard when financial services fail them.

That is not a card message.

That is not an account message.

That is a market position.

It allows Neo to talk about the card without making the card the company. It allows Neo to talk about accounts without making the account the relationship. It allows Neo to talk about merchants without making rewards feel like a coupon engine.

It also gives Neo a more durable answer to the question: “Why should I trust you?”

Because Neo is not merely trying to sell you a product. Neo is trying to make your money more useful to you and more valuable to the community around you.

What I Would Challenge Neo to Build

If I were translating this into a high-level marketing and operating plan, I would focus on six moves.

First, make membership the strategic product. Let the account, card, savings product, mortgage, investment, and merchant rewards serve as proof of membership. Do not let any single artifact define the company.

Second, loosen the mental dependency on the credit card. The card should remain important, but the customer relationship should be bigger than card usage. If merchant value only exists when the card is used, the model is still too narrow.

Third, make the phone a permissioned customer engagement surface, not a surveillance surface. Let customers choose to signal local intent, merchant interest, questions, offer saves, visits, and unresolved friction without requiring every useful signal to become a card transaction.

Fourth, make local merchant advocacy a central mission in Canada. Neo should be the company that helps customers keep more value in local markets and helps merchants compete against platforms they cannot outspend.

Fifth, build customer voice into the platform. Do not wait for customers to go public. Give them a credible, structured, respectful way to surface unresolved issues and patterns of institutional friction.

Sixth, diversify revenue so Neo can deliver financial services at a cost and value level that traditional banks struggle to match. That is how the customer-first position becomes economically durable rather than only emotionally attractive.

None of this requires Neo to abandon financial products.

It requires Neo to put them in the right order.

Customer first. Membership second. Merchant network third. Permissioned engagement fourth. Products fifth. Revenue everywhere the relationship creates real value.

Why This Matters

The strategic danger for Neo is not that it fails to look enough like a bank.

The danger is that it succeeds too well at becoming a modern version of the same account-and-card logic customers already understand and already distrust.

The Canadian market does not need another institution asking customers to admire its products.

It needs a company that understands the customer as a first-class citizen in the financial system.

Money belongs to customers. Accounts are only one way to hold it. Cards are only one way to move it. Merchants are one place it lands. Software is one way to coordinate it. Banking partners are one way to regulate and safeguard it.

The customer is the economic center.

When that relationship is understood properly, the business model changes. Marketing changes. Product design changes. Revenue changes. Support changes. The role of the merchant changes. The role of the customer voice changes.

That is the bigger opportunity.

Closing Perspective

Jeff, this is a respectful challenge.

Neo is close to something important because it already sees that the future of financial services does not have to look like a traditional bank. Its merchant network, rewards model, Canadian identity, and fintech structure all point toward a broader possibility.

But the broader possibility will be constrained if the card and account remain the main story.

Banks sell accounts. Customers manage their lives through money.

Neo should build around the second sentence.

The strongest version of Neo is not a better bank. It is not even a better credit card company.

It is a membership-based financial and local-commerce platform that helps Canadians make money work better, helps local merchants matter more, and gives customers a meaningful door when the relationship breaks.

That would be worth talking about.

More importantly, it would be worth joining.

Source Note

This article was informed by Neo Financial’s public pages, reviewed on May 21, 2026, including About, Accounts, Advanced Insights, Partners, Legal, and Help Centre. Those pages describe Neo’s fintech positioning, financial products, merchant network, account-provider structure, and public founder roles.

It also responds to the LinkedIn post provided as the prompt for this article, especially the argument that Canadians inherited their banks and that Neo wants to become the brand Canadians choose.

• Neo About: https://www.neofinancial.com/company/about

• Neo Accounts: https://www.neofinancial.com/accounts

• Neo Advanced Insights: https://www.neofinancial.com/insights

• Neo Partners: https://www.neofinancial.com/partners

• Neo Legal: https://www.neofinancial.com/legal

• Neo Help Centre, Everyday Account: https://support.neofinancial.com/hc/en-001/articles/21190171447309-Introducing-the-Neo-Everyday-account

Waterfall.

Agile.

Now Agentic Development.

Each era changed how we think about:

• ownership

• traceability

• execution

• coordination

• delivery

• change

But something important happened as we moved forward.

The boundaries changed faster than our thinking about them.

Today, AI coding discussions are focused on the wrong problem.

The conversation sounds like this:

“AI writes code fast, but that doesn’t mean the code is correct.”

That is true.

But it misses the larger issue entirely.

The real challenge is not code generation.

The real challenge is preserving intent while autonomous systems execute at machine speed.

That changes everything.

Waterfall Boundaries

Waterfall organized software around phases.

Requirements

• Design

• Development

• Testing

• Deployment

• Traceability existed mostly through documents.

The assumption was simple: If the specification was detailed enough, the implementation would eventually match the intended outcome.

The problem was obvious in hindsight.

Users validated documents instead of experiences.

Describing software through specifications is similar to describing music through text. You can describe the structure, timing, and components, but the actual experience only exists when it is played.

Software works the same way.

A workflow must be experienced to be understood.

This created the classic Waterfall failure: Months of implementation before users realized the workflow itself was wrong.

Not the code.

The workflow.

Agile Boundaries

Agile corrected many Waterfall problems.

It reduced feedback cycles.

It improved iteration speed.

It exposed working software earlier.

But Agile introduced a different boundary model.

The new units became:

• epics

• stories

• sprints

• vertical slices

This improved engineering execution.

But users still struggled to understand the complete operational workflow.

Why?

Because a sprint rarely represents a full business experience.

A user might validate:

• a login page

• a search screen

• an approval component

• a reporting widget

• But that does not mean they understand:

• the operational flow

• exception handling

• escalation paths

• timing

• interruptions

• role coordination

• long-term usability

Agile optimized delivery decomposition.

It did not fully solve the problem of experiential traceability.

Agentic Development Changes the Problem Again

Now, AI agents are writing software.

And the industry response has largely been fear:

• AI creates too much code

• AI moves too fast

• humans cannot review everything

• AI introduces mistakes

Those concerns are real.

But, IMO, they are secondary.

The deeper issue is this:

• AI accelerates local optimization faster than humans can preserve global coherence.

• Agents work well inside boundaries.

• They struggle crossing boundaries.

That matters because modern software is almost entirely boundary coordination:

• frontend to backend

• service to service

• application to the external provider

• workflow to workflow

• internal systems to external systems

Inside a small boundary, an agent has:

• local context

• local ownership

• local assumptions

Crossing boundaries changes the problem entirely.

Now the system must preserve:

• intent

• traceability

• authorization

• semantic meaning

• compatibility

• workflow integrity

At machine speed.

Why Smaller Boundaries Matter

Traditional software boundaries focused on:

• deployment

• scaling

• separation of concerns

Agentic boundaries serve a different purpose.

They minimize:

• semantic drift

• merge conflicts

• overlapping assumptions

• uncontrolled mutation

• architectural inconsistency

This becomes critical when multiple agents work concurrently.

A merge conflict is not merely a Git problem.

Git only detects textual overlap.

The real danger is semantic conflict:

• two agents implementing incompatible assumptions

• workflow drift

• contradictory business logic

• operational inconsistency

That means boundaries must become tighter and more intentional.

Not to slow AI down.

To preserve coherence while AI moves fast.

The Boundary Crisis

This is where the industry currently struggles.

Most systems still rely on tightly coupled API thinking.

APIs expose access.

They do not preserve intent.

A loosely coupled boundary requires far more than:

• endpoints

• schemas

• payloads

It must also preserve:

• identity

• authorization

• ownership

• operational meaning

• workflow traceability

• delegation

• policy

• auditability

The crossing itself becomes the architectural problem.

Not: “How do I call another service?”

But: “How do autonomous domains exchange intent safely without corrupting meaning?”

That is a much harder problem.

AIID

This is where AIID begins.

AI Intent-Driven Development is not primarily about AI-generated code.

It is about preserving intent integrity across autonomous execution domains.

AIID recognizes:

• boundaries are changing

• traceability is changing

• workflows are becoming executable specifications

• prototypes and specifications must stay aligned

• agents require constrained operational scopes

• intent must survive boundary crossings

The future of software development is not: Specification → Code

It is: Intent → Workflow → Prototype → Autonomous Execution → Operational Feedback

The specification and the workflow prototype become dual artifacts:

• one describes intent

• one demonstrates intent

Both need to remain traceable.

Both evolve together.

Both become part of the operational system itself.

The Next Architecture Era

Waterfall optimized predictability.

Agile optimized iteration.

Agentic systems require intent preservation.

That is the next boundary model.

The organizations that succeed with AI will not be the ones generating the most code.

They will be the ones that best preserve:

• workflow integrity

• operational meaning

• traceability

• governance

• identity

• authorization

• intent coherence

While autonomous systems execute in parallel at machine speed.

That is the problem AIID is attempting to solve.

Fast code is useful, but fast code by itself does not create sophisticated business software. The harder problem is coordination.

A real application is not one block of functionality. It is made from business capabilities, application boundaries, data ownership boundaries, workflows, and integration points. These pieces need to communicate with each other, but they cannot all be tangled together. If they are, the system becomes fragile very quickly.

This is one of the reasons I believe AI Intent Development, or AIID, is so important.

AIID is not just about asking an AI agent to generate a screen, a service, or a workflow. It is about giving the agent the right boundary to work within. The agent should understand the business slice it is responsible for, but it should not need to understand the entire application landscape before it can make a useful contribution.

That distinction matters.

When an agent needs too much context, the development process becomes heavy again. The token load grows. The chance of misunderstanding grows. The amount of architectural coordination grows. Eventually, the speed advantage starts to disappear.

AIID works differently. It allows an agent to focus on a defined application slice while still participating in a larger business system.

This is where SignalWeaver becomes critical.

SignalWeaver is a service purposely built by AISoftwareFactory.cloud to assist in the development of applications requested through BackTheApp.Software. Its role is not simply to move messages from one place to another. Its value is that it allows independently developed application slices to communicate across domain boundaries without requiring every agent to understand every receiving system.

That is a major part of the platform advantage.

A publishing agent does not need to know the full contact map of the application landscape. It does not need to understand every boundary, every subscriber, or every downstream process. It only needs to understand the lightweight method required to publish the right event.

SignalWeaver carries the cross-boundary communication pattern.

That means the agent can stay focused on the business capability it is building. The platform absorbs the complexity that would otherwise have to be carried in the agent’s working context.

The receiving side gets the same benefit.

A subscriber can receive a message through its relationship with SignalWeaver and handle that message inside its own application context. It can enrich the message with the local business meaning required to process it correctly.

This is important because it allows the publisher and subscriber to remain decoupled without becoming disconnected.

The publishing side does not have to know everything about the receiving side. The receiving side does not have to force its internal logic back onto the publishing side. Each side can own its own context, while SignalWeaver provides the event communication model that allows the overall system to stay functional.

That is what makes this kind of agentic development different.

The speed does not come only from agents writing code faster. The speed comes from reducing what each agent must know in order to make a correct contribution.

That reduction creates practical advantages.

Multiple agents can work at the same time without constantly colliding in the same code paths. Application slices can evolve independently. Cross-domain communication can happen without forcing every agent to carry the full architecture in its prompt context. The result is faster development, but also cleaner development.

This is why I see AIID as more than a prompt strategy.

It is a development model.

BackTheApp.Software provides the request path for the application. AISoftwareFactory.cloud provides the agentic development platform that turns that request into working software. AIID gives the agents a structured way to understand and build the application. SignalWeaver provides the event communication service that allows those independently developed slices to work together across boundaries.

That combination is what allows sophisticated software to be created quickly.

The software is decoupled, but it is still functional.

The agents are focused, but they are not isolated.

The application slices are independent, but they can still participate in larger business workflows.

For executives, this is the real point: agentic development becomes valuable when it can produce coherent business software, not just isolated pieces of generated code.

AIID and SignalWeaver are designed around that outcome.

They allow the development process to stay fast because each agent works with a smaller, clearer scope of knowledge. They allow the software to stay sophisticated because those independent slices can still communicate through a platform-level event model.

That is the difference between using AI to write code and using AI to build applications.

One produces output.

The other produces working business systems.

They can inspect a repository, search files, run tests, modify code, summarize changes, and continue work across increasingly complex development tasks. With tools such as Codex adding persistent goals, plugin workflows, external session imports, and multi-agent execution, coding agents are moving beyond simple prompt-and-response coding assistance.

But there is an important limitation in the way many coding agents work today.

They often treat the local codebase as the primary source of truth.

That is useful, but incomplete.

The codebase tells the agent what has been implemented. It does not always tell the agent why the system exists, what the business intended, what trade-offs were made, what stakeholders discussed, or what future outcome the development team is trying to produce.

And there is another practical issue: reading local files costs tokens.

Every time a coding agent opens files, scans directories, reads documentation, compares implementation details, or searches through large parts of a repository, it consumes context and tokens. For a small project this may not seem important. For real business systems, especially brownfield applications with years of accumulated code, documentation, comments, issues, and historical decisions, this becomes a serious constraint.

The agent may repeatedly read the same files. It may infer business rules from implementation details. It may inspect stale documentation or search through disconnected fragments of project history. Even when the agent succeeds, it can spend a great deal of its context budget rediscovering information that should already be available in a more useful form.

This is where a semantic project knowledge source becomes important.

Disclosure

ContentTraker is a product I have developed to maintain a business-domain-focused knowledge base for software projects.

It is designed for use by both human stakeholders and AI coding agents. Coding agents can access ContentTraker through tools, resources, and prompts exposed by a secure MCP server. This allows project knowledge to become part of the AI-assisted development workflow while remaining separate from the code repository itself.

The Problem With Code-Only Context

Code is essential, but code is not the whole project.

A codebase contains implementation. It may contain some documentation. It may contain tests that describe expected behaviour. It may contain commit messages or comments that hint at previous decisions.

But the codebase is rarely the complete record of business intent.

Stakeholders do not usually express requirements as source files. Executives do not describe strategic goals in pull requests. Users do not explain pain points in class names. Product owners do not always preserve decision history in comments beside the final implementation.

The business context often lives somewhere else:

• Requirements documents

• Meeting notes

• Support issues

• Architecture discussions

• Product strategy documents

• Stakeholder conversations

• Prior analysis

• Domain rules

• Acceptance criteria

• Historical decisions

When that information is scattered across emails, chat tools, ticketing systems, documents, and individual memory, the coding agent is forced to work from an incomplete view.

It can read the code, but it may not understand the purpose.

This creates a gap between what the agent can change and what the business actually needs.

Token Usage Is A Design Concern

One of the less visible costs of AI-assisted development is token usage.

A coding agent that relies mainly on local file reading must spend part of its context budget on discovery. It searches the repository, opens files, reads code, scans configuration, inspects documentation, and builds a temporary mental model of the system.

That process is useful, but it can be wasteful when the agent is repeatedly reconstructing the same context.

For example, if a project has an established business rule, the agent should not need to rediscover that rule by reading five service classes, two tests, an old markdown file, and a comment in a controller. The agent should be able to retrieve the relevant rule directly from a semantic knowledge source.

This is especially important as coding agents become more autonomous.

Persistent goals, background work, external session imports, plugins, and multi-agent execution all increase the amount of context an agent may need. If each agent must repeatedly read large portions of the local repository to understand the project, the development workflow becomes more expensive, slower, and more likely to drift.

A semantic search engine can reduce that burden.

Instead of relying only on raw file reads, the coding agent can query a knowledge source that has already organized the project’s business context. The agent can retrieve the most relevant requirements, issues, decisions, and explanations before deciding which files to inspect.

The codebase remains the implementation source of truth.

But the knowledge base becomes the intent source of truth.

ContentTraker As A Knowledge Source For Coding Agents

ContentTraker is intended to serve as that knowledge source.

It provides a business-domain-focused knowledge base that can be accessed by coding agents through secure MCP tools, resources, and prompts. This means the agent can retrieve project knowledge through a controlled interface rather than relying only on local file inspection.

That changes the development workflow.

Before modifying code, the agent can ask:

• What business problem is this feature solving?

• What stakeholder requirement is connected to this issue?

• What prior decision affects this area of the system?

• What documentation exists for this domain concept?

• What constraints should guide this implementation?

• What acceptance criteria define success?

This does not replace code inspection. The agent still needs to read the relevant files, understand the implementation, run tests, and make careful changes.

But ContentTraker can help the agent start from meaning instead of starting from raw source code.

That distinction matters.

A coding agent that only reads files can understand structure.

A coding agent connected to ContentTraker can understand purpose.

A Shared Space For Stakeholder Discussion

ContentTraker is not only useful for agents.

It also gives stakeholders a place to discuss the project in terms of business outcomes, requirements, and decisions.

This is important because software development is not simply a conversation between developers and code. It is a conversation between business goals, user needs, technical constraints, operational realities, and implementation choices.

When stakeholders only interact through the codebase, much of that conversation is lost. Non-technical participants may not be comfortable in GitHub issues, pull requests, or source files. Important context may remain in meetings, emails, chat messages, or documents that are not visible to the coding agent.

ContentTraker can become a shared project memory.

Stakeholders can discuss the business domain. Developers can document decisions. Analysts can clarify requirements. Product owners can connect features to outcomes. Coding agents can retrieve this knowledge when working on the system.

The result is a richer collaboration model.

The project knowledge is no longer trapped in the codebase.

It becomes available as a semantic resource for both people and agents.

AI Integrated Development

This is the foundation of what I call AI Integrated Development, or AIID.

AIID is a development methodology in which AI is not treated merely as a code generator. Instead, AI is integrated into the full development process through access to structured project knowledge, business-domain context, stakeholder discussion, code, tools, and runtime feedback.

In AIID, the coding agent works from more than the repository.

It works from the project’s knowledge environment.

That environment includes:

• The source code

• The issue history

• The business documentation

• The stakeholder discussion

• The domain model

• The architecture decisions

• The acceptance criteria

• The operational constraints

• The project goals

ContentTraker plays a central role in this methodology because it can act as the original repository of project knowledge.

Greenfield Development

In greenfield development, ContentTraker can be used as the starting point for a new application.

Before the code exists, the project knowledge exists.

Business goals, requirements, domain explanations, stakeholder interviews, process descriptions, feature outlines, and acceptance criteria can be captured in ContentTraker. The coding agent can then use that knowledge as the foundation for implementation.

This gives the agent a richer starting point than a single prompt.

Instead of saying, “Build an application that does X,” the team can maintain a structured body of knowledge that explains what the application is, why it matters, who it serves, and how success should be evaluated.

The coding agent can use that knowledge to generate implementation plans, propose architecture, create initial code, produce tests, and keep development aligned with the business domain.

In this model, ContentTraker becomes the original source for development.

The codebase is created from project knowledge, not from disconnected prompts.

Brownfield Development

In brownfield development, the problem is different.

The code already exists. The history already exists. The undocumented decisions already exist. The support issues, workarounds, constraints, and business rules may be spread across years of activity.

For a coding agent, this can be difficult.

The agent can inspect the local repository, but it may not know which old decision still matters. It may not know which stakeholder concern caused a feature to be implemented in a particular way. It may not know whether a strange piece of logic is accidental complexity or a business-critical rule.

ContentTraker can become the source for brownfield issues and documentation.

It can hold:

• Known problems

• Current issues

• Feature requests

• Business rules

• Migration notes

• Architecture explanations

• Stakeholder decisions

• Support context

• Refactoring rationale

• Documentation gaps

When the coding agent works on a brownfield system, it can use ContentTraker to understand the issue before it changes the code.

That improves both efficiency and judgment.

The agent spends fewer tokens rediscovering context, and it is more likely to make a change that respects the business reality of the system.

Why This Matters Now

Recent changes in coding-agent platforms point toward a more stateful and extensible future.

Features such as persisted goals, plugin workflows, external agent session import, permission profiles, and multi-agent execution all suggest the same direction: coding agents are becoming long-running participants in the development process.

That makes context more important, not less.

The more capable the agent becomes, the more important it is for the agent to work from trusted knowledge.

If an agent can continue a goal over multiple turns, it needs to understand the goal. If it can import work from another agent, it needs to know how that work fits the project. If it can run plugins and use tools, it needs to understand which sources are authoritative. If it can spawn subagents, those agents need access to shared project context so they do not each invent a different interpretation of the work.

This is where ContentTraker fits naturally.

It provides a secure, business-domain-aware knowledge source that coding agents can use alongside the repository.

The local files explain what the system is.

ContentTraker helps explain why the system matters.

The Business Advantage

The business advantage is not simply that AI can write code faster.

The real advantage comes when AI works from better context.

A coding agent connected only to a codebase may be productive, but it is still limited. It can inspect implementation details, but it may miss business intent. It can make changes, but it may not understand stakeholder priorities. It can read files, but it may spend unnecessary tokens reconstructing knowledge that should already be available.

ContentTraker adds the missing layer.

It gives organizations a way to maintain project knowledge as a semantic resource. It gives stakeholders a place to participate in the development conversation. It gives coding agents a secure knowledge source that complements the local repository. And it supports AIID as a methodology for integrating AI into the full software development lifecycle.

Software is not just code.

Software is accumulated intent.

AI-assisted development should preserve that intent, retrieve it when needed, and use it to guide implementation.

That is the role of ContentTraker in AI Integrated Development.

And that is why coding agents need more than code.

Suggested LinkedIn Post

Coding agents are getting better at reading repositories, modifying files, running tests, and continuing complex work.

But code alone is not enough.

The codebase tells an agent what has been implemented. It does not always explain why the system exists, what stakeholders decided, or which business rules should guide a change.

That is why I am thinking about ContentTraker as part of an AI Integrated Development methodology.

ContentTraker is a business-domain-focused knowledge base I have developed. It can be exposed to coding agents through a secure MCP server, giving agents access to tools, resources, and prompts that retrieve project knowledge without relying only on repeated local file reads.

This matters because reading local files consumes tokens, and because stakeholder context often lives outside the codebase.

For greenfield projects, ContentTraker can serve as the primary source of development knowledge.

For brownfield projects, it can become the source for issues, decisions, documentation, and business context.

The future of AI-assisted development is not just faster code generation.

It is a better context.

A small email icon, a Microsoft sign-in failure, and a reminder that automation without experienced judgment still breaks in simple ways.

The Setup

I clicked a small icon in an AI interface.

The tooltip said “Open email.”

That sounded useful. It looked like one of those small product improvements that saves time. Click once, open an email, keep moving.

Then Microsoft stopped the flow with this message:

That is not a user message.

That is not a business message.

That is a developer diagnostic that escaped into the user experience.

What the Screenshots Show

The screenshots show the problem clearly.

The first screenshot shows the promise: a small convenience feature. Open email.

The second screenshot shows the failure: a Microsoft sign-in screen that exposes a raw identity provider error to the user.

That gap is where experienced humans still matter.

The Technical Answer

Here is the exact assessment I made when reviewing the error:

The limitation is known enough to design around.

Microsoft documents AADSTS90015 as QueryStringTooLong, meaning the sign-in request sent to Microsoft Entra exceeds the maximum query string length it accepts. Microsoft’s error-code reference lists it directly. Microsoft also states its error-code documentation is for developer and admin guidance, and should not be used by the client itself. (learn.microsoft.com)

What likely happened:

You clicked the “Open email” icon.

The app tried to open Outlook or Microsoft sign-in using a URL.

That URL likely included too much data in the query string, often subject, body, return URL, state, redirect data, or encoded content.

Microsoft Entra rejected it before the user reached the email experience.

This is not a user problem.

This is a product design problem.

A good implementation would do one of these:

Limit the length of the mailto or compose URL before launching it.

Copy the content to the clipboard and tell the user.

Open a blank email and let the user paste.

Create a draft server-side.

Use POST or stored state instead of stuffing content into the URL.

Show a friendly message like:

“This query string is too long to open automatically. The content has been copied to your clipboard.”

The exact maximum length varies by browser, service, identity provider, proxy, and redirect chain. But the failure mode is predictable. Microsoft Q&A threads around this error point to oversized request parameters, cookies, RelayState, or redirect payloads as common causes. One Microsoft answer also references a 4096-byte limit on request parameters in a SAML context. (learn.microsoft.com)

So your criticism is fair.

The platform should not expose a raw identity-provider error to a normal user after clicking a convenience icon. It should detect the oversized request before opening Microsoft sign-in.

The Business Lesson

This is why AI is useful, but still not far enough along to own the full context of what it provides.

AI saw a task.

Open email.

An experienced human sees the system boundary.

Opening an email is not one action. It crosses product UX, browser behaviour, URL limits, Microsoft Entra authentication, redirect handling, message size, state management, and user trust.

That is the difference.

AI often completes the visible task.

Experienced humans understand the failure path.

Where the Design Failed

The interface offered a shortcut without checking whether the shortcut would work.

That is a product flaw.

A better system would test the payload size before launching the email flow. It would know when content is too large for a query string. It would avoid sending the user to Microsoft sign-in with a request that is already likely to fail.

The user should never see AADSTS90015 after clicking “Open email.”

The user should see something useful:

“This query string is too long to open automatically. The content has been copied to your clipboard.”

That message preserves trust.

It explains the issue.

It gives the user the next step.

It hides the internal machinery.

That is product thinking.

The Human Advantage

This is the value of experience.

A junior system sees an error.

An AI system explains an error.

An experienced architect asks why the user saw the error at all.

That question changes the solution.

The issue is not Microsoft Entra.

The issue is not the user.

The issue is the design choice that allowed a known technical boundary to leak into the user experience.

AI is getting better at generating features.

It is less reliable at understanding the limits around those features.

Those limits often come from years of scar tissue:

• Browsers have limits.

• Identity systems have limits.

• URLs have limits.

• Redirect chains have limits.

• Users have patience limits.

A Better Rule

When software crosses a system boundary, design the failure path first.

The happy path is easy.

The failure path tells you whether the product was designed by someone who understands production systems.

That is where AI still needs experienced humans.

Not because humans type faster.

Because humans know where systems break.

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