Connect with us

Non classé

From Systems of Record to a Logistics Control Layer

Published

on

The emerging logistics control layer should not be understood as one more application category. Its strategic role is to coordinate operating state, decisions, authority, and action across systems of record that were built to optimize different execution domains. That makes the shift architectural rather than cosmetic: ERP, TMS, WMS, YMS, OMS, visibility, and automation remain important, but the enterprise increasingly needs a layer that can connect what those systems know to what the logistics network should do next. The need for a control layer follows directly from the fragmentation described in Stop Managing Logistics as a Collection of Functions: the decision space between functions still has to be coordinated.

Most large logistics operations do not suffer from a shortage of software. They suffer from fragmentation of decision-making across software.

A TMS knows transportation. A WMS knows warehouse work. A YMS knows the yard. An OMS knows orders. Visibility platforms know events in motion. Automation systems know equipment state. ERP provides the transactional backbone.

Each system sees something important. None necessarily sees enough to coordinate the entire logistics response when conditions change. That gap is creating demand for what can best be described as a logistics control layer.

Not Another System of Record

The control layer should not be confused with an attempt to replace execution systems. TMS, WMS, YMS, OMS, and specialized automation platforms exist because their domains are complex. Recreating all of that functionality in a new monolithic platform would be expensive and, in many cases, unnecessary. The emerging requirement is different: interpret events across systems, determine which events matter, understand their consequences, coordinate a response, and move the decision back into execution. That is a control problem rather than a transaction problem.

ERP remains indispensable, but logistics increasingly operates at a cadence and level of physical detail that transactional systems were not designed to manage alone. A shipment ETA may change several times in a day. A dock may become unavailable. A carrier may reject a tender. A robot may fail. A yard can become congested. An order priority can change after work has already begun.

These are operating-state changes. Their significance depends on context across multiple domains. The control layer needs to consume that state without pretending to become the master system for every underlying transaction.

Visibility Was the First Step

Real-time transportation visibility helped establish the idea that logistics events could be aggregated outside the core execution system. Control towers expanded the concept by bringing multiple information sources into a common operational view. But visibility and control are not the same thing. A screen showing fifty late shipments may improve awareness while doing little to improve execution. A control layer must go further: identify which exceptions threaten an important outcome, determine what options exist, route the issue to the appropriate decision-maker or agent, and record what happened next.

The transition is from seeing to coordinating. This is harder than it sounds because the same event can have very different operational significance. A two-hour delay on one load may be immaterial. The same delay on another may stop production, miss a customer appointment, trigger demurrage, or cause a warehouse labor plan to fail.

The control layer therefore needs more than event ingestion. It needs business context: orders, inventory, customer commitments, facility constraints, transportation alternatives, costs, and decision rules. This is where data architecture, knowledge models, and AI increasingly intersect with logistics execution. There is a temptation to solve fragmentation by buying or building one platform that claims to do everything. Logistics history suggests caution.

Different operations will continue to require specialized systems, and companies will continue to have heterogeneous technology estates. The more durable architecture may therefore be modular: APIs, event streams, shared identifiers, orchestration services, decision logic, and agents that connect systems without requiring all of them to be replaced. That makes interoperability a strategic capability.

What Belongs in the Control Layer?

The exact architecture will vary, but several capabilities are becoming increasingly important. First is event normalization: converting signals from carriers, warehouses, equipment, and enterprise applications into a usable operating state. Second is exception prioritization: distinguishing events that require intervention from those that do not. Third is context assembly: gathering the information required to understand the consequence of an exception. Fourth is decision support: identifying feasible alternatives, costs, service implications, and constraints.

Fifth is workflow and authority: determining whether software can act, whether a human must approve, and which system should execute the change. Finally, the outcome must feed back into the operating record so the organization can learn whether the intervention worked. The value of the control layer is not another dashboard. It is compression of the decision cycle. Today, many logistics exceptions require a person to notice a problem, open multiple applications, send messages, collect missing information, evaluate options, obtain approval, update a system, and then monitor the result.

That workflow can consume more time than the physical intervention itself. A well-designed control layer can reduce those handoffs. It can assemble context automatically, present the relevant options, automate routine decisions within defined boundaries, and escalate only what requires judgment. The result can be lower exception cost, faster service recovery, better asset utilization, and greater planner capacity.

Control Requires Governance

The closer software moves toward execution, the more important decision rights become. Which decisions can be automated? What financial threshold requires approval? When can a shipment be rerouted? Who owns the trade-off between freight cost and customer service? What happens when two objectives conflict?

Those are not merely software settings. They are operating-model decisions. The logistics control layer is therefore as much about authority as technology. And it depends on one prerequisite: a sufficiently accurate picture of what is happening in the physical operation. That requirement becomes especially visible inside the warehouse, where software is increasingly coordinating machines as well as people.

Related Logistics Viewpoints research

The New Architecture of Logistics
Systems Engineering in Logistics
2026 Autonomous Exception Management Market Map
Exception Management Is Emerging as the New Supply Chain Control Layer
Previous in this series: The End of the Transportation-Warehouse Divide

Request The New Architecture of Logistics Client Edition

If your organization is assessing connected execution, orchestration, AI, observability, decision velocity, or selective autonomy, I would be glad to provide the complete client edition and discuss the implications for your logistics operating model and technology architecture.

Request the client edition

The post From Systems of Record to a Logistics Control Layer appeared first on Logistics Viewpoints.

Continue Reading

Non classé

The AI Trade Just Ran Into Its Unit-Economics Problem

Published

on

By

The artificial intelligence debate is changing.

For several years, the central question was whether AI worked. Then it became whether the technology could scale.

Increasingly, the question is becoming more difficult:

Who actually captures the value?

That distinction matters because AI adoption can accelerate, token consumption can soar and the economics of individual participants can still deteriorate.

This is the point at which a technology story becomes an operating-model story.

And for logistics companies deciding where AI creates economic advantage, that may be much more useful than watching the daily valuation of another AI stock.

More Tokens Does Not Automatically Mean More Revenue

The basic AI economic equation has generally seemed straightforward.

Models become better. Better models create more useful applications. Applications increase demand. Demand consumes more tokens. More tokens create more revenue.

The complication is price.

AI inference is becoming cheaper at a remarkable rate. Competition among model providers is increasing, open-weight models are improving, specialized models are proliferating and hardware efficiency continues to advance.

That is excellent for customers.

It is less obviously excellent for every company selling tokens.

Man Group’s bearish analysis of the AI investment cycle describes the problem starkly: if token prices decline faster than inference demand expands, enormous growth in usage does not necessarily produce the revenue required to justify an equally enormous infrastructure buildout.

Goldman Sachs Research is more constructive. Its work points to sharply increasing token consumption – potentially a 24-fold increase by 2030 as agentic AI expands – while declining unit compute costs could improve hyperscaler margins.

Those positions are not actually contradictory.

They describe the variable that matters.

The economic outcome depends on the relationship among volume, price and cost.

That is unit economics.

The De-Rating Is Telling Us Something

The financial market has already become more discriminating about AI exposure.

A recent Goldman basket analysis reportedly showed an all-inclusive AI pair roughly 46 percent below its previous highs, even as underlying demand for compute remains strong. Goldman’s argument is not that AI is ending; rather, the opportunity may be broadening toward businesses with clearer monetization, embedded workflows and defensible economic positions.

That distinction is important.

A broad technology transition does not guarantee that every participant in the technology stack earns extraordinary returns.

The internet changed the world. Many internet companies disappeared.

Containerization transformed global trade. That did not mean every shipping line earned exceptional margins.

Cloud computing became foundational infrastructure. The economics nevertheless concentrated in particular layers of the stack.

AI is likely to behave similarly.

The technology can be revolutionary while the value migrates.

Open Models Are Accelerating the Pressure

The open-model transition makes this more visible.

Vercel’s AI Gateway data recently showed open-weight models reaching approximately 62 percent of token volume on August 22, up from 28.4 percent roughly two months earlier and about 11 percent in April. These are figures from one platform rather than the entire AI industry, but the speed of the shift is notable.

Customers are learning something logistics managers learned long ago.

Not every movement requires premium service.

You do not ship every load by air. You do not give every SKU the same inventory policy. You do not assign the most expensive resource to every task simply because it is technically capable of performing it.

The same logic is beginning to apply to AI.

Enterprises can route difficult tasks to expensive frontier models while sending repetitive, lower-value or highly specialized workloads to cheaper models.

This is good architecture.

It is also price pressure.

As switching becomes easier, the model itself can become one component within a larger decision architecture.

That changes where the economic moat resides.

The Value May Move Up the Stack

Consider a logistics company using AI to manage exceptions.

The model may analyze late shipments, weather, inventory availability, customer commitments and transportation alternatives. It may recommend that an order be reallocated, a shipment expedited or a customer promise changed.

Suppose the model call costs 20 cents today and two cents three years from now.

The model provider has experienced severe unit-price compression.

The logistics operator has not necessarily lost anything.

In fact, the logistics operator may gain.

If the AI avoids a $5,000 expedite, prevents a stockout or allows one planner to manage twice as many exceptions, the economic value exists primarily in the operating outcome – not in the token.

This is where the AI economics discussion becomes particularly relevant to enterprise logistics.

Falling model prices could transfer economic value away from model providers and toward companies capable of embedding inexpensive intelligence into valuable workflows.

The model becomes cheaper.

The decision becomes more valuable.

Architecture Becomes the Moat

This suggests that enterprises should be careful about defining an “AI strategy” around access to a particular model.

Model leadership can change.

Prices can change even faster.

An enterprise architecture built tightly around a single provider may eventually look like a transportation network designed around one carrier regardless of lane, service requirement or price.

The more durable architecture is likely to separate the business problem from the intelligence resource used to solve it.

Understand the decision.

Assemble the required context.

Define the constraints.

Determine the acceptable action.

Then route the problem to the model – or combination of models – capable of solving it at the appropriate cost.

That is not simply AI adoption.

It is AI orchestration.

And it looks very similar to other logistics optimization problems.

Intelligence Is Becoming a Variable Cost

The larger economic change may be that machine intelligence is becoming a purchasable input whose price declines rapidly.

That is extraordinary.

For most of industrial history, intelligence has been expensive. Analytical capacity was constrained by the number of skilled people available to perform the work.

AI begins to relax that constraint.

If the cost of a useful unit of machine reasoning continues falling, companies can economically apply intelligence to thousands of decisions that previously could not justify human analysis.

Shipment prioritization.

Carrier selection.

Inventory rebalancing.

Appointment scheduling.

Exception resolution.

Warehouse labor planning.

Supplier-risk analysis.

Customer-response generation.

Every one of these can potentially consume enormous quantities of tokens while producing economic value far larger than the cost of those tokens.

This is why collapsing AI prices are not necessarily bearish for AI adoption.

They may be extraordinarily bullish for the users of AI.

The Second Half of the AI Trade

The first phase of the AI boom rewarded scarcity.

There were too few advanced GPUs. Too little compute. Too few frontier models. Too little capacity.

Scarcity created pricing power.

The next phase may reward orchestration.

Models will proliferate. Intelligence will become cheaper. Enterprises will learn to switch among providers. Open-weight systems will handle an increasing share of routine workloads. Infrastructure costs will continue to matter, but customers will become much more disciplined about what they are willing to pay for a unit of intelligence.

That does not mean the AI boom is over.

It means the economics are maturing.

The winners in logistics will probably not be the companies that consume the most AI.

They will be the companies that turn increasingly inexpensive intelligence into better operating decisions.

That is a very different metric.

Tokens are an input.

The decision is the product.

And the economic value ultimately belongs to whoever can make that decision improve the system.

The post The AI Trade Just Ran Into Its Unit-Economics Problem appeared first on Logistics Viewpoints.

Continue Reading

Non classé

Requirements Before Technology: Define the Problem Before Buying the Solution

Published

on

By

The fastest way to buy the wrong logistics technology is to begin with the technology. Yet that is still how too many programs start: a new TMS, WMS, control tower, yard platform, AI initiative, or automation project. The solution enters the room before the operating requirement has been defined.

The problem is not that any of these technologies are bad ideas. The problem is that the solution has entered the conversation before the requirement has been defined. Systems engineering reverses that order. The expanding scope described in What Is a WMS in 2026? is a useful example of why requirements should be defined before a buyer lets a rapidly broadening product category define the problem.

Start With the Operating Problem

A requirement is not a feature request. “AI-enabled routing” is not a business requirement. “Reduce the time required to identify and recover priority shipments at risk of missing their delivery commitment” is closer. “Real-time visibility” is not a requirement by itself. “Identify at-risk customer orders early enough to take corrective action before the promised delivery window” is.

The difference matters because requirements describe desired system behavior and outcomes. Features describe how a vendor has chosen to implement capabilities. When organizations begin with features, the evaluation tends to become a comparison of product checklists. When they begin with requirements, they can evaluate whether a technology, process change, organizational change, or combination of solutions actually solves the operating problem. That produces a very different buying process.

Logistics requirements are rarely one-dimensional. At the highest level, the business may require improved service, lower working capital, greater resilience, faster response, or lower operating cost. Those outcomes then need to be translated into more specific operating requirements.

If the objective is faster response to disruption, what does faster mean? Minutes, hours, or days? Which disruptions matter? What information must be available? Which decisions must be accelerated? Who is allowed to make them? What constraints cannot be violated?

The answers drive system design. A useful requirements hierarchy might include business requirements, operational requirements, information requirements, decision requirements, technology requirements, security and compliance requirements, and human factors requirements. That last category is easy to neglect. A system may be technically capable of producing a recommendation every five minutes, but if a planner can realistically evaluate only ten exceptions per hour, the operating design still has a bottleneck.

Put the Constraints on the Table Early

Good requirements engineering does more than define what a system should do. It defines the boundaries within which the system must operate. Logistics networks are full of constraints: labor availability, warehouse throughput, dock capacity, trailer availability, carrier schedules, driver hours, parcel cutoffs, regulatory requirements, customer commitments, data limitations, capital budgets, integration dependencies, physical space, maintenance windows, and organizational policy. If those constraints are left implicit, they eventually reappear as implementation surprises.

This is particularly important in automation and AI projects. Optimization models are only useful when they reflect the constraints that actually govern the operation. AI recommendations are only actionable when they fit within decision rights, data quality, and execution capability. The best technology in the world cannot compensate for a requirement that was never articulated. Requirements discussions also benefit from distinguishing between what is necessary and what is desirable.

Every stakeholder has preferences. Transportation may want a particular carrier workflow. Finance may want additional controls. IT may prefer a specific architecture. Operations may want a familiar user interface. Executives may want a capability they have seen elsewhere.

Some of these preferences are important. Others are habits. A disciplined process identifies which requirements are mandatory, which are high-value, which are negotiable, and which are simply convenient. That distinction gives the organization room to make intelligent tradeoffs rather than creating an impossible specification in which everything is equally important.

It also improves vendor conversations. Technology and automation providers can respond to the logistics problem the customer is actually trying to solve rather than to an undifferentiated list of requests. One of the most useful ideas from systems engineering is that a requirement should eventually be verifiable. “Improve visibility” is difficult to test.

“Provide the status and predicted arrival time of 95 percent of priority inbound shipments with data no more than 30 minutes old” can be tested. This discipline creates a bridge between design and implementation. The requirements used to justify the investment become the basis for validation after the system is deployed.

That sounds elementary, but many logistics projects lose this connection. Business cases are approved around outcomes, implementations are managed around milestones, and success is eventually declared because the system went live. Go-live is not a business outcome. A system should be judged against what it was supposed to accomplish.

Buy the Solution Only After the Problem Is Defined

A requirements-first approach does not slow innovation. It makes innovation more precise. Once the operating requirements are clear, technology choices become easier to evaluate. The organization can determine which capabilities are essential, which integrations matter, where automation is appropriate, where human judgment remains important, and what level of performance is actually required.

Sometimes the answer will be a new platform. Sometimes it will be process redesign, better master data, a change in decision rights, or a relatively modest extension of an existing system. That is not a less ambitious transformation. It is a more engineered one.

Logistics leaders are under enormous pressure to move quickly, especially around AI and automation. Speed matters. But speed in selecting a solution is not the same as speed in solving the problem.

Speed matters, especially in AI and automation. But speed in selecting a solution is not the same as speed in solving the problem. In 1.4, we take the next step and make the stakeholder conflicts, constraints, and tradeoffs explicit before they get buried in the design.

Related Logistics Viewpoints research

Systems Engineering in Logistics
The New Architecture of Logistics
2026 Supply Chain Decision Intelligence Market Map
Supply Chain Technology Buyers Have a Market Structure Problem
Previous in this series: Stop Managing Logistics as a Collection of Functions

Request the Systems Engineering in Logistics Client Edition

If your organization is evaluating a logistics transformation, technology strategy, automation program, or operating-model redesign, I would be glad to provide the complete client edition and discuss how the framework applies to your priorities, constraints, and operating environment.

Request the client edition

The post Requirements Before Technology: Define the Problem Before Buying the Solution appeared first on Logistics Viewpoints.

Continue Reading

Non classé

NVIDIA Is Buying the Distribution Layer of AI

Published

on

By

NVIDIA’s agreement to acquire Hugging Face for approximately $12.9 billion looks, at first, like another large transaction in an AI market already full of large numbers. Look more closely, however, and this is considerably more interesting than a semiconductor company buying a software company.

NVIDIA already dominates one of the most important layers of artificial intelligence: accelerated computing. Hugging Face occupies a different position. It has become one of the principal places where developers discover models, evaluate them, modify them, and decide how and where those models should run.

NVIDIA is therefore not simply acquiring another AI asset. It is moving toward the interchange where models, applications, developers, and computing infrastructure meet. That matters because the next phase of AI competition will increasingly be about orchestration rather than individual components.

For logistics executives, that should sound familiar.

Hugging Face Has Become AI Infrastructure

Hugging Face began in 2016 and has evolved into much more than a repository for AI models. The platform now serves millions of developers and hosts millions of models, along with datasets and applications used by companies to discover, evaluate, customize, and deploy artificial intelligence.

The scale matters, but its position within the architecture matters more.

Modern AI is increasingly becoming a component ecosystem. An enterprise does not necessarily select one enormous model and build everything around it. It might use one model for computer vision, another for document processing, another for coding, and a more capable frontier model for difficult reasoning. Some models might run internally, others through cloud APIs, and still others at the edge.

Hugging Face sits in the middle of that increasingly complicated environment. It helps developers find the components and increasingly helps them determine how those components can be deployed.

In logistics terms, Hugging Face looks less like a manufacturer and more like an interchange. It does not need to manufacture every product moving through the network to influence how the network operates. Its value comes from connecting a large number of models, developers, applications, and infrastructure choices.

NVIDIA has agreed to buy that interchange.

NVIDIA’s Problem Is Bigger Than GPUs

NVIDIA’s existing position in artificial intelligence is extraordinary, but it also contains a strategic vulnerability. Some of its largest customers have powerful incentives to reduce their dependence on NVIDIA hardware. Microsoft, Google, Amazon, Meta, OpenAI, and others have developed or are developing specialized accelerators of their own.

That does not mean NVIDIA’s GPU franchise disappears. Its installed ecosystem, software architecture, developer expertise, and performance advantages remain formidable. But it does mean NVIDIA cannot assume the future AI architecture will consist of NVIDIA hardware underneath every important workload.

The rational response is to expand the battlefield.

If AI infrastructure becomes increasingly heterogeneous, then the layer that helps determine what models are selected and where workloads are executed becomes more valuable. NVIDIA does not necessarily have to own every model or manufacture every accelerator if it can remain deeply embedded in the architecture through which the larger ecosystem operates.

Hugging Face provides a route into that architecture.

A developer might choose a model created by Meta, Mistral, Google, DeepSeek, or an independent research group. That model might eventually run on NVIDIA hardware, an AMD accelerator, a hyperscaler’s custom chip, an enterprise server, or an edge device.

Owning Hugging Face puts NVIDIA much closer to the point where those decisions originate.

Why Hugging Face Needs to Remain Open

One of the most revealing parts of the deal is NVIDIA’s commitment to keep Hugging Face open and compute-agnostic. NVIDIA has said its hardware will not be required to build or deploy through Hugging Face and that the platform will continue supporting multiple clouds, frameworks, models, inference providers, and silicon architectures.

That may sound counterintuitive. Why spend almost $13 billion on a platform and continue allowing competing hardware through it?

Because the neutrality of the platform is part of what makes it valuable.

An interchange becomes strategically important because many participants are willing to use it. Ports become powerful because multiple carriers call there. Freight marketplaces become more valuable as more shippers and carriers participate. Digital platforms acquire influence because participants on multiple sides of a market continue to meet there.

If NVIDIA turned Hugging Face into a closed distribution channel for NVIDIA hardware, it could weaken the network effect it is buying.

The better strategy is subtler. Keep the interchange open, encourage as much AI development and deployment as possible to flow through it, and make NVIDIA infrastructure exceptionally attractive when users decide where those workloads should run.

That is not exclusivity. It is influence.

AI Is Becoming a Routing Problem

The acquisition also arrives as enterprise AI moves away from the assumption that the largest available model should handle every task.

That makes little economic sense once organizations begin operating AI at scale.

Logistics has dealt with this type of problem for decades. A company does not ship every product by air because air freight is fast. It selects the mode appropriate to the service requirement, product value, distance, urgency, and cost. The fastest resource is not necessarily the economically correct resource.

AI workloads are beginning to require the same discipline.

A difficult planning problem involving incomplete information may justify a high-cost frontier reasoning model. Invoice classification probably does not. A computer-vision application may require something entirely different. A repetitive enterprise workflow may run perfectly well on a smaller open-weight model hosted internally at a fraction of the cost.

Once enterprises begin making these choices systematically, model selection becomes a routing problem. Capability, cost, latency, reliability, privacy, sovereignty, and infrastructure availability all become constraints.

Hugging Face occupies an important position in that emerging routing architecture because it provides access to a broad universe of models rather than forcing developers into a single supplier ecosystem.

NVIDIA is now buying a position much closer to that routing decision.

From Components to Systems

The acquisition fits a broader evolution in NVIDIA’s strategy. The company has been steadily expanding outward from the GPU into networking, software libraries, complete computing systems, inference infrastructure, robotics, digital twins, and AI factories.

Hugging Face adds another layer: developers, models, datasets, applications, and distribution.

Viewed as a system, the logic becomes clearer. At the bottom of the architecture, NVIDIA supplies much of the physical computing infrastructure. Higher in the stack, its software and development tools help applications use that infrastructure. Hugging Face gives the company a strategic position closer to where developers choose which models to use and how those models should be deployed.

That means NVIDIA does not need every workload in the ecosystem to run on NVIDIA hardware for the acquisition to succeed. The larger objective may be to grow the entire AI ecosystem while positioning NVIDIA infrastructure as one of the easiest and most attractive destinations for the resulting workload.

That is a platform strategy, and it is considerably more durable than a strategy based solely on hardware scarcity.

The Logistics Lesson

There is a broader lesson here for logistics because the same structural shift is occurring throughout industrial technology.

Companies naturally focus on assets: factories, warehouses, transportation capacity, automation equipment, software applications, semiconductors, and increasingly AI models. But as systems become more interconnected, an increasing share of competitive power moves into the interfaces between those assets.

The valuable position is often the place where choices are made.

Which carrier receives the load? Which warehouse fills the order? Which inventory pool serves the customer? Which model handles the request? Which computing resource executes the workload?

The organization that controls or intelligently orchestrates those decisions can acquire influence far beyond the value of the underlying asset.

This is why orchestration is becoming such an important theme across logistics. Companies have spent decades improving individual nodes. They now have better warehouses, better transportation systems, better planning applications, better automation, and better visibility. The next increment of performance increasingly comes from coordinating those resources as a system.

Artificial intelligence is following the same path.

The first stage of the AI boom was dominated by the question of who could build the most powerful individual components. NVIDIA won an extraordinary portion of that contest because its GPUs became the essential machinery of AI.

The next contest will be about how those components are selected, routed, and orchestrated.

That is what makes Hugging Face strategically important. NVIDIA already controls one of the most valuable resources in artificial intelligence. It is now buying a position much closer to the place where millions of developers decide what intelligence to use and how to deploy it.

The chips still matter enormously, but the center of gravity is moving from individual components toward the architecture connecting them. As logistics has demonstrated repeatedly, the company that controls the interchange can become just as important as the companies producing what moves through it.

The post NVIDIA Is Buying the Distribution Layer of AI appeared first on Logistics Viewpoints.

Continue Reading

Trending