The Emergence of Visibility as Infrastructure: What Lessons Should Suppliers Learn?

project44’s separation of its business in July 2026 into project44, the Decision Intelligence Platform for shippers, and LSP44, the agent and Application Programming Interface (API) “infrastructure” business for Logistics Service Providers (LSPs), relies on a straightforward proposition: shippers buy applications, while LSPs buy infrastructure. According to project44, shippers want visibility, transportation management, yard management, and applications, in a common environment where they can manage supply chain operations. LSPs, by contrast, want carrier connectivity, data, APIs, software development kits, and Artificial Intelligence (AI) agents embedded inside their own technology stacks and customer propositions.

There is undoubtedly truth in this distinction. Digital logistics processes are increasingly central to how LSPs differentiate their services; therefore, they have a stronger incentive to retain their own customer portal and operating processes, and to build “infrastructure” through which they can offer visibility services to their own customers—creating another monetization opportunity. Shippers, by contrast, are pure data and application consumers, and are buying purely for internal purposes rather than with an eye to reselling visibility services. This explains and justifies why LSP44 is positioned as infrastructure on which an LSP builds, instead of an application that the LSP buys.

However, the distinction between LSPs and shippers may be a little too neat. Many LSPs continue to treat visibility as a checkbox to meet the specific requirements of a customer’s Request for Proposal (RFP), while some, especially larger shippers, view the data they gather as strategic assets and want to integrate them into their own analytical and operational environments. The desire for infrastructure is, therefore, not exclusive to LSPs; indeed, not all LSPs are mature enough to build their own visibility infrastructure.

The more fundamental product split within supply chain visibility is between three increasingly distinct product layers: validated data, decision intelligence, and workflow execution. The underlying capabilities that customers buy are similar, but the difference is primarily a question of bundling or packaging—whether as a finished application, as embedded infrastructure, or components within internally controlled workflows.

The validated data layer establishes clearly what is happening across the supply chain, aggregating and conditioning data from different sources, such as Internet of Things (IoT) devices, carrier connectivity and milestones, and many other enterprise systems and contextual sources. In a 2025 survey of 490 supply chain practitioners, ABI Research found that this is a layer that customers primarily look to source externally, with around 67% using some combination of partnerships, outsourcing, or technology capability acquisition from third parties, and only 29% looking to build visibility tools internally.

The decision intelligence layer helps customers interpret visibility data (e.g., Estimated Times of Arrival (ETAs), anomaly detection, root cause analysis) and provides recommendations regarding how to act on that. These capabilities often rely on specialist analytics and are built on large proprietary datasets assembled by visibility suppliers over many years, creating more accurate models than buyers would be able to replicate internally on a customer of one. For instance, survey respondents were even more unlikely to build this layer internally: only 16% were building predictive ETAs using internal teams, and 17% for lane risk assessments.

The third layer, workflow execution, turns recommendations into action. This includes creating tasks and eventually allowing agents to take bounded actions. This is the area with the heaviest narrative and positioning today from supply chain visibility vendors looking to capitalize on the hype around AI, and especially Agentic AI—but it is also conversely the layer that customers are least able to approach today because of their existing Information Technology (IT) infrastructure setup and because of broader governance concerns. project44 noted in a webinar in August 2026 that around 550 customers had adopted “at least one” of its 54 agents and deployed it into workflows they are running. Feedback from visibility suppliers more broadly, however, suggests that agents are deployed on repetitive but low-criticality workflows today—and that the majority of requests are still driven by basic visibility and exception monitoring.

Workflow automation is more likely to remain internal: approximately 43% of survey respondents noted that they are developing workflow automation through internal teams (compare 29% for visibility and 16% to 17% for interpreting results through the decision intelligence layer). This layer also highlighted the principal difference between LSP and shipper purchasing habits, with LSPs more likely by nearly 10% to build these capabilities internally as “infrastructure” (49%) compared to shippers (40%). There is also some evidence of customers, especially LSPs, looking to unbundle the data layer from the additional upper layers of a visibility solution, choosing to build and own these workflows within their own systems.

The reason for building workflows internally as “infrastructure” are clear when considering the barriers respondents face when looking to turn visibility into action: respondents cited cross-functional coordination (in the top 3 for 70%), missing Standard Operating Procedures (SOPs) for responding to alerts (in the top 3 for 65%), and insufficient operational authority (in the top 3 for 53%) as key reasons. Workflow execution is not merely another horizontal level capability: it depends on company-specific SOPs and risk tolerances, which are more difficult to encode in a single standardized platform.

These survey results suggest that buyers, whether LSPs or shippers, share a lot of goals in common. They want visibility providers to connect a fragmented ecosystem into a rich data environment, and to provide better analytical and data discovery capabilities; but they do not necessarily want them to own all the workflows that sit on top of these data and the analytical pool. LSPs may be more likely than shippers to build workflows internally, creating a justification for LSP44 given the company’s focus on this third layer of the visibility product stack. But the primary divide lies between what parts of that stack customers buy and what they look to build internally. In other words, it is more of a question of product and packaging than an obvious divide between LSPs and shippers.

The project44 and LSP44 split can be justified on the grounds of a shipper versus LSP product, but suppliers should avoid treating this as the main question or segmentation. The product divide is becoming sharper as visibility solution providers move from a one-size-fits-all “visibility” platform to focus on one or more parts of the product stack outlined above. The winning platform will not necessarily be the one that persuades every customer to adopt the entire stack, but the one that allows customers to set their own boundary between externally and internally built capabilities.

Of course, the best decision intelligence and workflow execution layers will be built on top of high quality data, which is where suppliers can differentiate in the short-to-medium terms. For IoT visibility providers in particular, the value proposition rests on the connection between the different layers of the stack: control over physical data capture, device behavior, validation, and contextualization creates more reliable intelligence and, over time, a stronger foundation for automated action. Suppliers can offer an integrated product, while allowing customers flexibility over how the output is consumed and who owns workflows. Repetitive agents and execution capabilities may be offered by an external vendor, but decisions that have a more important impact on an enterprise’s operations will often remain inside their internal systems. Suppliers should be ready to accommodate different customers’ needs with different go-to-market approaches, including fully bundled applications, embedded infrastructure, and hybrid approaches that give enterprises the ability to make the ultimate decision around how they purchase and implement different parts of the visibility stack.